Особенности разработки в облаках

Безусловно, облака предоставляют потребителям ряд преимуществ. Во-первых, это экономия на содержании ИТ-инфраструктуры, которой у компании теперь может и не быть вовсе либо она будет сокращена до минимума. Во-вторых, доступ к облачным приложениям может осуществляться отовсюду, где есть Сеть. В-третьих, облачная модель позволяет переложить необходимость обязательной сертификации программно-аппаратного комплекса к требованиям  ФЗ-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-решений доставка и установка должны быть автоматизированы – «пробрасывать» десятки приложений для тысяч внутренних клиентов корпоративного облака вручную силами системных администраторов просто невозможно физически. Очевидно, что автоматизация – это то качество, которое должно роднить процесс доставки приложений в рамках компании с аналогичным процессом в публичном облаке. Да и вообще внутренние бизнес-процессы коммерческого и частного облака не сильно различаются. И там и там последовательность внутренних бизнес-процессов облака имеет одинаковый вид: «выбор услуги => выделение ресурсов под услугу => доставка и установка услуги => биллинг услуги => возможность дозаказа услуги пользователем самостоятельно => отказ от услуги и освобождение вычислительных ресурсов». Поэтому на массовом рынке востребованы стандарты, созданные специально под коммерческое предоставление облачных сервисов.

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