1. Тут нет торрента и автоматического "размызывания" данных по сети, но идея с javascript полностью совпала: http://www.unhosted.org/ (http://www.opennet.ru/opennews/art.shtml?num=30401).
2. Распределенная файловая система: http://en.wikipedia.org/wiki/Grid_File_System.

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

К нынешнему моменту развития информационные технологии прошли через несколько значимых точек. Не вдаваясь в подробности, можно выстроить такую цепочку: файл-серверные решения, клиент-серверные, многозвенные. А затем появились решения на базе 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, картинки, менюшки, шаблоны- т.е. статическая часть данных- грузится по торрент-протоколу. Т.е. далее уже нет обращения к серверу.

Таким образом, снижается нагрузка на сервер, информационные потоки равномерно распределяются по сети (обмен данных между клиентами), а не стекаются все к ЦОДам. Побочный положительный эффект- с теми же ДОС-атаками проще будет справиться.

В предельном варианте реализации и БД можно по торрент-сети «размазать», так что сервис из «облака» полностью уйдет «жить» на клиентах. Сервер нужен будет только как стартовая точка входа в торрент-сеть сервиса и как резервное хранилище данных.

Теги