Выбираем Windows Azure: подходит ли платформа для вашего приложения? перевод

Если вы собираетесь использовать Windows Azure для размещения приложения, возникает вопрос: сможет ли платформа обеспечить надлежащий уровень обслуживания этого приложения и удовлетворить бизнес-требования? Мы попытаемся ответить на этот вопрос, рассмотрев следующие темы.

• Обзор преимуществ, предоставляемых платформой Windows Azure для развертывания приложений
• Использование преимуществ платформы в распространенных сценариях
• Отклонение сценариев, в которых не используются преимущества платформы
• Общие вопросы разработки и создания архитектуры

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

Общее представление о преимуществах Windows Azure

Прежде чем определить, сможет ли приложение работать в Windows Azure, необходимо рассмотреть основные преимущества платформы. Полный список преимуществ можно найти в документации по Windows Azure. Существует также множество статей и видеоматериалов о Windows Azure. Рекомендуется изучить документ Cloud Optimization — Expanding Capabilities, while Aligning Computing and Business Needs (Оптимизация облака — расширение возможностей при согласовании вычислительных ресурсов и бизнес-требований).

Преимущества платформы расширяют возможности управления оборудованием и ресурсами инфраструктуры. Рассмотрим некоторые из этих преимуществ, а затем обсудим сценарии их применения.

Управление ресурсами

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

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

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

Динамическое масштабирование — это возможность расширения и сокращения приложения в зависимости от выделенных ресурсов. Оно также называется эластичным масштабированием. Прежде чем перейти к описанию принципов действия масштабирования, необходимо понять базовую архитектуру приложения Windows Azure. В Windows Azure пользователь создает роли, совместно реализующие логику приложения. Например, одна веб-роль может обеспечивать работу интерфейсного сервера ASP.NET для приложения; другая рабочая роль (или несколько ролей) может выполнять необходимые задачи в фоновом режиме. Каждая роль размещается в центре обработки данных Windows Azure на одной или нескольких виртуальных машинах, называемых экземплярами ролей. Все запросы распределяются между этими экземплярами. Дополнительные сведения о ролях см. в статье The Windows Azure Programming Model (Модель программирования Windows Azure).

При повышении потребности в ресурсах можно создать новые экземпляры ролей, выполняющие код приложения. Эти экземпляры будут обрабатывать возросшую нагрузку. При сокращении потребностей экземпляры ролей можно удалить, чтобы не оплачивать ненужные вычислительные ресурсы. Такой подход существенно отличается от локального развертывания, требующего избыточных аппаратных средств для обработки пиковых нагрузок. При облачном развертывании масштабирование не осуществляется автоматически, но легко выполняется с помощью веб-портала или интерфейса API управления службами. Один из способов автоматического масштабирования приложений Windows Azure описывается в статье Dynamically Scaling an Application (Динамическое масштабирование приложения). Рекомендуем также ознакомиться с материалами статьи Autoscaling Application Block (Функциональный блок для автоматического масштабирования приложения), написанной группой специалистов Microsoft по созданию шаблонов и методик.

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

Высокая доступность и надежность

Windows Azure — это платформа для высокодоступных приложений. Она обеспечивает надежное хранение данных и доступ к ним с помощью служб хранения или базы данных SQL Windows Azure.

Во-первых, Windows Azure обеспечивает высокую доступность вычислительных ресурсов при наличии нескольких экземпляров каждой роли. Экземпляры ролей отслеживаются автоматически. Автоматическое развертывание нового экземпляра роли позволяет оперативно реагировать на перезапуски или сбои оборудования.

Во-вторых, Windows Azure обеспечивает высокую доступность и надежность хранимых данных за счет использования одной из служб хранения. Службы хранения Windows Azure реплицируют все данные как минимум на три разных сервера. Подобным образом база данных SQL реплицирует все данные, обеспечивая доступность и надежность.

Другие службы Windows Azure также обеспечивают высокую доступность. Дополнительные сведения см. в статье Windows Azure SLA (Соглашение об уровне обслуживания для Windows Azure).

Целевые сценарии, в которых используются преимущества Windows Azure

Располагая знаниями о преимуществах платформы Windows Azure, можно начать рассматривать наилучшие сценарии работы в облаке. В следующих разделах приведено несколько типовых примеров использования Windows Azure в качестве идеального решения для реализации определенных рабочих нагрузок и задач. Видеоролик Windows Azure Design Patterns (Шаблоны проектирования Windows Azure) демонстрирует приведенные ниже сценарии и дает обзор возможностей платформы Windows Azure.

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

Службы высокой доступности

Windows Azure идеально подходит для размещения высокодоступных служб. Рассмотрим интернет-магазин, развернутый в Windows Azure. Поскольку интернет-магазин является источником получения прибыли, очень важно обеспечить его постоянную работу. Для этого в центре обработки данных Windows Azure осуществляется мониторинг службы и автоматическое управление экземплярами. Кроме того, интернет-магазин должен оперативно реагировать на запросы клиентов. В Windows Azure это достигается с помощью функции эластичного масштабирования. В период пиковой активности покупателей происходит подключение новых экземпляров, которые обрабатывают увеличенную нагрузку. Интернет-магазин также должен исключить возможность потери заказов и сбоев обработки размещенных заказов. Хранилище Windows Azure и база данных SQL предоставляют возможности высокодоступного и надежного хранения, обеспечивая целостность сведений о состоянии заказов на протяжении всего их жизненного цикла.

Периодические рабочие нагрузки

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

Примечание. Чтобы избежать оплаты машинного времени, необходимо не просто приостановить приложение, а удалить развертывание.

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

Непредсказуемый рост

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

В этой ситуации идеальное решение — Windows Azure. Рассмотрим небольшой веб-сайт, посвященный новостям спорта и получающий прибыль от размещения рекламы. Объем прибыли прямо пропорционален объему трафика, создаваемого сайтом. В этом примере предприятие располагает ограниченным начальным капиталом, не имея средств на установку и запуск собственного центра обработки данных. Создав веб-сайт на платформе Windows Azure, можно легко развернуть имеющееся решение в качестве приложения ASP.NET, использующего внутреннюю базу данных SQL для хранения реляционных данных и BLOB-объектов для изображений и видео. Если популярность веб-сайта будет расти, предприятие может увеличить размер базы данных SQL или количество экземпляров веб-ролей для интерфейсных серверов. Хранилище BLOB-объектов в Windows Azure имеет встроенные возможности масштабирования. По мере сокращения количества посещений ненужные экземпляры можно удалить. Поскольку прибыль компании пропорциональна объему трафика сайта, Windows Azure позволяет начать с малого, быстро развиваться и сокращать риски.

С помощью Windows Azure можно полностью контролировать затраты на вычислительные ресурсы. Для создания механизма автоматического масштабирования, который формирует или удаляет экземпляры на основе настраиваемых правил, используется Service Management API (Интерфейс API управления службами) или Autoscaling Application Block (Функциональный блок автоматического масштабирования). Можно изменить количество экземпляров с учетом заранее определенного значения, например выделить четыре экземпляра для использования в рабочее время и два экземпляра для использования во внерабочее время. Можно также оставить количество экземпляров прежним и увеличивать его вручную на веб-портале при повышении нагрузки. Windows Azure позволяет гибко принимать решения, соответствующие потребностям бизнеса.

Пики рабочих нагрузок

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

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

Windows Azure позволяет временно масштабировать приложение для обработки пиков нагрузки и сокращать использование ресурсов по окончании периода всплесков активности.

Разгрузка инфраструктуры

Как было показано в предыдущих примерах, большая часть распространенных облачных сценариев использует преимущества гибкого масштабирования Windows Azure. Однако Windows Azure позволяет сократить затраты и с помощью приложений с неизменными шаблонами рабочих нагрузок. Управление собственным центром обработки данных — процесс дорогостоящий, особенно если принимать во внимание расходы на электроэнергию, оплату труда персонала, приобретение оборудования, лицензирование программного обеспечения и содержание объектов. Кроме того, трудно определить связь расходов с отдельными приложениями. Windows Azure позволяет сократить совокупные расходы и сделать их более прозрачными. В документе Cloud Optimization — Expanding Capabilities, while Aligning Computing and Business Needs (Оптимизация облака — расширение возможностей при согласовании вычислительных ресурсов и бизнес-требований) доступно описаны стандартные затраты на локальное размещение и возможности их сокращения с помощью Windows Azure. Windows Azure также имеет встроенный калькулятор для определения отдельных расходов и совокупной стоимости владения (Total Cost of Ownership, TCO). Это позволяет оценить возможности сокращения затрат при внедрении Windows Azure. Ссылки на калькуляторы и другие сведения о ценах доступны на веб-сайте Windows Azure.

Сценарии, не использующие возможности Windows Azure

Не все приложения следует переносить в облако. В облаке будут работать только те приложения, которые поддерживают функциональные возможности Windows Azure.

В качестве примера можно привести веб-сайт личного блога, предназначенного для друзей и членов семьи. На таком сайте можно размещать статьи и фотографии. Для реализации этого проекта можно использовать Windows Azure. Однако применение этой платформы не рекомендуется по следующим причинам. Даже если на сайт ежедневно заходит незначительное количество посетителей, для обработки этих запросов потребуется наличие постоянно запущенного экземпляра роли (следует учесть, что для выполнения соглашения SLA Windows Azure по вычислительным ресурсам необходимо два экземпляра). Стоимость облачных услуг Windows Azure зависит от количества времени, в течение которого каждый экземпляр роли находится в развернутом состоянии (в номенклатуре Windows Azure это называется машинным временем). Приостановка приложения не означает приостановку потребления (и оплату) машинного времени. Даже если в течение дня веб-сайт посетил только один пользователь, оплата взимается за 24 часа машинного времени. В некотором смысле это арендуемое пространство в виртуальной машине, на которой запущен код. На момент написания этого материла работа даже одного самого маленького экземпляра веб-роли стоит 30 долл. США в месяц. А при хранении 20 ГБ изображений в хранилище BLOB-объектов к этой сумме нужно добавить еще 6 долл. США на оплату хранилища, транзакций и полосы пропускания. Ежемесячные расходы на размещение сайта такого типа в Windows Azure выше, чем стоимость простого стороннего решения по размещению веб-узлов. Что еще более важно, для подобных веб-сайтов не требуются функции управления ресурсами, динамического масштабирования, высокой доступности и надежности.

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

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

Оценка архитектуры и разработки

Для оценки возможности перехода на Windows Azure недостаточно уверенности в том, что приложение или бизнес-цели могут быть реализованы в облаке. Важно также оценить особенности архитектуры и разработки существующего или нового приложения. Для этого можно воспользоваться средством оценки Microsoft Assessment Tool (MAT) для Windows Azure. При работе с этим средством пользователю будет предложено ответить на вопросы, чтобы определить типы проблем, которые могут возникнуть при переходе на Windows Azure. Рядом с каждым вопросом находится ссылка See full consideration (Просмотреть все учитываемые аспекты), перейдя по которой можно получить дополнительные сведения о данной области в Windows Azure. Эти вопросы и дополнительные сведения помогут определить возможные изменения в проекте существующего или нового приложения в облаке.

Помимо использования средства MAT необходимо иметь четкое представление о платформе Windows Azure, в том числе об общих шаблонах проектирования для платформы. Начините с просмотра видеоматериалов о Windows Azure или с чтения вводных технических документов, таких как The Windows Azure Programming Model (Модель программирования Windows Azure). Затем изучите службы, доступные в Windows Azure, и подумайте, как их использовать. Обзор служб Windows Azure можно найти в документации MSDN.

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

Область	Описание
Гибридные решения	Перемещение сложных устаревших приложений на платформу Windows Azure может оказаться непростым делом. Иногда трудно обеспечить соответствие правовым нормам, определяющим условия хранения определенных типов данных в облаке. Однако можно создать гибридные решения, соединяющие размещенные в Windows Azure службы с локальными приложениями и данными. Существует ряд технологий Windows Azure, поддерживающих эту возможность, включая шину обслуживания Service Bus, службу Access Control Service и компонент Windows Azure Connect. По этой теме можно просмотреть видеоматериал (октябрь 2010 г.): Connecting Cloud & On-Premises Apps with the Windows Azure Platform (Связь облачных и локальных приложений на платформе Windows Azure). Руководство по гибридной архитектуре, основанное на реальных внедрениях в компаниях клиентов, см. в документе Hybrid Reference Implementation Using BizTalk Server, Windows Azure, Service Bus and Windows Azure SQL Database (Гибридная реализация с помощью BizTalk Server, Windows Azure, шины обслуживания и базы данных Windows Azure SQL).
Управление состоянием	При перемещении существующего приложения на платформу Windows Azure, следует принять во внимание один из важнейших факторов, а именно — управление состоянием. Состояние многих локальных приложений хранится на жестком диске. Другие функции, такие как состояние сеанса ASP.NET по умолчанию, используют ресурсы памяти локального компьютера для управления состоянием. Несмотря на то, что роли имеют доступ к локальному диску и памяти виртуальной машины, Windows Azure распределяет все запросы между всеми экземплярами ролей. Кроме того, экземпляр роли в любое время можно остановить и перенести (например, если требуется обновить компьютер, на котором запущен экземпляр роли). Такое динамическое управление запущенными экземплярами ролей имеет важное значение для реализации возможностей масштабируемости и доступности Windows Azure. Поэтому код приложения в облаке должен обеспечивать удаленное хранение данных и состояния с помощью таких служб, как служба хранения Windows Azure или база данных SQL. Дополнительные сведения о вариантах хранения см. в разделе Store and Access Data (Хранение данных и доступ к ним) веб-сайта Windows Azure.
Требования к хранилищу	База данных SQL является решением реляционной базы данных в Windows Azure. Если в настоящий момент вы используете SQL Server, переход к базе данных SQL не должен вызывать трудностей. Если миграция выполняется с другого типа базы данных, можно воспользоваться помощниками по миграции SQL Server, которые помогут осуществить это процесс. Дополнительные сведения о переносе данных в базу данных SQL см. в статье Data Migration to Windows Azure SQL Database: Tools and Techniques (Миграция данных в базу данных Windows Azure SQL: средства и способы). Хранилище Windows Azure представляет собой надежную, высокодоступную и масштабируемую систему хранения данных. Один из типовых шаблонов проектирования — эффективное сочетание базы данных SQL с таблицами, очередями и BLOB-объектами Windows Azure. В качестве примера можно привести использование базы данных SQL для хранения указателя на большой двоичный объект в хранилище Windows Azure вместо хранения BLOB-объекта в самой базе данных. Это эффективный и экономичный способ. Обсуждение вариантов хранения см. в статье Data Storage Offerings on the Windows Azure Platform (Предложения по хранению данных на платформе Windows Azure).
Функциональная совместимость	Самым простым для разработки или переноса на платформу Windows Azure приложением является приложение .NET. Пакет Windows Azure SDK и средства Visual Studio значительно упрощают процесс создания приложений Windows Azure. Но как быть при использовании программного обеспечения с открытым исходным кодом или сторонних инструментов и языков разработки? В пакете Windows Azure SDK реализован интерфейс API REST, который совместим со многими другими языками. Разумеется, не следует забывать и о проблемах, решение которых зависит от выбранной технологии. В некоторых случаях можно использовать изолированный проект .NET в Visual Studio и перегрузить метод Run для роли. Компания Microsoft предоставляет пользователям пакеты Windows Azure SDK для Java и Node.js, предназначенные для разработки и развертывания приложений. Также существуют пакеты SDK, разработанные сообществом и совместимые с Windows Azure. Веб-сайт Ineroperability Bridges and Labs Center (Мосты взаимодействия и лабораторный центр) один из лучших ресурсов в этой области. Развертывание проектов, использующих программное обеспечение с открытым исходным кодом, также может оказаться непростой задачей. Например, в следующей статье обсуждаются варианты развертывания приложений Ruby в Windows Azure: http://go.microsoft.com/fwlink/?LinkId=235880. Для платформы Windows Azure доступно множество различных языков. Прежде чем оценить возможность размещения приложения в Windows Azure, необходимо выбрать вариант платформы на нужном языке.

Чтобы узнать о возможных проблемах развертывания и ознакомиться с другими решениями, рекомендуется изучить материалы по миграции приложений на Windows Azure. Группа специалистов Microsoft по разработке шаблонов и практик опубликовала руководство по миграции Moving Applications to the Cloud on the Microsoft Windows Azure Platform (Перемещение приложений в облако на платформе Microsoft Windows Azure). Дополнительные материалы по миграции см. на веб-сайте Windows Azure: Migrate Services and Data (Миграция служб и данных).

Сводка

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