Этот материал, принадлежащий перу известного трейдера OZZY, посвященный некоторым вопросам бизнеса в софтверной индустрии. Первоначально материал был опубликован еще в форуме INDX, как ответ на один из бизнес-планов (заявка от проекта S-BOX). Материал представляет собой переработанный, с согласия автора, текст и показывает некоторые, хоть и спорные, но интересные мысли о перспективах бизнеса на рынке программного обеспечения. В скобках я добавил свои комментарии, таким образом сам текст минимально корректирован. Можно не соглашаться, можно спорить - но прочитать интересно! Просьба также не рассматривать приведенные примеры "в лоб" - смысл материала становится более понятным, если абстрагироваться от конкретики и посмотреть на всю индустрию немного "сверху"…

Часть Первая. Что не так в консерватории или зачем нужны распределённые системы.

Начнем наш рассказ с небольшого практического примера (на основе одной заявки на венчурный проект на бирже INDX).

Итак, задача звучит следующим образом:

Пользователю нужно защищённое хранилище НЕФОРМАТИРОВАННОЙ информации с разделением доступа. То есть, пользователю предоставляется возможность хранить конфиденциальную информацию на удаленном сервере, причем сама информация может иметь любой формат.

Классическое решение задачи:

Создать "дисковый массив" с доступом через некий административный Web-интерфейс по защищённому протоколу + криптование данных в момент их занесения в хранилище.

Теоретически, решение правильное, но с практической точки зрения оно содержит ряд узких мест. Собственно узкое место одно – криптование данных на стороне сервера, из которого вытекают два следствия:

Высокая нагрузка на сервер хранилища, что повысит требования к компу => увеличит его стоимость несоизмеримо выполняемой функции => что увеличит цену вопроса. (я бы добавил еще - уязвимость в алгоритме криптования или программной реализации сразу повлечет за собой ПОЛНУЮ дескредитацию всех данных всех пользователей. Это минус. Действительно, криптоалгоритмы очень ресурсоемки, потому применение мощных алгоритмов увеличит потребности в мощности сервера. Но если воспользоваться некоторыми техническими решениями, например, аппаратными шифровальщиками - то тут уже можно оспорить точку зрения автора).

Данные будут передаваться в "открытом" виде от клиента к серверу, что существенно снижает ценность криптования данных на сервере (применение SSL частично спасает ситуацию, но приведет к удорожанию системы).

Как же побороть оба "несчастья"? Очевидно, нужно выносить процесс криптования с сервера хранилища на другие компутеры, т.е. применять классическую распределённую схему. Какие же машинки в этом случае лучше всего подходят для выполнения данной функции? Ответ и на этот вопрос достаточно очевиден, эту функцию лучше всего вынести на клиентские компьютеры, потому что:

Производительность системы в целом будет расти прямо пропорционально количеству подключившихся клиентов.

Данные от клиентов будут уходит на сервер уже в криптованном виде, т.е. по внешним каналом никаких "открытых" данных передаваться не будет.

Но что же получается в такой схеме? А получается то, что клиент вправе выбирать сам то крипто-ПО, которое считает для себя более удобным, и часто совсем не то, которое "прилагается" к сервису ;-). Таким образом весь сервис вырождается только к предоставлению места под хранение клиентской информации. Если кто не в курсе, то данные объёмом до 10М (а теперь уже и существенно больше) можно бесплатно растолкать по сотне мест в Инете, а хранение больших объёмов стоит копейки.

NOTES

Скажу ещё, что данную идею можно развить и дальше. Поскольку единственная плата клиента – плата за трафик, то сократить её можно архивируя информацию перед отправкой в "хранилище". И тут наступает самый интересный момент… RAR даёт возможность ставить пароли на архивы, в общем-то это стандартная фича, но что делает ЭТОТ архиватор с паролём? Он не хранит его в архиве, он использует этот пароль в качестве ключа (!) перед тем, как зажать файлы. Длинна пароля может быть достаточно большой (по крайней мере 32 символа у меня помещалось, а это 256 битный ключ, однако), ограничений на вводимые символы вроде тоже нет… Таким образом, получается, что даже никакого крипто-ПО использовать не нужно. (кроме того, RAR - стандарт де-факто на рынке, к тому же кроссплатформенный…)

ЗЫ Следующая часть будет о Хлебе, Масле и Икре…

Часть Вторая. О Хлебе, Масле и Икре или как программеру на это заработать.

Разработка ПО (в общепринятом понимании) уже несколько лет как перестала приносить доходы "индивидуалам" и мелким конторкам, специализировавшимся на этом. Данный рынок (разработки "чистого" ПО) уже поделен гигантами и просто крупными компаниями. Особо озабоченные "любители" постоянно голосят о "монополизации рынка" и "борьбе за права потребителей". Но эти вопли только подчёркивают то, что они всего-навсего ЛЮБИТЕЛИ и недалёкие люди, поскольку не замечают, что у них под боком Каста ПРОФЕССИОНАЛЬНЫХ Программеров как жила припеваючи, так и продолжает жить не смотря на то в какой компании они работают. (вот тут заключена одна из главных мыслей этого материала, и одна из самых спорных!)

А суть этого становиться понятна, если окинуть всю поляну и не только на текущий момент, а с учётом всей предыстории.

Производители делятся на две группы:

Первая, в которую входят такие монстры по производству ПО, как Голубой Гигант, Одна Малоизвестная Мелкая Компания с Гарри Поттером во главе и им подобные. Они формируют операционные среды. Ведь если абстрагироваться, то весь Биллев Офис является неотъемлемой частью Виндовс => частью операционной среды.

Вторая, очень разнокалиберная публика (от монстров, до "индивидуалов"), что же делают они? Нет, они не пишут "приклидное ПО". Так думает ЛЮБИТЕЛЬ, и это неверно. Прикладное ПО лишь средство. Эта группа занимается адаптацией ОС под нужды конечного пользователя/решения. В рамках этой деятельности, разработчики данной группы занимаются "финишной" интеграцией отдельных компонентов ОС и компонентов решений разработчиков своей группы.

Первая группа выступает для второй в качестве "санитара леса", поддерживая перспективные решения и "забывая" о неудачных. В тоже время, вторая формирует для первой множество конечных решений, на основе которого первая вырабатывает более общие и делает их частью своих операционных сред (т.е. если ты не являешься частью решения, ты являешься частью проблемы). Тот же многострадальный Биллев Офис классический пример такого "общего" решения. На самом деле, ещё одни аналогичным, если не более крупным обобщением стала MS Visual Studio .NET, но об этом ещё мало кто догадывается ;-). (а появление .NET - это вообще отдельная "песня", и она может и уже изменяет мир ПО так, что через пару лет все может быть совсем по-другому, нежели сейчас. Для размышлений, приведу всего лишь два названия: Microsoft Business Solutions CRM и www.salesforce.com)

Так вот, всё сказанное выше должно было навести на мысль, что все рассматриваемые БП IT-проектов (которые безусловно относятся ко второй группе разработчиков), должны, в первую очередь, ориентироваться на предоставление IT-услуг (оттуда должны поступать основные деньги), а само ПО должно быть лишь средством и закладывать более 10-20% в доход от его реализации просто… нецелесообразно. Вот так и получается, что разработчики-любители "чистого" ПО живут с этих 10-20% и то, если найдут клиента (что стало очень сложно), а профессионалы получают все 100%, да ещё и очереди стоят.

ЗЫ. Следующая часть будет посвящена Samples-ам…

Часть Третья. Samples или что такое ХОРОШО и что такое ПЛОХО.

Естественно, что подобное обсуждение хорошо было бы закончить каким-нибудь примером…

Давайте проиллюстрируем описанное выше одним примером - обменным автоматом ROBOX.

Автомат ROBOXа стал побочным продуктом основного вида деятельности, т.е. он создавался именно как СРЕДСТВО ПРЕДОСТАВЛЕНИЯ УСЛУГИ этим проектом. Поскольку ROBOX (в концептуальном плане) выступает для клиентов в качестве шлюза между различными электронными валютами, то и сам автомат сервиса изначально делался в виде интегрированного друг с другом набора служб. Преимущества такого подхода многие смогли уже увидеть, на примере того, как шустро в автомате появлялись новые валюты, которых даже не планировалось на момент создания автомата.

NOTES

Этот пример неплохо показывает, что разработка "чистого" ПО не такое уж прибыльное дело для небольшой конторы и имеет практический выхлоп только в качестве поддержки основного бизнес-процесса компании, т.е. в первую очередь услуги (IT или другие, неважно), а уже потом ПО.

Примечание: выскажу, вроде известную мысль, но о которой часто все забывают - само ПО никому не нужно! Ни открытое, ни закрытое, но свободные форматы, ни бинарные/XML и т.д. Именно - ненужно! Всем (ну или почти всем) надо решение их задач и проблем, причем быстрое, эффективное и дешевое. И все! Этим можно ставить крест на всех баталия за и против опенсоср, виндовс и всего остального - не делайте продукт (как вариант - не продавайте продукт, впрочем все в этом материале можно с успехом применить и для рынка продаж ПО, своего или чужого), решайте проблемы заказчика, и будет вам и хлеб, и масло, и икра, и очередь новых клиентов….