вторник, 19 апреля 2011 г.

Что скрывается за «облаками»?

Отголоски идеи, предложенной в статье, можно прочитать в ранней публикации. Статья писалась несколько месяцев. За это время произошел неожиданный всплеск к теме «облаков», но никто из обсуждающих тему не продвинулся настолько далеко, как изложено в данной статье.
Как бы в подтверждение моих мыслей, пока писалась эта статья, «ВКонтакте» объявили, что добавят возможность скачивания видео из соц.сети по протоколу torrent. Одна из причин- снизить нагрузку на сервера.

Оковы прошлого

К нынешнему моменту развития информационные технологии прошли через несколько значимых точек. Не вдаваясь в подробности, можно выстроить такую цепочку: файл-серверные решения, клиент-серверные, многозвенные. А затем появились решения на базе SOA , cloud. Разработка новых архитектурных решений, появление новых технологий - это попытки ИТ справиться с новыми вызовами, а также устранить недостатки предыдущих решений. Нынешняя недавняя «фаворитка» SOA - далеко не идеальное решение. С одной стороны: централизация управления сулит простоту администрирования ПО, с другой стороны - высокие требования к масштабированию, надежности, безопасности. К тому же, раньше не было единой платформы для разработки SOA-решений, в результате, разработчикам надо было придумывать свои реализации архитектуры. И это только технические проблемы, а есть еще административно-правовые вопросы, не решенные до сих пор. В результате, SOA «не пошла»- старые, добрые клиент-серверные решения в целом оказались удобней в эксплуатации.
Появившаяся технология «облачных» вычислений – это попытка решить некоторые проблемы современных архитектурных подходов проектирования. Обращаю внимание, что я в статье отношусь к «облачным» вычислениям не как к новой архитектуре, а как к реализации архитектуры клиент-сервер. «Облако» обеспечивает единую среду исполнения разнообразного ПО, которая хорошо масштабируется, обладает высокой надежностью. Однако, несмотря на то, что про «облачные» вычисления говорят уж года 3 подряд, повального использования «облачного» ПО нет.
С технической точки зрения причина в том, что «облака» решают очень маленькую часть проблем. «Облака» обеспечивают среду разработки и исполнения, легкость развертывания приложений, масштабирования и, отчасти, повышают надежность, но это все - на серверной стороне. Они никак не решают проблему безопасности в целом и не устраняют ни единой проблемы при передаче данных, и проблемы на клиентской стороне ПО. Для корпоративного сектора эти технические проблемы «облаков» существенны.
Есть ряд сложностей (решаемых, но тем не менее сложностей), связанных с использованием «облаков». Например, тоже масштабирование: отличное решение- выделяемая вычислительная мощность растет пропорционально вашим потребностям. Для начинающего бизнеса сразу получить готовую инфраструктуру, обкатанную, налаженную- это отличное подспорье в начале бизнеса, «высокий старт». А быть как, если придуман новый бизнес-процесс, который даст конкурентное преимущество, а готовое «облачное» решение его не поддерживает? Можно заказать кастомизацию у того же «облачного» сервиса, либо, если у них есть API, попробовать разработать свое решение.
Или другая сложность. Вспомните историю с отключением серверов «Агавы»: пришел сотрудник органов правопорядка и просто отдал распоряжение отключить сервера. Все сервера с тысячами хостингов на них. «Облако» без лишних телодвижений перекинет клиентов на другой ЦОД. Ну, разве что, время отклика возрастет. Но ведь ваша информация оказалась в руках неизвестно кого! Вас успокоит то, что это все по закону, в рамках следствия, и следствие интересуется не вами, а другим хостингом?
Вспоминаю из своей практики: как маскировались сервера и продумывались защиты от «маски-шоу», как, в случае сбоя, работаешь «до упора», но чтобы к утру все заработало, как на тривиальном клиент-сервере делали ежечасные бэкапы на лету, писали «автообновлялки» клиентского ПО и т.п. До сих пор работают системы, в создании которых я принимал участие или целиком создавал сам. Прошло уже 7-10 лет, а бывшие коллеги в общении говорят: «А помнишь, ты делал? Так до сих пор работает».
Программное обеспечение, написанное без всяких «облаков», работает годами. А если «сбойнет», то быстро поднимается бэкап, в крайнем случае, программист/администратор будет работать до полного устранения поломки. За это он получит потом пару дней отгулов. Хитроумные приемы обеспечивают сохранность и недоступность данных для «людей в масках». Это уже обкатанные годами решения. Любые новые технологии должны предложить очень сильные аргументы, чтобы на них обратили внимание.
Вот и получается, что у «облаков» достаточно ограничений. Они займут свои нишу, но, безусловно, ландшафта архитектурных ИТ-решений не изменят. Траектория кривой развития «облачных» вычислений уже хорошо наблюдаема, прогнозируема. Еще год-два, и это будет «вчерашним днем», как написал Колесов «С облачной тематикой пора завязывать». Очень хорошо читается использование «облаков» для почтовых сервисов, антиспама, Web-фильтров, сайтов, групп общения, коллективной работы и т.д.
Но я предлагаю передовым отрядам айтишников заглянуть за «облака», в день завтрашний. Подумать, какие решения, а, может быть, новая архитектура ждет нас впереди. То, что реально может устранить недостатки нынешних решений и откроет новые возможности в области ИТ-технологий. Начинать надо уже сейчас, чтобы быть на волне прогресса. Скажу сразу, я сам пытаюсь «просчитать» технологию будущего. Отрывки моих мыслей можно увидеть в моих публикациях.

Взгляд сквозь хрустальный шар

Какие проблемы есть у нынешних решений? Традиционные ключевые моменты: надежность, доступность, безопасность, производительность.
«Облаками» мы «разрулим» большинство проблем, но на серверной стороне. Разве что, остается без ответа вопрос относительно безопасности, приватности данных пользователя. А как быть с каналами передачи данных? Если шифрованием можно обеспечить безопасность, то надежность связи гарантировать никто не берется. Это вторая проблема. Третья проблема - «живость» интерфейса на клиентской стороне. Приложение не должно подвисать, медленно работать, требовать непропорционально много ресурсов для выполнения задачи.
На сегодняшний день весьма распространена архитектура с тонким web-клиентом и реализацией бизнес-логики на серверной стороне. Нынешняя гонка браузеров помогает решить третью проблему. Остаются проблемы с каналом связи и общая проблема безопасности данных. Обе проблемы решаются развертыванием «облаков» в локальной сети клиента. Но такое решение вызывает у апологетов облачных вычислений сразу резкое «нет»: во-первых, убивается идея SaaS; во-вторых , в локальной сети «облако» полностью теряет все свои преимущества перед классическим клиент-сервером, с серверной частью, функционирующей на кластере.
Таким образом, можно сформулировать ключевое противоречие: использование «облака» вне предприятия ненадежно из-за каналов связи. С другой стороны, перенесение «облака» в локальную сеть предприятия лишает его каких-либо преимуществ перед существующими решениями (т.е. приходим к классической модели продажи ПО по лицензиям, обслуживание «облака» клиентом или аутсорсинг).
Расскажу случай, работал я на складах. Офис в городе, склад - за городом. Связь по Интернет через VPN. За городом только один провайдер был, т.е. резервный канал невозможен. Ну, разве что, через спутник, что при том объеме траффика было нереально. Раз в месяц на полдня-день канал падал. А это совершенно реальные потери в деньгах: из-за сбоя клиенту отказали в продаже - он без проблем купил у другого. Абсолютно реальные потери в деньгах. Не косвенные, а, что ни на есть, прямые. При этом, провайдера постоянно «пинали», но без толку. И никакой договор об обеспечении качества связи они, ни за какие «коврижки», не подписывали. Это понятно, почему - ведь от них тоже далеко не все зависит.
Поэтому, многие клиенты никогда не согласятся на использование «облаков»- со своими ИТшниками под боком спокойнее. А если учесть, что классический клиент-сервер совершенно спокойно, без существенных оптимизаций, работает на нескольких тысячах клиентов, то «облаку» тут совсем нет места. Более крупные клиенты используют «трехзвенки», которые замечательно масштабируются без всяких «облаков» и «держат» уже пару десятков тысяч АКТИВНЫХ пользователей, подчеркиваю, активных. Т.е. общее число пользователей может быть на порядок больше. Т.е. «двухзвенка», «трехзвенка» способны вытянуть на себе 99% предприятий.
Можно заметить, что в статье о SaaS почти не говорится - все крутится вокруг общих достоинств и недостатков технических реализаций архитектур. В основном, речь о клиент-серверной архитектуре. В теории, «облака» должны еще, вроде бы, быть дешевле. Пока только встречаются общие «разводы вилами по воде» на эту тему – четких выкладок по пунктам я не видел. Поверим на слово - дешевле.
Итак, необходимо придумать решение, чтобы «облако» вне предприятия не теряло своей привлекательности. Две ключевые проблемы: надежность каналов связи и общая безопасность данных. Ваши предложения?
Мой вариант: использование torrent-сетей. Шифруем и размещаем блоки данных на разных клиентах. По запросу torrent-клиенты отдают нам нужные блоки. Блок эквивалентен сектору на диске, т.е. можно написать драйвер, наподобие iSCSI, который будет torrent-сеть представлять в виде диска. Информацию многократно дублировать на клиентах. Таким образом, чем больше клиентов и чем больше места на своих дисках они предоставляют для хранения torrent-данных, тем надежнее сеть.
1. В результате, получается безопасное решение - ни у кого нет всех данных, только отдельные зашифрованные блоки. Безопасность в таком решении на голову выше, чем в «облаках» («маски-шоу» отдыхают).
2. Это дешевое решение, т.к. роль ЦОДов сводится к минимуму- используются мощности клиентских компьютеров.
3. Это устойчивое к сетевым сбоям решение- ни с одного, так с другого клиента придут данные. Более того, данные можно ограничить локальной сетью, что обеспечит полную автономность сети.
Минусы:
1. Многократное дублирование не каждому клиенту понравится- ведь, чтобы закинуть в torrent-сеть 1МБ своих данных надо в сеть, под хранение чужих данных отдать, например, 10МБ своего диска (для полного десятикратного дублирования, чтобы повысить вероятность нахождения в сети хотя бы одного клиента из десяти). Пропорции могут быть произвольными- я привел соотношение 1:10 лишь как пример.
2. Сетевые задержки пакетов выше, чем у «облака».
3. Некоторые проблемы с гарантированным доступом к данным- никто же не гарантирует, что из клиентов с нужным блоком данных будет хоть кто-то «онлайн». Хотя тут можно использовать выделенный сервер или «облако» для хранения полной копии всех данных.
Что мне больше всего нравится в моем варианте- это преемственность. Сеть торрент-клиентов строится вокруг «облаков». Одна технология не отвергает другую, а взаимно дополняет. «Облако» хранит «оригинал» данных и раздает торренты клиентам. А теперь представьте, если в браузер включить поддержку торрента, например, в виде плагина. Нагрузка на сайты резко упадет, т.к. «статику» клиенты будут забирать друг у друга через торрент, не обращаясь на сайт. Как это выглядит в действии:
1. Сайт может быть построен на «облаке», а может быть традиционный хостинг.
2. Задача сайта- выдать на клиента его кастомные, пользовательские данные и указать ссылку на исполняемый скрипт. Это типичный web2.0- никаких «фантазий».
3. Скрипт, исполняясь в браузере, начинает формировать внешний вид загружаемой страницы, на основе пользовательских данных.
4. А вот далее начинаются «чудеса». CSS, картинки, менюшки, шаблоны- т.е. статическая часть данных- грузится по торрент-протоколу. Т.е. далее уже нет обращения к серверу.
Таким образом, снижается нагрузка на сервер, информационные потоки равномерно распределяются по сети (обмен данных между клиентами), а не стекаются все к ЦОДам. Побочный положительный эффект- с теми же ДОС-атаками проще будет справиться.
В предельном варианте реализации и БД можно по торрент-сети «размазать», так что сервис из «облака» полностью уйдет «жить» на клиентах. Сервер нужен будет только как стартовая точка входа в торрент-сеть сервиса и как резервное хранилище данных.
Такова моя идея. Аналогичных идей в Интернете я не встречал. Как и все предыдущие, эту идею я отдам на реализацию любому заинтересовавшемуся специалисту согласно условий. По моему мнению, идея очень сильная… в общем, дерзайте.

Ссылки по теме:
  1. Протокол torrent: http://ru.wikipedia.org/wiki/Torrent
  2. Распределенная файловая система: http://en.wikipedia.org/wiki/Grid_File_System
Update: После публикации статьи я нашел уже готовую реализацию, буквально 1:1, того, о чем я писал: http://www.unhosted.org/, http://www.opennet.ru/opennews/art.shtml?num=30401. Приоритет в идее не за мною, но я очень рад такому подтверждению идей, сгенерированных мною. Это говорит о том, что я "держу нос по ветру" и правильно чувствую тренды в ИТ.

суббота, 16 апреля 2011 г.

Агентство "Мы ищем таланты"

Идея предлагается в рамках нынешних процессов модернизации и технологического развития. Агентство может быть создано в рамках деятельности существующих организаций, занимающихся инновациями: Роснано, фонд "Сколково", РВК.
Зачем это нужно?
Возьмем в качестве примера фонд "Сколково". У фонда не много проектов на сегодняшний день (апрель 2011 года). Поток их явно падает. Это естественный процесс, связанный с тем, что прошел первоначальный интерес к проекту. С другой стороны, все используемые на сегодняшний день способы привлечения стартапов можно отнести к пассивным. Т.е. фонд, выставив условия, ждет, когда к нему придут стартапы. Тут надо заметить, что частные инвесторы действуют гибче, устраивая выездные сессии. “Топтаться на этой поляне” всем уже тесно. “Сливки” сняты и нужно делать следующий ход- самим заняться активным поиском талантов и созданием вокруг них стартапа.
Почему это надо делать?
Среди ученых очень много талантливых людей, но совершенно коммерчески не активных. Т.е. свои исследования они проводят годами, делают доклады, пишут монографии, при этом даже не задумываются о коммерциализации своих идей. Нужен эдакий антрепренёр, тот кто оценит перспективность исследования и полностью возьмет за себя все вопросы коммерциализации разработки. Сам ученый при этом, получая необходимые средства на исследования, не озабочивается какими-либо вопросами, не связанными с исследованиями.
Как это сделать?
  1. Сформировать пул потенциальных инвесторов. Например, гранты на исследования уже выдаются компанией Microsoft. Выразили заинтересованность в сотрудничестве с фондом многие крупные компании. Такая работа уже проводится- с “нуля” делать ничего не придется.
  2. В ВУЗами фонд подписаны меморандумы о сотрудничестве. В рамках этих меморандумов следует договориться о получении в электронном виде тезисов докладов с научных конференций. Тут же можно подумать о формировании базы данных и публикации на сайте фонда этих тезисов, чтобы инвесторы могли сами “попастись” на сайте в поиске интересных идей. Это будет способствовать созданию комьюнити вокруг фонда.
  3. Доклады могут делаться как самими учеными, так и студентами, у которых ученый является руководителем проекта. Интересные с точки зрения доклады отбирать для более детального анализа.
  4. По отобранным докладам провести детальный анализ (включая выезд к ученому и устное обсуждение деталей), подготовив аналитический отчет. В отчете отразить степень готовности исследования к коммерциализации и примерную область применения.
  5. Из пула инвесторов выбрать потенциально заинтересованных, которым предложить выделить грант на исследование с последующей коммерциализацией. Фонд может выступать как соинвестор.
  6. Антрепренёр, т.е. человек который нашел ученого, свел его с инвестором и добился инвестирования получает вознаграждение.
Достоинства моего предложения
  1. Данный механизм отлично “ложится” на деятельность фонда и укладывается в уже существующие договоренности между фондом, ВУЗами, инвесторами.
  2. Поиск талантов переходит на качественно новую стадию- он становится активным. Вместо пассивного ожидания, когда сам исследователь со своей разработкой придет в фонд за финансированием, фонд сам его ищет и предлагает ему все готовое. Исследователю останется только подпись в договоре под галочкой поставить и получить деньги на свой счет для исследований. В то время как сейчас он должен проявить “коммерческую жилку”, отвлечься от исследований: зарегистрировать юридическое лицо, найти иностранного участника (требование фонда), подать заявку в фонд и пройти все формальные процедуры оформления.
  3. Формирование базы данных исследовательских проектов будет способствовать формированию “Сколковской общины”, создание которой декларируется фондом.
  4. Это всем выгодный подход: компании-инвесторы получают информацию по исследованиями, которые могут заинтересовать их R&D подразделения; фонд выполняет свою миссию, существенно наращивая свой портфель проектов, антрепренёр получает свой процент от сделки. Полный “win-win”, как говорится.
  5. Сам план прост, и его возможно в течение нескольких месяцев начать реализовывать.