Модели сервисов облачных вычислений: Часть 2. Платформа как сервис

Узнайте, какие возможности предлагает концепция "Платформа как сервис" (Platform as a Service – PaaS), для того чтобы разработчики получили выгоду от использования облачных вычислений, а владельцы и руководители предприятий смогли заранее оценить поставщиков PaaS, сведя к минимуму потенциальную возможность катастрофических ошибок.

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

Дэн Орландо, главный исполнительный директор, Creative RIA

Дэн Орландо (Dan Orlando) – фотографияДэн Орландо (Dan Orlando) является признанным профессионалом в сообществе разработчиков корпоративных приложений. Его многолетняя деятельность в качестве консультанта и опыт работы с платформами Adobe, так же как и публикации на IBM developerWorks, Adobe Developer Connection и Amazon Web Services, очень востребованы лидерами отрасли. Дэн регулярно появляется в блоге на DanOrlando.com.



21.03.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Облачные вычисления: Основы

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

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

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

Часто используемые сокращения

  • API: интерфейс прикладного программирования (Application Programming Interface).
  • HTTP: протокол передачи гипертекста (Hypertext Transfer Protocol).
  • IDE: интегрированная среда разработки (Integrated Development Environment).
  • ROI: окупаемость инвестиций (Return On Investment).
  • SQL: язык структурированных запросов (Structured Query Language).
  • SSL: протокол защищенных сокетов (Secure Sockets Layer).
  • UI: пользовательский интерфейс (User Interface).

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

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

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

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

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

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

Хочу обратить ваше внимание на перекрестную матрицу концепций, приведенную в первой части данной серии статей. Эта информация также приведена в таблице 1.

Таблица 1. Перекрестная матрица концепций трех категорий облачных вычислений
Заменяемая парадигмаХарактеристикиОсновные понятияПреимуществаНедостатки и рискиКогда не стоит использовать
IaaSИнфраструктура как активОбычно не зависит от платформы; расходы на инфраструктуру разделяются и, следовательно, снижаются; соглашения SLA; оплата по факту использования; автоматическое масштабирование.Распределенные вычисления (grid computing), вычисления как коммунальная услуга (utility computing), вычислительный экземпляр (compute instance), гипервизор (hypervisor), выгрузка в облако (cloudbursting), вычисления с множественной арендой (multi-tenant computing), организация пулов ресурсов (resource pooling).Снижение капиталовложений в аппаратное обеспечение и трудовые ресурсы; снижение риска потери инвестиций; низкий порог внедрения; плавное автоматическое масштабирование.Бизнес-эффективность и производительность очень зависят от возможностей поставщика; потенциально большие долгосрочные расходы; централизация требует новых/других подходов к мерам безопасности.Когда капиталовложения превышают текущие расходы.
PaaSПриобретение лицензийПотребляет инфраструктуру облака; обеспечивает методы динамичного (agile) управления проектами.Стек решений (solution stack).Плавное развертывание версий.Централизация требует новых/других мер безопасности.Отсутствует
SaaSПрограммное обеспечение как актив (бизнеса и потребителя)Соглашения SLA; пользовательский интерфейс, предоставляемый приложениями тонких клиентов; компоненты облака; взаимодействие посредством API; не сохраняющий состояние (stateless); слабосвязанный (loosely coupled); модульный; семантическая совместимость.Тонкий клиент; клиент-серверное приложение.Снижение капиталовложений в аппаратное обеспечение и трудовые ресурсы; снижение риска потери инвестиций; плавное итеративное обновление.Централизация данных требует новых/других мер безопасности.Отсутствует

Основные компоненты PaaS

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

Для лучшего понимания этих двух компонентов рассмотрим их определения. Вычислительная платформа в своем простейшем виде представляет собой место, где может без проблем работать программное обеспечение, если оно отвечает стандартам этой платформы. Типичными примерами платформ являются: Windows™, Apple Mac OS X и Linux® для операционных систем; Google Android, Windows Mobile® и Apple iOS для мобильных вычислений; Adobe® AIR™ или Microsoft® .NET Framework для программных инфраструктур. Важно помнить, что мы не говорим о самом программном обеспечении, а только о платформе, на которой оно должно работать. Рисунок 1 поможет понять эти взаимоотношения.

Рисунок 1. Графическая интерпретация взаимоотношений между категориями облачных вычислений и элементами PaaS
Рисунок 1. Графическая интерпретация взаимоотношений между категориями облачных вычислений и элементами PaaS

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


Выбор поставщика

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

Вот несколько основных вопросов, которые, возможно, следует задать конкретному поставщику PaaS до подписания договора:

  • Какие инфраструктуры и языки поддерживаются? В идеале услуга PaaS должна поддерживать все инфраструктуры, основанные на предпочтительном для этой платформы языке.
  • Сколько приложений можно создать? Большинство поставщиков PaaS ограничивает количество создаваемых приложений на основании плана или пакета, на который вы подписались. Убедитесь в наличии плана или пакета, отвечающего вашим требованиям.
  • Какого рода содержимое разрешено? Инфраструктуры, поддерживающие PaaS, обычно оперируют концепцией под названием "вычисления со множественной арендой" (multi-tenant computing), когда много "арендаторов" "живут" на одном сервере, разделенные посредством экземпляров виртуальных машин, управляемых гипервизором. Поставщик PaaS может устанавливать определенные ограничения на виды приложений и содержимого, которые вы планируете разместить.
  • Базы данных какого типа поддерживаются? Ответ на этот вопрос очень важен, если имеются данные, которые вы будете переносить как часть приложения. Необходимо убедиться в том, что предлагаемая поставщиком база данных совместима с форматом, который вы намереваетесь использовать для импорта своих данных.
  • Поддерживается ли протокол SSL (HTTPS)? Это еще один важный фактор с точки зрения безопасности. Вы можете столкнуться с большими проблемами, если, запланировав ведение финансовых операций посредством ваших приложений, обнаружите, что протокол SSL не поддерживается.

Анатомия PaaS

Теперь, когда мы так продвинулись в изучении PaaS, давайте рассмотрим функциональные возможности, которые следует учитывать при сравнении поставщиков PaaS:

  • Инфраструктура разработки приложений. Надежная инфраструктура разработки приложений, построенная на широко распространенной технологии. В идеале нужно остерегаться потенциальной возможности попасть в зависимость от поставщика. В этом отношении обычно безопасным является использование технологии с открытыми исходными кодами, такой как Java™.
  • Простота использования. PaaS должна иметь простые в использовании WYSIWYG-программы с предустановленными виджетами, готовые компоненты пользовательского интерфейса и инструменты перетаскивания объектов (drag-and-drop), а также поддерживать несколько стандартных интегрированных сред разработки. Все это будет способствовать быстрой итеративной разработке приложений.
  • Инструменты моделирования бизнес-процессов (Business Process Modeling - BPM). Вам необходима надежная BPM-инфраструктура, позволяющая выполнять моделирование бизнес-процессов и создавать приложения на основе этой модели.
  • Доступность. Выбранная платформа должна быть доступна всегда и везде.
  • Масштабируемость. Платформа должна быть достаточно интеллектуальна, чтобы использовать эластичность инфраструктуры для обработки нагрузок, которые может создавать приложение.
  • Безопасность. Платформа должна иметь эффективные средства борьбы с угрозами, такими как межсайтовые скрипты, внедрение SQL, отказ в обслуживании (Denial of Service), и средства шифрования трафика, а также предоставлять возможность встраивать эти средства в разрабатываемые приложения. Кроме того, платформа должна поддерживать возможности единого входа (single sign-on), чтобы ее можно было интегрировать в другие локальные или облачные приложения.
  • Инклюзивность. Платформа должна обеспечивать возможность включать, встраивать и интегрировать другие приложения, созданные на этой или другой платформе.
  • Переносимость. Платформа должна быть независимой от используемой инфраструктуры и позволять компаниям переносить приложения с одной IaaS на другую.
  • Инструменты переноса. Чтобы упростить и ускорить процесс миграции данных из традиционных локальных приложений в приложения, основанные на новой платформе, в составе инструментария платформы должны быть программы пакетного преобразования и импорта данных.
  • API. Для выполнения задач аутентификации пользователей, сохранения и извлечения файлов (например, файлы и активы Web-приложения), а иногда и прямых вызовов базы данных, платформа должна иметь хорошо документированный API. Это позволит повысить гибкость создания и настройки программного обеспечения на совместную работу с платформой в соответствии с конкретными требованиями компании.

Управление привязкой к поставщику

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

Одним из способов избежать привязки к поставщику является стандартизация API и технологий платформы. Такие организации, как Simple Cloud (см. раздел Ресурсы), начали работать с различными поставщиками, вовлекая их в проект с открытыми исходными кодами, преследующий цель внедрить PHP в облако. Инициатива Simple Cloud, объединившая компании Zend Technologies, Microsoft, IBM и Rackspace, имеет целью разработку уровня абстракции между различными платформами.

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

Чтобы освободить рынок PaaS от привязки к поставщику, необходимы поставщики сервисов, поддерживающие общий базовый API. Рецепт прост: поставщики сервисов, увязшие в закрытых технологиях, должны согласиться поддерживать инициативы по стандартизации, такие как Simple Cloud.


Заключение

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Information Management
ArticleID=806434
ArticleTitle=Модели сервисов облачных вычислений: Часть 2. Платформа как сервис
publish-date=03212012