Rambler's Top100
Статьи ИКС № 03-04 2016
Олег ФАТЕЕВ  25 апреля 2016

Лабиринты PaaS. Платформы облачной разработки

Услуги Platform as a Service – перспективный сегмент рынка, интересный не только облачным провайдерам, но и разработчикам программного обеспечения.

Олег ФАТЕЕВ, независимый эксперт по облачной разработке

Проблематика PaaS в России, к сожалению, практически не освещается – в отличие от IaaS и SaaS. Поэтому начнем с классического определения, данного американским NIST (National Insti­tute of Standards and Tech­nology). PaaS (Plat­form as a Service) – это модель предоставления облачных услуг, которая дает потребителю возможность разворачивать в облаке приложения, разработанные с использованием конкретных языков программирования, программных библиотек, сервисов и инструментов, поддерживаемых облачным провайдером. По­тре­бителю PaaS не требуется контролировать уровень облачной инфраструктуры IaaS (Infrastructure as a Service), но он имеет все возможности для управления, конфигурирования и развертывания разработанных приложений, которыми может пользоваться сам или предлагать своим конечным пользователям по модели SaaS (Software as a Service).

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

PaaS и IaaS

Рассмотрим, чем отличаются возможности PaaS и IaaS, на примере работы с облачными базами данных (такие сервисы предоставляют сегодня многие операторы облаков).

В случае PaaS платформа берет на себя все заботы по управлению облачной инфраструктурой (программной и аппаратной). Вы как потребитель просто пользуетесь сервисом, концентрируясь на предметной части своей задачи. Вы формируете высокоуровневый запрос на использование, указывая, что вам нужна база данных SQL или NoSQL, нужен такой-то тип хранилища. А уже платформа прозрачно для вас выполняет операции по созданию и конфигурированию виртуальных машин и развертыванию на них нужных СУБД. У вас нет непосредственного доступа ни к виртуальным машинам, ни к этим СУБД.

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

Основные преимущества PaaS лежат в плоскости стоимости и практического удобства:

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

PaaS используется для быстрой разработки, прототипирования, проверки гипотез. А на IaaS вы переходите, когда нужно выводить ваш сервис в продуктив. Таким образом, PaaS и IaaS могут быть полезны на разных этапах жизненного цикла продукта. Если вы создаете сервис для внутреннего потребления, то PaaS так и останется единственной опцией.

Выбирая PaaS-сервис SQL или конкретную СУБД SQL из доступных шаблонов IaaS, вам не приходится менять свои привычки в разработке, ваши программистские навыки применимы в обоих случаях. Не является даже принципиально важным, что вы используете в продуктиве, а что в разработке.

Очень часто вы манипулируете с тремя опциями: локальная СУБД, СУБД на виртуальных машинах в облаке, СУБД в виде сервиса PaaS. Это позволяет в итоге выбрать оптимальное конечное решение – или же и дальше использовать весь этот микс.

Выгоды использования

Концепция DevOps

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

Поэтому сейчас в разработке преобладает концепция DevOps (Development and Operations) – методология, ориентированная на тесную интеграцию процессов разработки, процедур развертывания и эксплуатации программных продуктов, чтобы можно было их быстро создавать и оперативно вносить любые изменения, не прерывая работу пользователей. Частота выходов новых версий и обновлений продуктов становится серьезным конкурентным фактором. Сегодня уже никого не удивишь тем, что облачный сервис обновляется даже в течение дня, при этом находясь в активном использовании. Определенные обновления могут делаться только для конкретного набора экземпляров облачного сервиса, не затрагивая другие его экземпляры.

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

PaaS обеспечивает интегрированность разработки и развертывания облачных сервисов, которые исходно представляют собой комплекс компонентов из разных источников, таких как серверы приложений, СУБД, BI и т.п. PaaS берет на себя заботу об интеграции и совместной работе всех компонентов, обеспечивает выделение им достаточного, но не избыточного, количества облачных ресурсов. Включение в PaaS средств тестирования и автоматизации обеспечивает полноту всего цикла облачной разработки. И во главу угла при этом ставится задача минимизации затрат на каждом этапе и для всего цикла в целом.

P a a S   в   ц и ф р а х

Статистики и прогнозов по рынку платформенных сервисов в открытом доступе не слишком много. Согласно исследованию компании TBR, объем рынка PaaS составил $7 млрд в 2014 г. и  ежегодно увеличивается на $1 млрд. К 2018 г. он может достигнуть $11 млрд. Возможно, эти цифры не так впечатляют, как показатели рынка SaaS и IaaS, но ведь они показывают, по сути, емкость того сегмента облачного рынка, который ориентирован исключительно на разработку.

Открытое сообщество профессиональных консультантов Wikibon на 2016 г. оценивает доходы вендоров публичных PaaS в размере $2,8 млрд и прогнозирует в ближайшие 10 лет взрывной рост этих доходов более чем в 20 раз – к 2026 г. их объем достигнет $68,3 млрд. 

Удобство для разработчиков

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

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

PaaS может предоставлять разработчикам различные интерфейсы доступа и управления: командную строку, интегрированную среду разработки IDE, доступ через веб-браузер или через REST API (REpre­sen­tational State Transfer). Наиболее продвинутые сервисы PaaS предоставляют все четыре опции.

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

Использование PaaS в публичных облаках актуально и тогда, когда трудно спрогнозировать нагрузку и необходимо обеспечить совместную работу множества программистов, находящихся в разных местах и занимающихся разными проектами.

Ключевые критерии выбора PaaS

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

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

Гибкость настройки. Ряду проектов требуется серь­езная кастомизация, т. е. настройка PaaS под эти проекты. Естественно, PaaS различаются количеством компонентов, которые могут быть кастомизированы, и способами, которыми могут быть сделаны изменения в компонентах.

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

Возможности миграции. Существенный фактор при выборе PaaS – возможность переноса приложений в облако. Разные PaaS имеют свои ограничения по миграции и предъявляют определенные требования к переносимым приложениям. Приложения могут существовать либо только в бинарных модулях, когда нет никакого доступа к исходному коду, либо могут быть жестко завязаны на API и платформу конкретного вендора, в этом случае задача миграции может оказаться непростой. Если используются стандартизованные средства уровня middleware и runtime, и если к тому же это open source, то миграция значительно упрощается. А если приложения построены в микросервисной архитектуре в расчете на тот или иной формат контейнеризации, то миграция, как прямая, так и обратная, становится простой стандартной процедурой.

Универсальность (частный и публичный сервис). Если есть жесткие требования информационной безопасности и приложение разрабатывается для нужд конкретной компании, то правильный выбор – частный PaaS. Частные облака обеспечивают полный контроль над всеми ресурсами PaaS. Если важнее стоимость и гибкая масштабируемость решения, то обычно проще использовать публичный PaaS, не компрометируя при этом безопасность, так как облачные операторы ради конкурентоспособности всегда стремятся поддерживать высокий уровень безопасности. Иногда более удобна гибридная модель, когда одна и та же PaaS-платформа используется и в облаке провайдера, и развернута внутри компании.

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

Популярные PaaS

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

Microsoft Azure. Стремительно растущий публичный сервис. Появившийся изначально как PaaS, Azure был расширен потом до уровня IaaS. На его примере хорошо видно, как сейчас стираются границы между этими категориями. PaaS от Microsoft имеет два варианта: Azure Websites и Azure Cloud Services, второй вариант реализует классический PaaS-подход. Azure Cloud Services поддерживает родную для Microsoft платформу .NET, а также Node.js, PHP, Python, Ruby. В качестве PaaS-опций для работы с базами данных предлагается Azure SQL Database, Azure SQL Table Storage, Azure Blob Storage. Имеются аналитические средства для работы с большими данными, мобильный бэк-энд и интернет вещей IoT. Разработчики могут выбирать между видами хранилищ, им доступен портал или интерфейс командной строки, средства балансировки, автомасштабирования и мониторинга.

AWS Elastic Beanstalk. Как и Azure, сервис от Ama­zon – наиболее известный публичный PaaS. Он поддерживает Java, Python, Ruby, Perl. В качестве опции для работы с базами данных AWS предлагает RDS (Rela­tio­nal Database Service). Поддерживаются средства мобильной аналитики и мобильного бэк-энда. К недостаткам PaaS от Amazon можно отнести высокие накладные расходы по ресурсам при его использовании, зачастую более выгодно выбирать IaaS-опции для решения аналогичных задач.

Google App Engine. Сервис был запущен в 2008 г., положив начало эре PaaS. Ориентирован на распределенные веб-приложения и на использование Java, Python, PHP и Go. Этот PaaS предоставляет управляемую среду исполнения, которая гарантирует масштабирование, но только при выполнении определенных условий проектирования. Предоставляется свое транзакционное хранилище. Из недостатков – необходимость использовать проприетарный API. Доступен только в публичном облаке Google.

Heroku. Компания, звезда которой взошла в 2008 г., сыграла важную роль в истории PaaS. Ее успех был во многом связан с использованием GitHub в качестве репозитария и системы контроля версий и Ruby on Rails в качестве языка программирования и фреймворка для разработки. В 2010 г. Heroku была куплена Salesforce.com, а в следующем году в нее перешел создатель языка Ruby японец Юкихиро Мацумото (Matz). Кстати, слово heroku было придумано им же, но задолго до появления компании, оно составлено из слов hero (герой) и haiku (хайку, японский поэтический жанр). Сейчас помимо Ruby эта платформа поддерживает Java, Node.js, Scala, Clojure, Pathon и PHP. Ориентирована на создание распределенных приложений и работает только в публичных облаках. Существующие сложные приложения для работы на платформе Heroku требуют изменений в коде.

IBM Bluemix. Базируется на известной PaaS-тех­нологии Cloud Foundry, как и ряд других коммерческих PaaS, и размещается на инфраструктуре облака IBM, называемого SoftLayer. По своим возможностям близок к Azure и AWS, но уступает им по распространенности. Есть версия для частных облаков.

Red Hat OpenShift. Представитель PaaS-платформ с открытым исходным кодом, ориентирован на использование контейнеров. Хорошо поддерживает парадигму DevOps и автоматизацию процессов CI/CD (Con­tinuous Integration/Continuous Delivery). Требует высокой квалификации как разработчиков, так и администраторов. Поддерживает Jave EE и ориентирован на создание корпоративных приложений. Может быть развернут и в публичных, и в частных облаках.

Jelastic. Изначально платформа разрабатывалась в расчете на экосистему Java (Jelastic = Java Elastic). Но в настоящее время поддерживает многие языки программирования и средства разработки: Java, Java EE, .NET, PHP, Ruby, Node.js, Python + Docker, а также разнообразные СУБД: MySQL, MariaDB, Neo4j, PostgreSQL, MongoDB, Cassandra, Redis, MSSQL. Работает в различных облаках: публичных, частных, гибридных. Может быть развернута даже на ноутбуке. Простая миграция существующих приложений в облако без необходимости менять код, так как нет привязки ни к какому проприетарному API. Вертикальное и горизонтальное масштабирование в условиях пиковых нагрузок, живая миграция. Поддерживает парадигму DevOps и микросервисы.

 2 5   н а и б о л е е   и з в е с т н ы х   P a a S

 

 

      Продукт

              Возможности

  В каком облаке развертывается

       Сайт

ActiveState Stackato (ныне HP Enterprise Helion Stackato)

App Containers, aPaaS, DBaaS

Частное у провайдера, частное у клиента, гибридное

stackato.com

Apprenda

App Containers, aPaaS, DBaaS, MBaaS

Частное у клиента, гибридное

apprenda.com

AWS Elastic Beanstalk

App Containers, aPaaS

Публичное

aws.amazon.com

CenturyLink AppFog

App Containers, aPaaS, DBaaS

Публичное

centurylinkcloud.com

Clever Cloud

App Containers, aPaaS, DBaaS

Любое

clever-cloud.com

cloudControl

App Containers, aPaaS, DBaaS

Публичное, частное у клиента

cloudcontrol.com

Engine Yard

App Containers, aPaaS

Публичное

engineyard.com

FatFractal

App Containers, aPaaS, DBaaS, MBaaS

Публичное, частное у клиента, гибридное

fatfractal.com

Google App Engine

App Containers, aPaaS

Публичное

cloud.google.com

Heroku

App Containers, aPaaS, DBaaS

Публичное

heroku.com

IBM Bluemix

App Containers, aPaaS, iPaaS

Любое

bluemix.com

Jelastic

App Containers, aPaaS, iPaaS

Любое

jelastic.com

Lunacloud

App Containers, iPaaS, DBaaS, MDD/RD PaaS

Публичное

lunacloud.com

Mendix App Platform

aPaaS, DBaaS, MDD/RD PaaS

Любое

mendix.com

Microsoft Azure

App Containers, aPaaS, MBaaS

Публичное

azure.microsoft.com

Oracle PaaS

aPaaS, DBaaS

Публичное, частное на Oracle Exalogic, гибридное

cloud.oracle.com

Outsystems Platform

aPaaS, iPaaS, DBaaS, MBaaS, MDD/RD PaaS

Любое

outsystems.com

Pivotal Cloud Foundry

App Containers, aPaaS, DBaaS

Публичное, частное у клиента

pivotal.io

Red Hat JBoss Enterprise Application Platform for xPaaS

App Containers, aPaaS

Любое

openshift.com

Red Hat OpenShift

App Containers, aPaaS

Любое

openshift.com

Salesforce

App Containers, aPaaS, iPaaS, DBaaS, MDD/RD PaaS

Публичное

salesforce.com, force.com

SAP HANA Cloud Platform (in-memory PaaS)

App Containers, aPaaS, iPaaS, DBaaS, MBaaS

Публичное

sap.com

Progress Rollbase

aPaaS, MDD/RD PaaS

Любое

progress.com

WorkXpress PaaS

aPaaS, DBaaS, MBaaS

Публичное, частное у провайдера, частное у клиента

workxpress.com

WSO2 App Cloud

App Containers, aPaaS, DBaaS, MBaaS

Публичное, частное у клиента, гибридное

wso2.com

Примечания:

App Containers (контейнеры приложений) – изолированные пакеты приложений, абстрагированные от инфраструктуры. В разных PaaS могут использоваться разные технологии контейнеризации и виртуализации приложений;

aPaaS (Application Platform as a Service) – облачный сервис, обеспечивающий среду для разработки и развертывания приложений в облаке;

iPaaS (Integration Platform as a Service) – слой облачной платформы, который обеспечивает интеграцию и коммуникацию приложений между собой;

DBaaS (Database as a Service) – СУБД, предоставляемая для использования по облачной модели;

MBaaS (Mobile Backend as a Service) – связывает мобильные приложения с инфраструктурной частью облачных сервисов, обеспечивает удаленное управление мобильными приложениями и push-оповещение;

MDD/RD PaaS (Model-Driven Development/Rapid Development PaaS) – высокоуровневая разработка на основе моделей, скоростная разработка за счет высокой степени абстрагирования. Разработку могут вести не профессиональные программисты, а непосредственно специалисты в своей предметной области, оперируя знакомыми им категориями.


Будущее PaaS – микросервисы

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

С концепцией микросервисов связан ряд заблуждений. Многие думают, что это просто экземпляры одного сервиса, запускаемые в разных контейнерах, и что каждый экземпляр для своей работы требует минимальное количество ресурсов, поэтому он и «микро». Конечно, все значительно серьезнее. В основе микросервисов лежит целая парадигма программирования, называемая предметно-ориентированным проектированием (DDD – Domain-Driven Design), когда общая задача декомпозируется по предметным областям. А на этапе исполнения все микросервисы, полученные в результате превентивной декомпозиции и жестко никак не связанные, интегрируются между собой.

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

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

Микросервисный подход ускоряет и упрощает разработку, но при этом могут возникать проблемы с масштабированием и надежностью работы. Решение одной задачи может «растекаться» по разным вычислительным ресурсам. Простой запрос на чтение веб-страницы может обрабатываться одновременно разными микросервисами, работающими на разных виртуальных серверах, физических серверах, стойках в ЦОДах, даже территориально находящихся в разных местах. Чтобы избежать подобной бесконтрольности, нужно выбирать правильную платформу для создания и выполнения микросервисных приложений.

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

В условиях микросервисной архитектуры разработчики хотят быстро выпускать новые версии своих продуктов и проводить сравнительное тестирование версий. Межмодульные зависимости, условия масштабирования и политики безопасности описываются на уровне скриптов или конфигурационных файлов PaaS, это уменьшает необходимость ручного воздействия. При использовании PaaS, ориентированного на DevOps, можно экспериментировать с новыми версиями сервисов, при необходимости «откатываясь» на предыдущие.

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

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

                                                                                                                        *   *   *

Известный ресурс для разработчиков программного обеспечения DZone (свыше 1 млн зарегистрированных участников) провел опрос среди своих подписчиков, выяснив, какими облачными сервисами они в первую очередь пользуются. 60% используют именно PaaS, их оказалось даже чуть больше сторонников IaaS – 59% (можно было выбирать оба варианта одновременно). Результаты опроса свидетельствуют: программистам, перед которыми стоят задачи облачной разработки, без использования PaaS уже практически не обойтись. А сравнимый спрос на тот и другой сервис – при том что объем рынка IaaS сейчас в несколько раз больше PaaS – говорит о значительном потенциале роста услуг PaaS уже в самое ближайшее время. 

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: