Содержание


Практические рекомендации по развертыванию приложений в облаке

Comments

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

Выбор между IaaS, PaaS и SaaS

Когда говорят об облачных вычислениях, обычно имеют в виду один из трех возможных способах развертывания кода приложения: инфраструктура как услуги (IaaS), платформа как услуги (PaaS) и программное обеспечение как услуги (SaaS). То, какой из них лучше подходит для вашего проекта, зависит от конкретных особенностей базы кода, с которой вы работаете. Давайте рассмотрим каждый из этих вариантов облачных технологий.

Инфраструктура как услуга (IaaS)

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

Преимущества: у вас будет полный контроль над каждым аспектом системы.

Недостатки: нужны знания по системному администрированию или команда системных администраторов для управления системой, так как ответственность за ее работоспособность и безопасность лежит на вас.

Платформа как сервис (PaaS)

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

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

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

Программное обеспечение как сервис (SaaS)

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

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

Недостатки: вы имеете ограниченный контроль над приложением на хостинге, и часто бывает трудно интегрировать в систему внешние процессы.

Что выбрать?

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

Масштабирование приложения

Как уже упоминалось, PaaS предоставляет возможности масштабирования большинства языков и сред. Однако как разработчик, вы должны быть знакомы с предлагаемыми способами масштабирования и знать, когда имеет смысл горизонтальное масштабирование, а когда – вертикальное.

Вертикальное масштабирование

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

Горизонтальное масштабирование

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

Ручное масштабирование

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

Автоматическое масштабирование

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

Что выбрать?

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

Состояние приложения

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

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

Что выбрать?

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

Базы данных для облачных приложений

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

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

Способ 1: выбрать поставщика, который позволяет открывать удаленное VPC-соединение с базой данных.

Способ 2: взаимодействовать с базой данных через набор защищенных REST-служб, развернутых в инфраструктуре, у которой есть доступ к данным.

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

Если код приложения не нужно соединять с существующей корпоративной базой данных, то количество возможных вариантов становится почти бесконечным. Я рекомендую развернуть базу данных в том же географическом регионе/ЦОД, что и приложение, но в других контейнерах или на других серверах. Это позволит масштабировать базу данных независимо от веб-уровня. Кроме того, выбирайте базу данных, которая быстро и легко масштабируется, будь то СУБД SQL или NOSQL.

Рекомендации по географическому распределению

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

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

Что выбрать?

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

Создание и использование веб-сервисов REST

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

Непрерывный выпуск и интеграция

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

Что выбрать?

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

Как избежать зависимости от поставщика

Если вы вынесите из этой статьи что-то одно, хотелось бы, чтобы это была следующая мысль: несмотря на то, что многие поставщики облачных услуг предлагают привлекательные проприетарные API-интерфейсы, которые уменьшают количество необходимого кода или объем необходимой работы, их следует избегать любой ценой. Это не более чем простая уловка, нацеленная на то, чтобы привязать вас к своей экосистеме и чрезвычайно затруднить перенос приложения в систему другого поставщика услуг или в свой собственный центр обработки данных. Чтобы избежать этих нестандартных API-интерфейсов, придерживайтесь испытанных и надежных наборов технологий, включающих уровень базы данных, уровень хранения данных и любые конечные точки микросервисов, которые вам могут понадобиться. Первоначальные инвестиции в этом случае могут быть несколько выше, чем при использовании готового проприетарного решения, зато ваша зависимость от технологии будет значительно меньше, а это может сэкономить вам деньги и время в долгосрочной перспективе.

Разрабатывать локально или в облаке

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

Что выбрать?

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

Чего ожидать от поставщиков облачных услуг в ближайшие годы

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

Заключение

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

  1. Для разработки приложений выбирайте PaaS; управлением инфраструктуры будет заниматься поставщик, а у вас останется больше времени на то, чтобы сосредоточиться на коде вашего приложения.
  2. Выбирайте платформу, которая обеспечивает возможность как ручного, так и автоматического горизонтального масштабирования приложений.
  3. Проектируйте новые приложения как приложения без сохранения состояния.
  4. Для существующих или унаследованных приложений выбирайте поставщика PaaS, который поддерживает приложения как с сохранением состояния, так и без него.
  5. Выбирайте базу данных, которая масштабируется и размещена на сервере/в контейнере, отдельном от кода приложения, так чтобы ее можно было наращивать независимо.
  6. Выбирайте поставщика облачных услуг, который позволяет развертывать и масштабировать инфраструктуру приложения в нескольких географических регионах по всему миру.
  7. Ведите разработку на основе веб-сервисов REST.
  8. Выбирайте поставщика облачных услуг, который отвечает всем перечисленным выше требованиям, добавляя к своей платформе комплексные инструменты непрерывной интеграции/непрерывного выпуска (CI/CD).
  9. Избегайте зависимости от поставщика.

Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1020090
ArticleTitle=Практические рекомендации по развертыванию приложений в облаке
publish-date=11052015