Интеграция – основа облака

История облаков в их нынешнем понимании достаточно коротка, и интеграция в этой сфере делает лишь первые шаги. Казалось бы, совсем недавно, всего пять лет назад, Эрик Шмидт, в ту пору генеральный директор Google, представил на конференции по поисковым машинам Search Engine Strategies Conference перспективную, по его мнению, модель компьютинга, впервые назвав ее облаком, а сегодня облачные технологии становятся одной из важнейших составляющих ИТ. Помимо самого слова «облако» в идеях, озвученных Шмидтом 6 августа 2006 года, не было чего-то революционного и неожиданного — дух предвосхищения грядущих перемен уже витал в воздухе, и предшественников облаков было много (utility, autonomous, on-demand и т.п.), однако именно Шмидт вошел в историю тем, что нашел необходимое обобщенное определение и дал ему образное имя. В интервью после конференции он откровенно признал заслуги специалистов и компаний, развивавших это направление раньше: «Я отдаю себе отчет в том, что очень многие думали о чем-то подобном, но понимание не приходит сразу, требуется время, я считаю возникновение облачной модели объективным явлением, связанным с глобальной тенденцией; мы все и на индивидуальном, и на корпоративном уровне методично смещаемся в онлайн». Последующие события показали, что облака действительно оказались не маркетинговым трюком, как это нередко бывает.

Вслед за Шмидтом технологический проповедник Николас Карр сделал популярной аналогию между облаками и традиционными коммунальным системам снабжения, прежде всего электрическими сетями. Примерно через два года, в строгом соответствии с кривой неоправданного предвосхищения, или хайпа, началась массовая пропагандистская кампания. Теперь облака называли пятой коммунальной услугой после электричества, газа, воды и телефона. Однако между пропагандистами облаков и пользовательским сообществом образовалось очевидное рассогласование — многие пользователи не смогли сразу поверить в преимущества облаков и до сих пор остаются в положении бабушки из «Вороньей слободки» Ильфа и Петрова, которая жгла керосин, так как не доверяла электричеству. Их недоверие вполне оправданно: проблемы безопасности и непонимание процесса получения из облака ресурсов, аналогичных предоставляемым существующими корпоративными информационными системами, ведь логически они несравнимо сложнее, чем электричество, газ или вода. В результате, признавая достоинства облака как идеи, но не доверяя глобальным облакам, предприятия стали строить свои собственные, частные облака, если продолжить аналогию с электричеством — системы автономного питания.

На пятом году истории облаков стало ясно: глобальные облачные технологии набирают зрелости, и весомых причин для недоверия к ним становится все меньше. Вопреки прогнозам, неожиданно выяснилось, что казавшаяся наиболее острой проблема безопасности решается проще, чем можно было бы предположить, причем не столько техническими средствами, сколько руководствуясь соображениями обыденной житейской мудрости. Крупные провайдеры облачных сервисов с их неограниченными техническими и финансовыми возможностями могут обеспечить более высокий уровень безопасности данных, чем уровень, достижимый в условиях отдельно взятого предприятия. В конце концов доверяем же мы свои жизни авиакомпаниям, что уж говорить о данных. В связи с этим вспоминают высказывания Бенджамина Франклина («Тот, кто предпочтет безопасность свободе, не заслуживает и не получит ни того, ни другого») и Дуайта Эйзенхауэра («В поисках абсолютной безопасности мы доведем себя до банкротства»). Уже давным-давно люди поняли, что любая система безопасности является компромиссом, и важно лишь, чтобы он был осмысленным.

В то же время придать облаку необходимые потребительские качества оказалось гораздо сложнее, чем обеспечить безопасность. Задачу представления облаков в виде некоторого универсального резервуара вычислительных ресурсов и ресурсов хранения, из которого можно доставлять вычислительные сервисы и сервисы для работы с данными, то есть обеспечить обещанные коммунальные услуги, гораздо проще умозрительно поставить, чем решить. Для этого нужно как минимум научиться создавать гибридные облака, поскольку с самого начала произошло разделение на публичные и частные облака, имеющие вполне ограниченные ресурсы. Снять эти ограничения были призваны технологии cloudbursting («выброс облака»): так назвали концепцию перемещения в случае возникновения необходимости данных и приложений из частного облака в публичное облако, таким образом можно создавать временное гибридное облако. Следующим и более практичным шагом стало создание специальных средств интеграции облаков (Cloud-to-Cloud Integration, C2I).

На данный момент эволюционного развития облаков можно выделить две основные модели интеграции: одна предполагает интеграцию на уровне приложений и программных сервисов (SaaS), другая — на инфраструктурном уровне (IaaS) с использованием программ-посредников, называемых облачными брокерами (Cloud Brokerage). В первом случае предполагается интеграция программных ресурсов, предоставляемых провайдерами, и собственных программных ресурсов пользователей, а во втором — своего рода виртуализация любых облачных ресурсов и устранение привязки потребителя к конкретному провайдеру.

Интеграция на уровне приложений и программных сервисов ставит своей целью создание единой системы из разрозненных приложений и по своей функциональности аналогична традиционным системам интеграции приложений предприятия (Enterprise Application Integration, EAI). В отличие от этого, задача программных брокеров заключается в виртуализации облаков и в конечном счете сводится к интеграции инфраструктурных сервисов от разных провайдеров с использованием промежуточного слоя, изолирующего поставщиков от потребителей сервисов. Некоторые противопоставляют эти две модели, что, скорее всего, ошибочно — они взаимно дополняют друг друга.

Интеграция приложений и сервисов

Самые простые интеграционные решения этого класса предполагают использование традиционных средств EAI в двух близких по смыслу вариантах. В первом применяются интеграционные инструменты EAI/ESB, принадлежащие пользователю, — они находятся на стороне потребителя и от классических отличаются тем, что имеют в своем распоряжении специальные коннекторы, которые обеспечивают им доступ к приложениям, резидентным в облаке. Таким образом они могут интегрировать внутренние и внешние ресурсы, например, как в продукте Informatica PowerCenter. Второй вариант отличается использованием миграционных инструментов, расположенных в облаке, — пользователь арендует и приложения, и средства интеграции. В качестве примера можно привести тот же Informatica PowerCenter, но в версии Cloud Edition on Amazon EC2, согласно которой пользователи берут ПО компании Informatica в почасовую аренду.

Менее традиционные интеграционные решения на уровне SaaS можно рассматривать как следующий шаг в дальнейшем развитии сервисных архитектур. Иногда их еще называют интеграцией как сервис (Integration as a Service) или интеграцией по запросу (On Demand Integration). В них используются специально созданные SaaS-приложения, способные интегрироваться в пользовательскую среду вместе с другими облачными приложениями (например, Informatica On Demand Integration Services и отчасти IBM WebSphere Cast Iron Cloud Integration). В решениях этого типа используется одно из важнейших преимуществ сервисной архитектуры SOA — удобство и простота технологий сервис-ориентированной интеграции (Service Oriented Integration, SOI). Модули, реализующие сервисные функции, являются автономными, поэтому средствами SOI из них можно собирать необходимую сервисную экосистему, а далее внутри этой системы, комбинируя слабосвязанные сервисы в наборы, строить процессы более высокого уровня, соответствующие конкретным требованиям бизнеса. Такой подход обеспечивает более высокую гибкость и способность к адаптации, чем те свойства, которыми обладают классические, жестко связанные системы EAI. Вот почему SOA в свое время стала важнейшим инструментом для решения интеграционных проблем — SOA позволяет создавать гибкие системы за меньшую стоимость и с меньшим риском за счет превращения данных и приложений в форму сервисов. Сервисная модель упрощает взаимодействие между отдельными компонентами, главным образом за счет исключения необходимости в передаче состояния — достаточно передать от сервиса к сервису управление и соответствующие данные.

В современном представлении в SOA должны наличествовать три основных компонента:

• сервисная шина предприятия (Enterprise Service Bus, ESB) — основное связующее звено между сервисами, обеспечивающее оркестровку сервисов;
• шина данных предприятия (Enterprise Data Bus, EDB), объединяющая разнородные источники данных — это сервисный аналог систем интеграции информации предприятия (Enterprise Information Integration, EII);
• управляющий модуль (Connectivity Module), содержащий репозиторий основных составляющих SOA и организующий потоки работ и данных.

Принципы SOA естественным образом предполагают для облаков превращение всех поддерживающих технологий в сервисы, в таком случае любые приложения, начиная от простейших офисных и до корпоративных (SCM, CRM, ERP и др.) могут размещаться где-то в облаке и доставляться через Web c доступом через браузер. На рис. 1 показана идеальная схема, где вся корпоративная система реализована на сервисных принципах, по ней можно проследить взаимосвязь между отдельными компонентами.

Рис. 1. Корпоративная система на сервисных принципах

Среди продуктов, поддерживающих интеграцию данного типа, есть решения от крупных компаний, например BizTalk Internet Service Bus, FioranoMQ, Amazon SQS, проекты с открытыми кодами Hosted Mule ESB и OnlineMQ on the Clouds, в также решения, предлагаемые небольшими нишевыми компаниями Boomi, SnapLogic и Jitterbit.

Облачные брокеры

В июне 2011 года аналитики Gartner выступили с прогнозом, согласно которому еще недавно не существовавший сегмент рынка брокеров облачных сервисов (Cloud Services Brokerage, CSB) к 2015 году достигнет размера 100 млрд долл., что равно суммарному годовому обороту Oraclе и Apple. Такого фантастического скачка еще не было, но эксперты объясняют этот феномен способностью CSB заметно технологически ускорить распространение облачных технологий, преодолеть барьер негативного восприятия пользователями отдельных сторон облачных технологий и сломать стереотипы. Gartner называет три главных преимущества CSB: они избавят облачные технологии от сопровождавшего их до сих пор сомнения в безопасности; сделают облака доступными предприятиям малого и среднего бизнеса, заполнив существующий, несмотря на все декларации о гибридных облаках, разрыв между частными облаками, создаваемыми крупными предприятиями, и публичными, в основном востребованными у конечных пользователей; создадут эффективную «службу одного окна» для сервисов, предоставляемых разными провайдерами, что избавляет от привязки к одному провайдеру.

С этими аргументами нельзя не согласиться, но аналитики не копают глубже — рост с нуля до сотни миллиардов за считанные годы должен иметь более весомую причину, и она, скорее всего, состоит в происходящей сейчас смене фундаментальной парадигмы компьютинга в целом, переживающего очередной революционный период, иногда называемый переходом в пятое поколение. Не стоит путать поколения компьютинга с поколениями компьютерных технологий — это принципиально разные вещи (в одном случае речь идет о доступе к приложениям, а в другом — об элементной базе). Новые поколения компьютинга не отвергают предшествующие — они десятилетиями мирно сосуществуют с ними.

Собственно идея брокеров — необходимость в установлении связей между поставщиками сервисов и потребителями — не нова. В свое время силами Organization for the Advancement of Structured Information Standards (OASIS) была разработана концепция и стандарт Universal Description, Discovery and Integration (UDDI), но внедрению этой идеи тогда помешала неразвитость экосистемы – этот стандарт и поныне остается одной из самых непонятных вещей сервисной архитектуры. Из его описаний следует, что это рекомендации для публикации сервисов в каталогах с последующей выборкой из этих каталогов, но, несмотря на то что его поддерживали основные производители (участниками проекта были более 130 компаний), к 2006-2007 годам интерес к нему пропал. Скорее всего, UDDI оказался «туповат», он не соответствовал уровню сложности поставленной задачи, но из этого вовсе не следует, что нет потребности в более совершенном решении.

Первое поколение компьютерных систем безраздельно господствовало вплоть до начала 80-х, это были монолитные системы, все было в одном, пользователь получал доступ к приложению на мэйнфрейме и позже на мини-ЭВМ. С появлением локальных сетей, ПК и рабочих станций появились клиент-серверные архитектуры, произошло разделение — что-то делалось на сервере, а что-то на клиенте. В 90-е годы возникли веб-приложения, они даль импульс к зарождению сервисной идеи, воплощенной в SOA, это было совсем недавно, в середине 2000-х. Вполне логичным был следующий шаг, и в 2010-х на сцену вышли облачные сервисы. Однако их массовому восприятию мешает целый ряд обстоятельств, в том числе и те, о которых речь шла выше и избавиться от которых позволяют облачные брокеры.

Аналитики Forrester, в отличие от Gartner, делают прогнозы на более близкий период времени, считая, что первые реальные работы в области интеграции частных и публичных облаков и предоставления объединенных ресурсов и сервисов только начнутся в 2012 году. При этом предстоит еще пройти эволюционный период — все начнется с модели простых брокеров (simple cloud broker model), обладающих ограниченными возможностями автоматизации, и постепенно разовьется до уровня полных брокеров (full broker); такие автоматические брокеры будут выполнять роль специалистов (fixer), способных самостоятельно решать проблемы.

Рис. 2. Облачный брокер и провайдеры облачных сервисов

Еще год назад операции над облаками ограничивали технологии «выброса облака»; облачные брокеры — следующий шаг в том же направлении. Как показано на рис. 2, облачный брокер действительно выступает в роли посредника между поставщиками и потребителями сервисов. Несмотря на образность, слово выбрано не слишком удачно. Задача облачного брокера схожа с деятельностью биржевого брокера лишь в части распределения заказа между несколькими провайдерами внешних облаков — это программное обеспечение, которое помогает компаниям получить наибольшее преимущество от использования внешних облаков. В зависимости от требований он выполняет еще ряд полезных функций, выбирая ту или иную модель взаимодействия; например, может устанавливать ПО на компьютерах заказчика или предоставлять его на условиях аренды. Основные функции облачного брокера:

• обеспечение прозрачной для пользователя работы с различными провайдерами от лица заказчика на всех фазах (развертывание, мониторинг, биллинг), действуя как агрегатор сервисов;
• распределение работ между различными провайдерами и оптимизация соотношения цена/качество для выбора наиболее выгодных вариантов;
• управление резервированием виртуальных машин, размещенных у нескольких провайдеров, в понимании того, что реальные возможности любого отдельно взятого провайдера ограничены.

Появление брокеров можно рассматривать шире, чем просто создание интегрирующего посредника между поставщиками и потребителями услуг, – это еще и переосмысление сути облака и интеграция трех сторон, участвующих в процессе создания облачных сервисов: провайдер — владелец и оператор, специализирующийся на торговле сервисами, создающий автоматизированную безопасную коммунальную инфраструктуру предоставления сервисов; производитель ПО; консультант — третья сторона, обладающая экспертизой в сфере деятельности двух других и способная их объединить.

Рис. 3. Диаграммы Венна для облачной инфраструктуры

Если построить диаграммы Венна с участием трех сторон (рис. 3), то на попарных пересечениях получим:

• SaaS — место, где интеллектуальная собственность производителя ПО объединяется с инфраструктурой, предоставляемой как сервис;
• интегратор облаков — пространство работы системного интегратора или консультанта, помогающих предприятию перейти в облака;
• аутсорсинг бизнес-процессов — предоставление бизнес-процессов в качестве сервиса (Business Process as a Service, BPaaS).

Место облачных брокеров — на пересечении всех трех кругов.

Итак, роль облачных брокеров можно определить так:

• посредничество в предоставлении облачных сервисов (Cloud Service Intermediation) — предоставляемые сервисы строятся поверх существующих облачных платформ с усилением ряда качеств, включая безопасность и удобство управления;
• объединение (Cloud Service Aggregation) — предоставление сервисов из разных источников;
• арбитраж (Cloud Service Arbitrage) — выбор оптимальных сервисов.

***

Облачные брокеры способны преодолеть основной недостаток UDDI (отсутствие механизма, обеспечивающего необходимый динамизм). Сервисная модель востребована со стороны динамически развивающихся компаний и провайдеров сервисов — значит, между ними должен находиться посредник, способный уловить изменения, происходящие с обеих сторон. Однако, несмотря на радужные перспективы, до последнего времени в сегменте облачных брокеров действуют лишь небольшие молодые компании, такие как CloudKick, CloudSwitch, CohesiveFT, DeltaCloud, Elastra, enStratus, Kaavo, Layer7 Techologies, LTech, RightScale, Vordel и Zimory.