Как выбирать службы Azure для конкретных задач

Автор статьи: Роб Кэрон, старший менеджер по маркетингу

Запись подготовлена в соавторстве с Барри Люйбрегтсом, MVP Azure .

В прошлом году я принял участие в вебинаре Pluralsight, который вел Барри Люйбрегтс, самый большой знаток (MVP) Azure и автор материалов Pluralsight. Вебинар назывался Высокая продуктивность разработчиков благодаря правильному выбору службы Azure . Мероприятие оказалось очень полезным: я оценил предложенный Барри метод выбора служб и функций Azure для использования как в его собственных проектах, так и при решении задач клиентов, которых он консультирует. Недавно я попросил Барри поделиться его схемой, чтобы опубликовать ее здесь и предложить Скотту Хансельману для показа в Azure Friday (видео можно найти ниже).

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

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

Обзор процесса

Рассмотрим мою схему в применении к задаче «Выполнение моего приложения в Azure».

Сначала я стараюсь ответить на ряд вопросов общего характера, а в данном случае на следующие:

1. Какая степень контроля мне требуется?
2. Где именно должно выполняться мое приложение?
3. Какая модель потребления мне нужна?

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

Итак, первый этап: ответы на общие вопросы относительно категории службы.

Вопрос 1: Какая степень контроля мне требуется?

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

Если нужна высокая степень контроля, выбирайте категорию «Инфраструктура как услуга» (IaaS) , в которую входят такие службы, как виртуальные машины Azure и экземпляры контейнеров Azure. С их помощью обеспечивается высокий уровень контроля над операционной системой и той инфраструктурой, где выполняется ваше приложение. Однако контроль подразумевает высокую степень ответственности — в частности, за обновление и защиту ОС.

Рис. 1. Какая степень контроля мне требуется?

Выше представлены службы, относящиеся к категории «Платформа как услуга» (PaaS) , например веб-приложения службы приложений Azure (App Service Web Apps). При использовании PaaS у вас нет контроля над операционной системой, в которой выполняется ваше приложение, и поэтому она не входит в вашу сферу ответственности. Однако предоставляется контроль над масштабированием вашего приложения и его конфигурацией (например, можно выбрать версию платформы .NET, на которой ему предстоит выполняться).

Следующий уровень абстракции — «Логика как услуга» (LaaS) , или «вычисления без сервера». К ней относятся службы Azure Functions и Azure Logic Apps. При их использовании Azure самостоятельно осуществляет управление низкоуровневой инфраструктурой, в том числе обеспечивает масштабирование вашего приложения. LaaS не дает вам возможности контроля над инфраструктурой, в которой выполняется приложение, то есть вы отвечаете только за его создание и настройку параметров, например строк подключения к базам данных.

Самый высокий уровень абстракции обеспечивается в категории «Программное обеспечение как услуга» (SaaS), которая предоставляет наименьшую степень контроля, позволяя уделять максимум внимания развитию бизнеса. Пример SaaS — Azure Cognitive Services: это API, которые вы просто вызываете из своего приложения. Контроль над кодом реализации таких служб и инфраструктурой, в которой они выполняются, принадлежит не вам — вы их только потребляете. Вам остается лишь управлять базовыми настройками приложения, например ключами API, которые используются для вызова службы.

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

Вопрос 2: Где именно должно выполняться мое приложение?

Второй вопрос связан с задачей «Выполнение моего приложения в Azure».

Рис. 2. Где именно должно выполняться мое приложение?

Казалось бы, ответ — в формулировке самой задачи: «Мое приложение должно выполняться в Azure». Но все не так просто. Например, возможно, какие-то части приложения будут выполняться в общедоступном облаке Azure, а какие-то — в Azure Government, в Azure China или даже локально, с помощью Azure Stack.

Кроме того, может потребоваться выполнение приложения — как в Azure, так и локально (например, на случай изменения законодательства) — на собственном компьютере или в общедоступных облаках других операторов.

Суть этого вопроса сводится к определению степени независимости от поставщика и места для хранения данных.

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

Вопрос 3: Какая модель потребления мне нужна?

Ответ на заключительный вопрос зависит от особенностей использования приложения.

Рис. 3. Какая модель потребления мне нужна?

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

Другие приложения используются время от времени, например фоновое задание, которое выполняется один раз в час, или API, обрабатывающий отмену заказа (такой API вызывается несколько раз в день). В таком случае для приложения необходимо выбрать службу, относящуюся к категории «логика как услуга» (или «вычисления без сервера»). Эти службы работают, только когда вам нужно, и оплачиваются лишь за время их выполнения.

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

Следующий шаг: сопоставить функциональность службы с требованиями моего приложения

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

В итоге вы сможете выбрать именно ту службу, которая подойдет для конкретного приложения. Я нередко использую несколько служб для тех или иных своих приложений, если они состоят из многих компонентов, например из пользовательского интерфейса и API. В таком случае, вполне возможно, что веб-приложение лучше выполнять в Azure App Service Web App, а API — в Azure Functions.

Другие категории служб

Мы рассмотрели требования только для одной категории задач: «Выполнение моего приложения в Azure». Существует и множество других, например «Защита моего приложения в Azure», «Аналитика данных в Azure» и «Мониторинг моего приложения в Azure». Описанный здесь метод подходит для всех этих категорий.

Этот метод мы недавно обсуждали и со Скотом Хансельманом.
Посмотрите выпуск Azure Friday «Как я выбираю службы Azure для моих задач» , где демонстрируется процесс выбора служб для задач «Выполнение моего приложения в Azure» и «Хранение моих данных в Azure».