Безусловно, облака предоставляют потребителям ряд преимуществ. Во-первых, это экономия на содержании ИТ-инфраструктуры, которой у компании теперь может и не быть вовсе либо она будет сокращена до минимума. Во-вторых, доступ к облачным приложениям может осуществляться отовсюду, где есть Сеть. В-третьих, облачная модель позволяет переложить необходимость обязательной сертификации программно-аппаратного комплекса к требованиям  ФЗ-152  («О защите персональных данных») с потребителя сервисов на их поставщика. Вместе с тем значительно меняется сам процесс создания ПО, предоставляемого из облака, в зависимости от того или иного типа сервиса и инструментария, которыми располагает разработчик. Кроме того, возникает неочевидная, но весьма острая проблема доставки и развертывания облачных приложений на стороне пользователя. Википедия дает довольно удачную трактовку термина облаков — «технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис». В данной формулировке ключевыми являются понятия ресурс и сервис.

Категории сервисов

На данный момент наиболее распространено деление всех облачных решений на три (рис. 1) категории: инфраструктура как сервис (Infrastructure as a Service, IaaS), платформа как сервис (Platform as a Service, PaaS) и программа как сервис (Software as a Service, SaaS).

 

Рис. 1. Уровни абстракции облачных сервисов

 

IaaS – сервис, абстрагирующий пользователя от работы с аппаратными ресурсами. В самом простом случае любой владелец ЦОД может продавать ресурсы своих физических серверов. Хотя наиболее часто, конечно, эти сервисы предоставляют функциональность ресурсов виртуальных машин. Примеры подобных сервисов: Amazon (EC2), Windows Azure (VM Role), виртуализация от VMware, Parallels и др.

Разработчику облачных приложений модель IaaS, по сути, не приносит ничего нового – написание программы для работы на физическом компьютере на практике мало чем отличается от приложения для работы внутри виртуальных машин. Это и неудивительно, ведь виртуальные машины создавались таким образом, чтобы быть полностью прозрачными для ПО, которое работает под их управлением. Конечно, могут быть исключения, и разработчик может применять какие-то специфические технологии, предоставляемые той или иной платформой виртуализации для создания более эффективных программных продуктов. Например, организовать взаимодействие между программами посредством какого-то специфичного и оптимизированного канала связи — VMware Communication Interface, средств хранения данных (Shared Folders или специализированные подсистемы хранения данных) или формата распространения продукта (Virtual Appliances) и т. д. И чем больше подобных специфических технологий доступны разработчику в рамках решения IaaS, тем с большей вероятностью он пересекает нечетко определенную границу в область решений PaaS.

Различие между PaaS и IaaS не очевидно, но крайне важно. Термин PaaS получил широкое распространение позже, чем IaaS, и является логическим развитием исходных идей. Представим разработчика, который пишет обычное корпоративное или веб-приложение, которое выглядеть будет примерно следующим образом: база данных, веб-сервер и сервер приложения. Разработчик пишет приложение, покупает три виртуальные машины, на каждой из которых запускает соответствующий компонент (рис. 2).

 

Рис. 2. Отличие PaaS от IaaS в наличии стандартизованных служб для создания приложений

 

Когда приложение начинает жить и развиваться, количество пользователей растет, и в какой-то момент мощности одного веб-сервера может не хватить – потребуется приобрести и запустить несколько серверов, распределять нагрузку (рис. 3) между которыми будет какое-то решение по балансировке (Load Balancer).

 

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

 

А еще через какое-то время может перестать хватать мощностей сервера баз данных и потребуется увеличить мощность, к примеру выделив под нее ресурсы значительно более серьезного оборудования (рис. 4).

 

Рис. 4. Облачное приложения с ростом числа его пользователей неминуемо будет потреблять все больше ресурсов

 

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

Создатели PaaS-систем предложили разработчикам инструменты, посредством которых можно динамически управлять параметрами системы (рис. 5). Отсюда, собственно, и происходит термин PaaS – предоставление услуг платформы в виде сервиса. Яркими примерами таких сервисов могут служить Amazon Cloud Computing и Microsoft Azure, предоставляющие схожую функциональность:

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

 

Рис. 5. Совокупность инструментов в рамках платформы позволяет облачным сервисам масштабироваться «на лету»

 

Важно отметить наличие API и сред разработки, которые позволяют (кстати говоря, в значительной мере жертвуя переносимостью получившихся решений) создавать адаптирующиеся к изменяющимся внешним условиям приложения. Которые, кстати говоря, очень часто попадают в категорию SaaS.

На самом верхнем уровне абстракции в «облачном» стеке находятся решения категории SaaS, предоставляющие прикладные сервисы непосредственно конечным пользователям. Из наиболее ярких примеров таких решений можно назвать Salesforce.com, Microsoft Office 365 и Google Apps. Какие-то приложения создаются с использованием преимуществ IaaS и PaaS, какие-то разрабатываются в расчете на собственную инфраструктуру – здесь нет единых правил и каждый разработчик решает поставленные задачи исходя из текущей ситуации. Однако типичная проблема, возникающая у компаний — независимых разработчиков программного обеспечения, – организация каналов доставки своего сервиса. Причем здесь речь может идти как о доставке облачного приложения конкретному конечному пользователю в рамках компании (из корпоративного облака), так и о продаже сервиса через провайдеров. Возникает эта проблема в первую очередь из-за того, что прямые поставки услуг пользователям не всегда возможно организовать – требуются «посредники» в лице сервис-провайдеров.

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

Примеряем на себя

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

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

Недостатка, связанного с отсутствием специальных облачных сервисов, нет в PaaS — свобода здесь ограничена вполне конкретным инструментарием, с наличием которого разработчикам необходимо считаться. Да, работа в рамках PaaS потребует некоторого времени на изучение платформы, однако сделает облачную разработку более технологичной и позволит перенести опыт, полученный в процессе создания одного продукта, на другие облачные проекты. Однако ориентация приложений (а значит, и программистов) на одну платформу имеет очевидный минус: при миграции на другую PaaS-систему или при расширении функционала сервиса за счет опций, предусмотренных в рамках другой платформы, адаптировать приложение на новую основу не удастся. Его придется либо переписывать заново, либо кидать между двумя платформами мостик в виде API. Это, конечно, уменьшает главное достоинство облачного решения — масштабируемую производительность и общую надежность сервиса.

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

Самый интригующий момент связан с разработкой SaaS, где главным является правильная организация доставки клиенту облачных приложений. Сейчас уже ясно, что для enterprise-решений доставка и установка должны быть автоматизированы – «пробрасывать» десятки приложений для тысяч внутренних клиентов корпоративного облака вручную силами системных администраторов просто невозможно физически. Очевидно, что автоматизация – это то качество, которое должно роднить процесс доставки приложений в рамках компании с аналогичным процессом в публичном облаке. Да и вообще внутренние бизнес-процессы коммерческого и частного облака не сильно различаются. И там и там последовательность внутренних бизнес-процессов облака имеет одинаковый вид: «выбор услуги => выделение ресурсов под услугу => доставка и установка услуги => биллинг услуги => возможность дозаказа услуги пользователем самостоятельно => отказ от услуги и освобождение вычислительных ресурсов». Поэтому на массовом рынке востребованы стандарты, созданные специально под коммерческое предоставление облачных сервисов.

 

Средства разработки для облаков

Amazon Web Services (AWS). Ключевыми сервисами платформы являются Amazon EC2 (хостинг виртуальных машин на базе Xen) и S3 (хостинг данных). Помимо этих сервисов, AWS предоставляет:

  • Amazon EBS – блочное хранилище данных для виртуальных машин EC2;
  • Amazon CloudFront – CDN для распределенной доставки объектов S3;
  • Amazon MapReduce – готовая к использованию инсталляция Hadoop;
  • Amazon SimpleDB – распределенная нереляционная база данных;
  • Amazon Simple Queue Service – очередь сообщений;
  • и др.

Windows Azure. Платформа, предоставляющая почти аналогичный Amazon Web Serices функционал. Ключевыми сервисами платформы являются Windows Azure (на данный момент, установленная в вычислительных центрах Microsoft Windows 2008 с Hyper-V) и SQL Azure (SQL Server 2008 R2). Azure поддерживает два режима работы с приложениями: на уровне сервисов (WebRole/WorkerRole) и на уровне виртуальных машин (VmRole). Для упрощения разработки и отладки приложений, ориентированных на работу в Windows Azure, предоставляется Azure SDK, интегрированный с Visual Studio. Помимо базовых сервисов, Azure также предоставляет в распоряжение разработчика следующие иструменты:

  • Azure Table – нереляционная база данных (аналог Amazon SimpleDB);
  • Azure Blob – блочное хранилище данных (аналог Amazon EBS);
  • Azure Queue – инсталляция Microsoft Message Queuing;
  • Azure Drive — виртуальный диск для выполнения операций над файлами;
  • множество других инструментов, необходимых для создания приложенияй на платформе Windows Azure.

Force.com. Платформа Salesforce Force.com предназначена для быстрого создания SaaS-решений. Приложение должно быть написано практически с нуля для того, чтобы исполняться в рамках этой платформы. Разработка ведется на Oracle Apex и в оригинальной среде Visualforce. С одной стороны, использование широко распространенных технологий разработки является плюсом этой платформы и должно быть высоко оценено разработчиками, у которых есть опыт создания внутренних (in-house) приложений. С другой – использование этой платформы очень сильно привязывает разработчиков к данному решению на уровне исходного кода и вынуждает применять только конкретные инструменты. И, хотя решение является идеальным для пользователей Salesforce.com, которые хотят расширить функционал базового облачного сервиса, прочие сценарии могут быть не столь удобны.

Google App Engine (GAE) – платформа для разработки и хостинга масштабируемых веб-приложений. Интеграция происходит, как и в случае с Force.com, на уровне исходного кода и среды исполнения. Поддерживаемые языки программирования: Python, Java, все JVM-языки (Groovy, JRuby, Jython и др.) и Go. Аналогично большинству облачных платформ, GAE дает пользователям нереляционные базы данных, доступ к которым организуется через SQL-подобный язык GQL (ключевое отличие которого – невозможность делать операцию JOIN, из-за чего он становится неэффективным при распределении запроса по нескольким машинам). Google App Engine предоставляет множество удобных средств разработки, значительно упрощающих процесс создания масштабируемых приложений. Вместе с тем полученные решения сильно зависят от GAE и, по сути, приложение создается под эту платформу.

Jelastic. Небольшая компания Hivext сделала успешный шаг в направлении полноценного PaaS-сервиса, предоставляемого на территории бывшего СССР. Проект Jelastic финансируется фондом Runa Capital и представляет собой облачную платформу для разработки под Java и PHP. В состав платформы входит постоянно расширяющийся и бесплатный набор API для создания приложений. С их помощью создатель приложений может решать типовые задачи, такие как авторизация пользователей, раздача прав доступа, файловое хранилище и пр. Кроме того, в состав платформы входит графическая среда для управления приложениями и параметрами облачного окружения. В числе привлекательных опций – собственная технология балансировки внутренних ресурсов AppLogic и возможность вертикального масштабирования.

Application Packaging Standard. APS представляет собой два решения в рамках одной технологии. С одной стороны, это платформа для доставки приложений облачным способом, а с другой — инструмент для получения платы за пользование этими приложениями. В этой связи APS в большей степени ориентирован на поставщиков массовых облачных сервисов, для которых автоматизация доставки и установки SaaS жизненно важна в силу огромного количества клиентов. Запаковка приложений осуществляется специальным включаемым модулем на Eclipse. Технология APS интегрирована в продукты Parallels для хостинга и автоматизации облачных средств.

 

Максим Кузькин (maximk@parallels.com) — системный архитектор компании Parallels (Москва).

Купить номер с этой статьей в PDF