Основные принципы создания облачных приложений на платформе Microsoft Azure
Цель лекции: первоначальное знакомство с облачными платформами и изучение составных частей и терминологии платформы Microsoft Azure.
Согласно прогнозам IDC, в 2011 году 80% новых программ будет доступно в виде облачных сервисов; к 2014 году более трети покупаемых программных продуктов будет предоставляться заказчикам через облако. Ключевая идея, которая находится в основе облачных технологий, заключается в том, чтобы компания, которая пользуется хостингом для размещения своих интернет-приложений, оплачивала только использованные ресурсы с возможностью увеличения мощности в случае возникновения потребностей масштабирования и возможностью быстрой подстройки сервисов под свои бизнес требования.
Поставщики, предлагающие облачные платформы, могут рассматривать это в различных аспектах. Так выделяют три основных вида облачных платформ: инфраструктура как сервис (IaaS) , программное обеспечение как сервис (SaaS) и платформа как сервис (PaaS).
В стандартной схеме, когда вендоры проставляют компьютерные ресурсы: серверы, файерволы, балансировщики нагрузки, а разработчик приложения может удаленно установить его на арендованное оборудование достаточно сложно решаются вопросы масштабирования. Когда возникает необходимость масштабирования разработчик должен сделать запрос на выделение дополнительных ресурсов. Обработка этого запроса, выделение новых ресурсов, изменение размеров оплаты и другие сопутствующие операции обычно занимают немало времени. Поэтому компании при использовании такой схемы необходимо иметь прогноз возможного использования компьютерных ресурсов, чтобы заранее обеспечить требуемое количество ресурсов в датацентре.
У провайдера облачных вычислений масштабирование может быть выполнено в любой момент времени простым изменением файла конфигурации и изменения вступят в силу тоже достаточно быстро в течение нескольких минут.
Подход инфраструктура как сервис IaaS обеспечивает для компании заказчика необходимый уровень доступа к своему приложению, так как в этой схеме компания- поставщик обычно обеспечивает только самый низкий уровень функционирования облачной системы, что позволяет заказчику сохранять контроль над выполнением приложения начиная с уровня операционной системы до уровня приложения. Ключевым преимуществом является то, что заказчик избавляется от необходимости отслеживания потребности в реальных и виртуальных машинах, а оперирует и оплачивает только реально использованные аппаратные ресурсы по факту.
Существует также сценарий, когда компания может использовать предлагаемый поставщиком интерфейс для установки и конфигурации своего приложения без учета того, какие аппаратные и программные средства поставщик услуги использует. Такой подход называется Программное обеспечение как услуга (SaaS), поскольку оплата такого сервиса производится за использование определенной службы.
В этой модели компания заказчик не имеет прямого доступа к аппаратным средствам, на которых работает его приложение, также нет доступа и к средствам операционной системы. Все эти элементы конфигурируются и управляются поставщиком услуг. Механизм управления доступный заказчику ограничен возможностями предлагаемого интерфейса, обычно в этих целях используется веб-интерфейс. Другими словами поставщик услуг обеспечивает полноценную работу приложения, как на уровне аппаратной части, так и на уровне операционной системы, а заказчик работает только со своим приложением.
Третий способ платформа как сервис (PaaS) занимает промежуточное положение. В его рамках компания заказчик арендует платформу, на которой размещает свое приложение и может самостоятельно управлять и своим приложением и определёнными настройками операционной системы. Это позволяет снять ряд ограничений модели SaaS.
Модель PaaS заключается в представлении компании заказчику интегрированной платформы для разработки, тестирования, развертывания и поддержки различных типов приложений. Платформа может включать в себя как функции для дизайна приложений, так и для его разработки, развертывания и хостинга, а также специальные службы для обеспечения командного взаимодействия, маршалинга, интеграции с базами данных, безопасности, управления состоянием, версиями приложений и другими функциями. Все указанные службы могут быть объединены в единое интернет приложение.
С системами класса PaaS нет необходимости задумываться о виде используемой дисковой памяти, сетевых интерфейсах и балансировщиках нагрузки и методах реализации механизмов хранения. В подобных системах доступ к ресурсам осуществляется с помощью специальных служб. При этом API такой службы может использоваться как удаленная служба. На практике это выражается в том, что для различных действий необходимо обратится к службе с соответствующими параметрами, получить результат и отобразить его пользователю. Ключевая идея облачных платформ - обеспечить разработчику условия для размещения и выполнения созданных им программ без необходимости управления тем, где физически располагается исполняемый файл и сохраняются данные. После размещения программы можно забыть о ней, так как дальнейшие действия по обеспечению ее работоспособности (кроме исправления ошибок, конечно) берет на себя платформа. В качестве ключевых операцией выполняемых поставщиком услуг можно выделить:
- применение обновления в момент их выхода;
- добавление дисковой памяти при возникновении потребности;
- перезапуск системы в случае аварийных ситуаций;
- репликацию данных для повышения надежности их сохранения;
- управление дисками и другим аппаратным обеспечением.
Обсуждая различные типы облачных сервисов — программное обеспечение, платформу и инфраструктуру как сервис, следует обращать внимание на т.н. границы управляемости — т.е. на то, чем, в сравнении с традиционными моделями развертывания в собственной инфраструктуре, можно управлять при переходе на облачную платформу. По понятным причинам, инфраструктура как сервис предоставляет большие возможности по настройке отдельных компонентов, тогда как платформа как сервис и программное обеспечение как сервис практически минимизируют эти возможности. Отличия в границах управляемости показаны на рис. 3.1.
