Вознесение: приложения для облаковПарадигму облаков отличает ряд характерных черт.

  • Транзитивное получение ресурсов. Пользователь по запросу сразу получает доступ к вычислительным ресурсам и ресурсам хранения в соответствии с заключенным с провайдером сервиса соглашением (в том числе об оплате, если провайдер – коммерческая организация). Этот подход отличается от схем совместного использования ресурсов, таких как grid-вычисления, при которых пользователи выдают вычислительное задание, а затем оно остается в очереди до тех пор, пока не станут доступны требуемые ресурсы.
  • Нефедеративное предоставление ресурсов. Даже если имеющиеся ресурсы являются физически распределенными, они предоставляются одним провайдером. И опять-таки, в отличие от grid-вычислений, это не есть объединение ресурсов всей федерации независимых провайдеров.
  • Измеряемость ресурсов. Провайдер фиксирует объем использования вычислительных, сетевых ресурсов или ресурсов хранения и выставляет счета потребителям, если это коммерческое предприятие, либо контролирует справедливое использование и распределение ресурсов, если это общественная или государственная организация.

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

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

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

Вознесение: приложения для облаков

Выбор требуемой модели облака и сервиса

Выбор вариантов создания приложения для облака или переноса существующего приложения зависит от типа облака и способа его развертывания.

Частные облака

Если вы создаете частное облако, вы можете строить его как хотите. Конечно, вы должны купить и развернуть инфраструктуру, но затем вправе использовать ее как ферму виртуальных машин, реализуя модель IaaS (Infrastructure as a Service), либо выбрать платформу, которая подходит для реализации модели PaaS (Platform as a Service). Наконец, вы можете, работая по модели SaaS (Software as a Service), создать приложения, к которым через ваше частное облако будут получать доступ другие пользователи. Однако создание частного облака – задача непростая.

Во-первых, для этого требуется подходящая аппаратная инфраструктура: компьютеры, средства хранения и структуры межсоединений. Как правило, приходится уделять серьезное внимание организации связи ресурсов хранения с компьютерами, чтобы избежать узких мест при вводе-выводе, например можно делать это с помощью сетевой топологии типа «утолщенное дерево» (fat-tree), используя Fibre Channel или Infiniband.

Во-вторых, частное облако должно иметь программную инфраструктуру для предоставления ресурсов ее пользователям. Такая инфраструктура – это нечто большее, чем обычный портал для распределения виртуальных машин. Так, программная инфраструктура должна предоставлять пользователям возможность запрашивать некоторое число виртуальных машин и некоторое количество памяти, задавать контент виртуальной машины и загружать любое требуемое программное обеспечения, а также управлять виртуальными машинами. Пользователи должны иметь возможность передавать данные в облако и получать из него обработанную информацию. Зачастую может предусматриваться возможность перемещения виртуальных машин в рамках физической инфраструктуры в зависимости от распределения нагрузки.

Существует несколько программных решений для инфраструктуры облака. Вероятно, самое известное из них – это Eucalyptus, поскольку оно ориентировано на поддержку совместимости с Amazon Web Services (AWS) и предлагает те же самые команды и прикладные программные интерфейсы. Среди других решений можно отметить Enomaly и OpenNebula.

Публичные и гибридные облака

Если вы предпочитаете гибридный подход, ваш выбор ограничен возможностями, предоставляемыми провайдером внешнего облака, с которым вы сотрудничаете. К таким ограничениям, в частности, относится способ поддержки совместимости между облаками.

И в публичных, и в гибридных облаках вам необходимо проанализировать гарантии качества обслуживания и соглашения об уровне обслуживания, предлагаемые провайдером. Если ваше приложение должно находиться в состоянии готовности в течение 99,99% времени, это необходимо прописать в вашем соглашении с провайдером.

SaaS

Когда провайдер облака предлагает готовое к работе приложение по модели SaaS, то остается не так уж много возможностей его настроить, однако для одних приложений такие настройки необходимы, а для других они могут и не потребоваться. Как бы то ни было, вам уже не надо разрабатывать новое приложение, но придется адаптировать приложение SaaS к своим нуждам. Такая настройка ничем не отличается от того, что сегодня делают консультанты, предлагающие компаниям новое корпоративное программное обеспечение вроде ERP. Эта настройка часто выполняется вместе с провайдером облака или самим провайдером.

Ситуация меняется, когда SaaS-приложение – это пакет разработки программного обеспечения, такой как в случае с Force.com. С помощью подобных сред SaaS пользователи могут разрабатывать полнофункциональные облачные приложения, задействуя программные средства провайдера. Однако пользователи Force.com будут работать только в программной среде Salesforce.com.

IaaS

Модель IaaS предоставляет разработчикам больше гибкости. До тех пор пока вы можете размещать приложение в виртуальной машине, поддерживаемой провайдером облака, и вместе с ним все требуемые библиотеки и зависимые компоненты, вы в достаточно большой степени свободны в своих действиях. Основные ограничения будут связаны с поддержкой образов виртуальных машин. Например, если приложение требует ОС Windows, провайдер должен предложить образы виртуальных машин с этой системой, и такие ограничения ничем не отличаются от требований, выдвигаемых разработчикам системными администраторами корпоративных сред.

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

Модель IaaS имеет ряд особенностей, которые разработчики должны учитывать.

Поддержка параллелизма. Все больше и больше приложений начинают использовать параллелизм, и даже обычная настольная система или мобильный компьютер могут одновременно запускать более двух приложений, поэтому разработчики должны убедиться, что провайдер облака поддерживает модель одновременной работы программ. Скажем, если вы используете OpenMP, то на предоставляемой вам облачной платформе должны работать нужные вам библиотеки. Особое внимание следует обратить на приложения с интенсивной обработкой данных, которые требуют параллельного ввода-вывода. Например, поддерживается ли ввод-вывод MPI-2?

Для того чтобы работа в облаке была по-настоящему эффективной, разработчики, использующие IaaS, должны даже в большей степени, чем в случае настольных приложений, быть уверенными в том, что производительность, которой они добиваются за счет параллелизма, соответствует их ожиданиям.

Нюансы ввода-вывода. В модели IaaS данные, размещаемые в виртуальной машине, не хранятся постоянно и теряются, когда виртуальная машина завершает работу, они могут быть даже утрачены при сбое в ее работе. Разработчикам нужно хранить такие данные отдельно и передавать их в виртуальную машину только тогда, когда это требуется. Более того, если приложение имеет особые требования к вводу-выводу, убедитесь, что провайдер IaaS действительно может обеспечить необходимую производительность.

PaaS

По-видимому, именно PaaS большинство разработчиков имеют в виду, когда говорят о «программировании для облака». Инфраструктура PaaS дает программистам средства разработки, необходимые для создания программ в этой специфической инфраструктуре. Обычно эти инструменты представляют собой наборы библиотек и API, которые дают доступ к вычислительным ресурсам и ресурсам хранения.

Язык программирования. Разработчики должны использовать язык программирования, который поддерживает провайдер PaaS. Например, Google App Engine поддерживает Java и Python. Продукт Microsoft Azure позволяет работать с любым языком, который поддерживает .net с помощью соответствующих подключаемых модулей Visual Studio, а также с любым другим языком (в том числе Java), если код выполняется в Windows.

Платформы. Поддержка языка программирования мало значит без поддержки библиотек и платформ.

Google App Engine поддерживает среду времени исполнения Java 6, поэтому здесь имеются библиотеки среды времени исполнения и поддерживаются стандартные серверы java.net и JCache. В состав интерфейса Python входит стандартная библиотека Python (версии 2.5), можно также использовать популярную платформу Web-разработки Django для Google App Engine (хотя, возможно, придется внести изменения в код).

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

Абстракции программирования. Платформы PaaS предоставляют специфические абстракции, такие как хранение данных и доступ к ним, запросы на данные и очереди сообщений. Эти абстракции должны быть похожи на те, что вы используете (например, в PaaS постоянные данные обычно хранятся в «блобах» (Binary Large Object, BLOb) или в bucket (сегментах памяти) вместо обычных для файловых систем файлов), однако в каких-то деталях они различаются, и это может ограничить их переносимость между разными провайдерами PaaS.

На более высоком уровне платформы PaaS могут поддерживать парадигмы программирования, которые отличаются от традиционных. Например, MapReduce – парадигма программирования, базирующаяся на хорошо известных принципах функционального программирования и позволяющая передавать данные, сначала назначив вычислительные узлы, с тем чтобы установить соответствие входных и обработанных значений, а затем объединить результаты. Такой подход может оказаться вполне эффективным, и о нем давно уже говорят как об очередном существенном изменении в парадигме ИТ и как о решении, более предпочтительном, чем традиционная обработка баз данных.

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

***

Провайдеры облачных сервисов постоянно выпускают новые решения, так что в определенном смысле бесполезно пытаться рисовать полную картину состояния дел в этой области, тем не менее, для иллюстрации, в таблице приведены сведения по четырем основным на сегодняшний день провайдерам облаков и даны некоторые ключевые характеристики их сервисов. Эти провайдеры предлагают решения во всем спектре: IaaS, PaaS и SaaS.

Вознесение: приложения для облаков

Облака – далеко не новая парадигма, и на самом деле в ней собраны технологии, достигшие зрелости и поддерживаемые рыночной конъюнктурой. Сегодня не существует единого представления об облаке, единого способа реализации вычислений в нем или способа разработки приложений. ИТ-индустрия пережила немало периодов неоправданных восторгов и разочарований, но облака, похоже, не тот случай — многое из программного обеспечения сейчас работает в облаках, и еще больше будет там работать в будущем. Разработчикам уже предлагается весьма широкий выбор реализаций облаков, вариантов развертывания и различных подходов к программированию. Как всегда, тщательный анализ требования своих приложений в начале проекта может уменьшить неопределенность и спустить решение для облака с небес на землю.

Панос Лоридас (louridas@grnet.gr) – консультант Greek Research and Technology Network, научный сотрудник Афинского университета экономики и бизнеса.

Panos Louridas. Up in the Air: Moving Your Applications to the Cloud, IEEE Software, July/August 2010, IEEE Computer Society. All rights reserved. Reprinted with permission.

Программное обеспечение: путь в облака

Идеи сорокалетней давности, заложенные в мэйнфреймы, сегодня вернулись к нам на совершенно другом уровне и оказались востребованными в облачных вычислениях. Облака становятся все более популярными, однако неясно, выгодна ли облачная модель производителям ПО?

С точки зрения компьютерных технологий принцип вычислительных облаков не привнес в наш мир ничего принципиально нового – программное обеспечение, предоставляемое как сервис (SaaS), существовало и раньше, только называлось иначе: Web-приложениями, программами, работающими через Интернет. Действительно, весь мир давным-давно хранит личную корреспонденцию на удаленных серверах провайдеров электронной почты, и только сегодня оказалось, что происходит это в облаках.

В мэйнфреймах 60-х–70-х годов был реализован принцип предоставления ресурсов по запросу, что соответствует облачному термину «инфраструктура как сервис» (Infrastructure as a Service, IaaS). Тогда же начали использовать и популярную нынче виртуализацию, поскольку ресурсы были достаточно дорогими и возникла необходимость в их оптимальном распределении и контроле. Однако с возникновением персональных компьютеров стало возможным разделить рабочую нагрузку между компьютером и сервером, и задачи оптимизации отошли на второй план.

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

Однако, выгодна ли облачная модель производителю ПО? Институт лицензирования становится ненужным в условиях облаков, и требуется пересмотр всего бизнес-процесса. Тем не менее разработчики ПО обнаружили и преимущества новой модели.

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

В корпорации Microsoft поначалу не торопились создавать программное обеспечение для работы в облаках – попытки Google предоставить офисные приложения по запросу, начатые еще в 2005 году, казались несерьезными, однако неожиданно Google Apps и Google Docs стали оттягивать клиентов традиционного ПО. Обнаружилось, что предприятия вполне могут обходиться без собственного парка компьютеров и приобретения лицензий на офисные приложения. Ярким примером может послужить городская администрация Лос-Анджелеса, где недавно официально перешли на Google Apps. В результате с 2007 года лидер лицензионного ПО начал работу над проектами в облаках.

Прежде всего, нужна была облачная операционная среда, которой и стала Windows Azure, предоставляющая компьютерные ресурсы по запросу. На платформе Windows Azure пользователи могут создавать свои приложения, пользуясь привычными средствами разработки, например Visual Studio, и давно апробированными технологиями, например .net, что привлекло многих потенциальных корпоративных пользователей. Отдельным продуктом в рамках Windows Azure стал SQL Azure, с помощью которого можно создавать и поддерживать в облаках реляционные базы данных. Созданные облачные системы могут быть интегрированы с традиционными программами посредством модуля AppFabric, обеспечивающего защищенную передачу данных. Платформа Azure поддерживает протоколы SOAP, REST, XML, PHP, и с ее помощью может быть воплощен код, обеспечивающий бизнес-логику предприятия.

Однако в облаках важны не только технологии – для предоставления облачных сервисов требуется иная бизнес-модель, отличная от лицензирования и продаж программ в коробках. В качестве примера можно привести стоимость на сервисы, предоставляемые Microsoft: вычисления – 0,12 долл./ч, хранение данных – 0,15 долл./Гбайт/мес., загрузка данных – 0,1 долл./Гбайт.

На базе Azure возможно создание офисных приложений по запросу, которые теперь доступны в рамках работающей в режиме онлайн системы Windows Live, позволяющей создавать документы в форматах Word, Excel и PowerPoint. В дополнение к облачному сервису система позволяет открыть онлайн-документ на десктопе с помощью традиционного ПО, однако часто для этого требуется установить на компьютере самую свежую версию: благодаря облачным продуктам компании могут попутно продвигать и лицензионное ПО, по крайней мере на время, пока пользователи будут работать по старинке.

Еще в 1998 году корпорация Oracle провела тестирование облачной модели и попыталась выйти с ней на рынок. Речь шла, например, о бухгалтерской системе по запросу по цене 99 долл. в месяц, но подписчиков тогда оказалось немного. Возникли проблемы защиты, зависимости от провайдера, обеспечения конфиденциальности, рентабельности и др. Однако в 2007 году, с ростом популярности виртуальных машин, Oracle сразу включилась в игру, предложив образы виртуальных машин с предустановленным программным обеспечением собственной разработки. В 2008 году конечные пользователи смогли запустить продукты Oracle на Amazon.com.

Схема оплаты Amazon позволяет учесть стоимость услуг третьих сторон, в частности разработчиков ПО. Оплата состоит из двух частей: за использование инфраструктуры и за другие облачные услуги. Модель довольно проста в применении — специалистам Oracle достаточно установить СУБД и сделать ее образ в облачной среде Amazon. Образ регистрируется как коммерческий, а остальное выполняет система взаиморасчетов Amazon, которая ведет учет времени его фактической работы. Доходы делятся между Amazon как провайдером инфраструктуры и Oracle, которая в этом случае является провайдером ПО. Данная модель позволяет Oracle сохранить существующую бизнес-модель оплаты лицензии на каждую инсталляцию, а Amazon просто предоставляет контейнер, который можно наполнить любыми сервисами.

По сей день компанией Oracle предоставляются в облаках услуги по установке и использованию своих СУБД, а также по архивированию и хранению данных, и тем не менее такая модель не является самой эффективной – у провайдера нет полного контроля над ПО. Гораздо привлекательнее выглядело бы предоставление облачных услуг без посредников, когда нет накладных расходов на дополнительную операционную систему. К тому же у разработчика остается больше возможностей для контроля и сбора статистики, которая позволяет делать прогнозы о популярности той или иной услуги. Покупка Oracle компании Sun Microsystems имела стратегическое значение для развития направления облачных вычислений. Благодаря облачным технологиям Sun, Oracle сможет интегрировать инфраструктуру и программное обеспечение по запросу в единое целое.

Для конечных пользователей SAP облачная модель чрезвычайно привлекательна – установка и обслуживание нескольких тематических пакетов SAP обходится сегодня заказчику в сотни тысяч, а то и миллионы долларов, причем независимо от того, насколько интенсивно используется тот или иной пакет. В SAP начали исследовать облачную модель приблизительно с 2008 года, но пока речь не идет о полной замене лицензирования пакетов, в которые уже вложены инвестиции как со стороны SAP, так и со стороны конечных пользователей. Компания планирует только частичное введение облачных услуг, объединяя традиционные системы и дополняющие их сервисы в одну экосистему, что позволит осуществлять между ними обмен данными.

Неудивительно, что SAP, как и Microsoft, вынужденно смотрит в сторону облаков – рынок не стоит на месте, возникают новые провайдеры, предоставляющие услуги по запросу, аналогичные набору функций пакетов SAP. Например, для CRM-модуля таким конкурентом стала компания Salesforce, уже захватившая миллионную армию интернет-подписчиков. Онлайн-альтернативы финансовому и кадровому пакетам предоставляет компания Workday.

Корпорация IBM далеко не новичок на рынке облаков. Так, в 2006-2007 годах IBM Research предоставила вычислительные мощности по требованию Research Compute Cloud для корпоративных пользователей. Используемые вычислительные ресурсы были распределены по всему миру и представляли собой самое настоящее внешнее облако. Параллельно IBM предлагает консалтинговые услуги по оптимизации и виртуализации внутренней структуры предприятий. В то же время в рамках инициативы High Performance On Demand Solutions было реализовано облачное пространство, работающее в бизнес-парке в Китае. Этот любопытный и успешный проект финансировался правительством Китая для того, чтобы компании-стартапы смогли получить вычислительные ресурсы без больших вложений в оборудование и ПО.

Сегодня IBM переносит ряд своих приложений в облака, и наиболее известный пример – Lotus Notes, облачная версия которого доступна в решении LotusLive.

Компания постепенно подводит своих пользователей к работе в публичных облаках, например, промежуточными стадиями между клиент-серверной реализацией Lotus Notes и облачной LotusLive можно считать Lotus Quickr (ранее Quick Place) и Connections. Эти приложения, воплощенные на базе технологий WebSphere и Domino, берут на себя функции хранения данных на корпоративном сервере и поддержки коллективной работы внутри компании благодаря развернутой системе уведомлений. Однако эти приложения напрямую взаимодействуют с сервером через браузер, то есть работают они еще не в облаках, а с применением внутреннего оборудования, чтобы пользователи привыкли работать с данными удаленно. Следующей ступенью является продукт LotusLive, функционирующий во внешних облаках, и для многих бизнес-пользователей его возможностей вполне достаточно. Тем не менее в LotusLive пока еще не доступна сложная бизнес-логика, которую можно воплотить в традиционной среде Lotus Notes.

***

Вычисления в облаках – это только идея, и разработчикам ПО приходится немало потрудиться, решая в рамках этой модели конкретные задачи, чтобы сохранить своих пользователей в будущем. Несмотря на то что на рынке появились продукты, работающие в облачной среде, время прощаться с традиционным программным обеспечением еще не наступило. «Баланс между традиционным ПО и облачным пока еще будет сохраняться, – считает Хазрет Сапенов, председатель конференции по облачным вычислениям CloudSlam 2010. – Объем инвестиций в коробочное или лицензионное программное обеспечение все еще значительный, и пользователи не готовы полностью перенести свои приложения в облака и довериться провайдеру. Тем не менее облачная модель развивается хорошими темпами, и постепенно конечные пользователи все же перейдут в облака».

Ольга Топровер (olga.toprover@mail.ru) – независимый обозреватель (Лос-Анджелес, США).

Создание приложений средствами Force.com

Утверждается, что Salesforce.com предложила облачные сервисы еще до того, как началось широкое обсуждение идеи облаков. Компания предлагает свою базовую платформу Force.com сторонним разработчикам, которые хотят создавать приложения на инфраструктуре Saleforces.com.

Force.com – это среда разработки высокого уровня, предлагаемая по модели SaaS и предназначенная для создания корпоративных приложений (хотя ее можно рассматривать и как инфраструктуру PaaS, где платформа является интегрированным пакетом разработки). Отличительная особенность Force.com – удобство использования и быстрота развертывания. Данная среда имеет архитектуру «модель – представление – контроллер», а разработчик описывает базовую модель данных, используя объекты и их взаимосвязи. Объекты видны через вкладки (во многом так же, как вкладки в традиционных диалоговых окнах, формах и Web-браузерах) в структуре страницы, которая создана в редакторе, имеющем стандартный интерфейс Salesforce. Кроме того, разработчики могут создавать настраиваемые интерфейсы с помощью инструментария Visualforce.

Управление в Force.com осуществляется через потоки заданий в соответствии с правилами, определяющими их инициацию и действия, такие как задачи, назначенные пользователям, обновления полей данных, уведомления электронной почты и сообщения, передаваемые внешним приложениям (например, другим Web-сервисам).

Приложения, созданные с помощью Force.com, ориентированы на данные. Разработчики начинают с описания объектов данных, взаимосвязей между ними и управления безопасным доступом. Операции определения данных и спецификации пользовательского интерфейса выполняются в Force.com одним щелчком мыши. Можно создать целое приложения, не написав ни строчки кода. Разработчики также могут использовать Apex – язык программирования в Force.com, представляющий собой строго типизированный объектно-ориентированный язык программирования, позволяющий разработчикам связывать бизнес-логику с системными событиями (действия пользователя, обновления данных и т.п.). Синтаксис Apex напоминает Java, но язык обеспечивает также интегрированную поддержку запросов на данные и работы с хранимыми данными, предлагая, таким образом, функции, аналогичные хранимым процедурам в традиционных приложениях баз данных.

Приложения Force.com лучше подходят для сред, работающих со структурированными данными, пользователи которых получают определенные роли (подобные ролям в организации) и используют бизнес-логику, поддерживаемую потоками заданий. Методика разработки знакома специалистам, создававшим приложения баз данных с помощью языков четвертого поколения. Хотя Force.com не является инструментом повседневной работы, при определенных условиях он может способствовать увеличению производительности.