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

• Размещение приложения в облаке.
• Потребление сервисов из облака.

Размещение приложений в облаке

При данном подходе код приложения и данные полностью размещаются в облаке. Такой подход часто применяется для модели SaaS, в котором конечным пользователям предоставляется полностью готовый к использованию сервис¹, не требующий никаких затрат на локальную инфраструктуру (рис. 20).

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

Рис. 20. Размещение приложения в облаке

Применяется два варианта развертывания кода и данных приложения в облаке:

• В виде приложений, т.е. используя возможности платформы как сервиса (PaaS), обеспечивающей контроль и управление на уровне приложения. Код и используемые приложением ресурсы помещаются в специальный пакет, который публикуется в облако через административный портал или используя программные интерфейсы управления. Среда разработки Visual Studio, начиная с версии 2008, поддерживает публикацию проектов приложений в Windows Azure непосредственно из своего интерфейса. Создание схемы данных и размещение начальных данных приложения производится отдельно с использованием стандартных средств загрузки данных SQL Server или при помощи функций генерации схемы данных Entity Framework².
• В виде виртуальной машины, т.е. используя инфраструктуру как сервис (IaaS), обеспечивающей контроль и управление на уровне виртуальной машины. В отличие от PaaS при этом в облако публикуется образ виртуальной машины, в котором заранее размещено приложение и используемые ресурсы. Данный вариант существенно расширяет спектр приложений, который можно разместить в облаке, так как разработчик имеет полный административный доступ к виртуальной машине.

Потребление сервисов из облака

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

• Готовые платформенные сервисы, встроенные в Windows Azure. К ним, например, относятся хранилище нереляционных структурированных данных, хранилище бинарных объектов, реляционная база данных, сервисная шина передачи сообщений, сервис контроля доступа и др. Использование этих сервисов не требует размещения кода приложения в облаке, но может потребовать постоянного или временного переноса данных в облако.
• Создание собственных сервисов и размещение их в облаке. Как уже отмечалось, при проектировании и потреблении собственных сервисов рекомендуется следовать принципам сервисно-ориентированной архитектуры.

Существуют следующие варианты создания собственных сервисов, в которых часть кода или данных остается в локальной инфраструктуре:

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

Перенос данных в облако

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

Рис. 21. Перенос данных в облако

Размещение данных в облаке обладает рядом преимуществ:

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

К основным сценариям использования облака в качестве хранилища данных, в частности, относятся:

•  Справочники и другие референсные данные.
•  Резервные копии и выведенные из оперативного использования базы данных.
•  Мультимедийные данные, такие как, видео- и фотофайлы.
•  Данные геоинформационых систем (GIS).
•  Архивы информации.
•  Другие данные большого объема.

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

Рекомендации по масштабированию данных

Выбор хранилища данных и технологий работы с данными во многом определяет, как приложение будет масштабироваться и не станет ли база данных узким местом в производительности. Важно определить стратегию масштабирования хранилища, такую как разделы (partitioning), доступность средств репликации и синхронизации данных между базами данных и приложениями, процедуры загрузки и интеграции данных. Локальные и удаленные данные могут быть синхронизированы различными методами, например при помощи Microsoft Sync Framework⁴ или SQL Server Integration Services⁵ и других технологий и средств интеграции данных. Способность к масштабированию хранилища определяется также схемой данных, что должно быть заложено на этапе проектирования. Рекомендуется включать в набор полей записи ключ, позволяющий провести горизонтальное разделение таблицы для размещения ее частей на разных дисковых подсистемах или серверах. Данная техника носит название шардинг⁶. Для реляционных СУБД применяется техника под названием DDR⁷ в сочетании с шардингом, при которой приложение само решает к какой базе данных будет произведен запрос на основании состава ключа раздела.

Перенос кода приложения в облако

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

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

Рис. 22. Перенос кода в облако

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

Рекомендации по масштабированию сервисов

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

Слабое связывание компонентов

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

Основные вопросы, которые следует задать себе при проектировании слабосвязанной архитектуры:

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

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

Кеширование

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

Повышение уровня абстракции и разделение на уровни

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

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

• Использование технологий ORM⁹ позволяет абстрагироваться от специфики реализации базы данных.
• Использование сервисов данных, работающих поверх ORM технологий¹⁰.
• Представление потоков работ (Workflow) в виде сервисов¹¹.
• Использование модели подключаемых модулей и расширений.

Также обратите внимание на следующие технологии, доступные на платформе Windows Azure:

• WCF RIA Services¹², предназначенные для быстрого создания приложения с RIA-клиентом.
• Microsoft Extensibility Framework¹³, предназначенная для реализации модели расширений и плагинов.

Интеграция приложений

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

Рис. 23. Интеграция приложений

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

¹ К таким сервисам относятся, например, корпоративная электронная почта или CRM.

²https://msdn.microsoft.com/en-us/data/default.aspx

³ Windows Azure поддерживает HTTP(S), SOAP, ATOM, OData и др.

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

⁵ SQL Server Integration Services — технология извлечения, трансформации и загрузки данных, входящая в состав SQL Server.

⁶ Англ. — Sharding. Метод разделения хранилища на автономные узлы для обеспечения максимальных показателей производительности. Применяется в высоконагруженных системах.

⁷ Data Dependent Routing — маршрутизация, зависящая от данных. Архитектурный паттерн, в котором месторасположение данных определяется приложением на основе анализа содержания запроса.

⁸www.microsoft.com/hpc/

⁹ ORM — Object-Relational Mapping. Общее название технологий, позволяющих работать с данными при помощи объектов, отображаемых на записи базы данных. Ключевая ORM технология, поддерживающая SQL Server, SQL Azure и ряд других баз данных через подключаемых провайдеров, является Entity Framework, входящая в состав .NET Framework 4.0.

¹⁰ Например, WCF Data Services , предназначенных для быстрого создания Веб-сервисов в формате OData поверх ORM технологий, включая Entity Framework.

¹¹ Данная возможность поддерживатся в технологии Windows Workflow Foundation — https://msdn.microsoft.com/ru-RU/vstudio/jj684582

¹²https://www.silverlight.net/getstarted/riaservices/

¹³https://code.msdn.microsoft.com/mef