Windows Azure. Ценообразование. Примеры

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

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

• Учетная система
• Электронный магазин
• Обучающая система
• Социальная сеть

Эти приложения позволят нам посмотреть на различные сценарии использования ресурсов Windows Azure.

Сбор данных о приложении

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

• Средства, предоставляемые операционной системой (системные утилиты, счетчики производительности, системные журналы)
• Средства, включенные в состав СУБД
• Утилиты для измерения объема трафика
• Данные, которые, возможно, собирались в процессе разработки, тестирования, отладки и эксплуатации приложения

Если же создается новое приложение, то данные должны основываться на предполагаемом поведении приложения, сценариях использования, ожидаемом числе пользователей и т.п.

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

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

Учетная система

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

• Система должна позволять отслеживать использование различных ресурсов по всем регионам
• Уведомлять персонал о том, что ресурсы требуют замены или ремонта
• Передавать данные в другие системы управления, включая ERP
• Передавать два раза в день данные, собираемые в каждом офисе для их централизованного сбора и обработки
• Собирать, обрабатывать и сохранять данные в масштабируемой реляционной базе данных
• Передавать данные для их анализа различными приложениями, работающими как в «облаке», так и в локальной инфраструктуре
• Система должна быть максимально автоматизированной, не требующей существенных ресурсов на ее сопровождение

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

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

На следующей иллюстрации показана высокоуровневая архитектура приложения.

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

Использование этих данных в калькуляторе позволяет мгновенно получить представление о стоимости хостинга данного приложения в Windows Azure.

Как видно из приведенной иллюстрации, хостинг приложения в Windows Azure при использовании модели «оплата по факту» обойдется в 705 долл. в месяц. Использование калькулятора позволяет быстро оценить, какие элементы создаваемого приложения привносят максимальные затраты и выполнить действия по оптимизации архитектуры приложения для снижения его общей стоимости. Например, для такого типа приложения данные, хранимые в SQL Azure, могут быстро заполнить отведенные для них объемы. Разработчики могут снизить стоимость приложения за счет выбора более гибкой схемы хранения данных – использование базы данных меньшего объема и регулярное архивирование и/или удаление исторических данных. Также, если нагрузка на приложение не очень высока, можно уменьшить объем вычислительных ресурсов, выбрав виртуальную машину размера Small. При необходимости, можно будет добавить дополнительные экземпляры виртуальной машины или даже изменить ее размер.

Хостинг приложений, подобных рассмотренному в этом примере, в Windows Azure имеет смысл, как с финансовой точки зрения, так и как стратегический шаг. Операционные затраты порядка 9000 долл. в первый год (при выборе модели «оплата по факту») позволят компании улучшить глобальную доступность приложения, повысить его надежность и масштабируемость. Компания получает доступ к масштабируемой, высоко доступной и надежной облачной платформе без каких либо капитальных вложений и затрат на управление инфраструктурой, а также затрат, связанных с конфигурацией и обслуживанием базы данных.

Электронный магазин

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

На следующей иллюстрации показана высокоуровневая архитектура приложения.

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

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

Использование этих данных в калькуляторе позволяет мгновенно получить представление о стоимости хостинга данного приложения в Windows Azure.

Использование калькулятора для подсчета стоимости хостинга приложения на платформе Windows Azure позволяет быстро оценить, какие элементы создаваемого приложения привносят максимальные затраты и выполнить действия по оптимизации архитектуры приложения для снижения его общей стоимости. В данном примере, хранение данных в BLOB-ах увеличит число обращений к хранилищу – для их уменьшения можно переместить данные в базу данных SQL Azure и немного сэкономить на стоимости транзакций. Также можно уменьшить число экземпляров приложения, работающего в прикладной роли без заметных ухудшений при работе приложения в «стандартном» режиме. В случае пиковых нагрузок число экземпляров можно будет динамически увеличить. Сокращение числа экземпляров приложения уменьшит стоимость хостинга на 90 долл. в месяц (при выборе модели «оплата по факту») – будет использоваться не четыре, а три экземпляра.

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

Обучающая система

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

В компании было принято решение использовать платформу Windows Azure и Azure CDN для обеспечения доступа к обучающим материалам сотрудникам в любом офисе. Это решение базируется на следующих фактах:

• Отпадает необходимость в поисках подходящих решений для хостинга, механизмов для управления и масштабирования приложения
• Масштабируемая «облачная» платформа не требует капитальных вложений, управления инфраструктурой и позволяет сохранить инвестиции в существующие разработки на платформе Microsoft .NET
• Отпадает необходимость в создании, управлении и сопровождении собственной сети поставки контента (CDN)
• Соглашение о доступности сервисов (SLA) удовлетворяет требованиям по доступности обучающих материалов

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

На следующей иллюстрации показана высокоуровневая архитектура приложения.

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

Использование этих данных в калькуляторе позволяет мгновенно получить представление о стоимости хостинга данного приложения в Windows Azure.

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

Хостинг приложений, подобных рассмотренному в данном примере, в Windows Azure имеет смысл, как с финансовой точки зрения, так и как стратегический шаг. Использование калькулятора позволяет представление о стоимости хостинга, и убедиться в корректности архитектуры приложения и его отдельных компонентов. При стоимости хостинга менее 10000 долл. в год (при выборе модели «оплата по факту»), компания избавляется от затрат на создание и управление собственной сетью доставки контента (CDN) и получает масштабируемое «облачное» решение без капитальных инвестиций и затрат на управление инфраструктурой.

Социальная сеть

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

• Быстро масштабироваться для обеспечения эффективной поддержки неизвестного заранее числа пользователей
• Выдерживать массивные всплески запросов без потери производительности
• Быстро отвечать на запросы пользователей – в данном сценарии быстро выдавать запрошенные купоны
• Интегрироваться с выбранной социальной сетью
• Собирать базовую информацию о посетителях – фамилию/имя, адрес электронной почты, почтовый индекс, дату рождения, число посещений сайта и т.п.
• Проверять возраст участников (должны быть старше 18 лет)
• Находить и отображать местоположение ресторана на основании введенного почтового индекса
• Интегрироваться с внешним поставщиком сервисов электронной почты для рассылки купонов и управления кампанией по рассылке почты по всему списку участников акции
• Уведомлять участников о неверном адресе электронной почты в случае невозможности отсылки купона
• Сохранять данные для последующего анализа результатов кампании, включая данные о посещении ресторана, обмене купона на напиток и т.п.
• Поддерживать возможность повторного использования для будущих кампаний

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

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

На следующей иллюстрации показана высокоуровневая архитектура приложения.

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

Использование этих данных в калькуляторе позволяет мгновенно получить представление о стоимости хостинга данного приложения в Windows Azure.

Хостинг приложений, подобных рассмотренному в данном примере, в Windows Azure имеет смысл, как с финансовой точки зрения, так и как стратегический шаг. Использование калькулятора позволяет представление о стоимости хостинга, и убедиться в корректности архитектуры приложения и его отдельных компонентов. При стоимости хостинга менее 800 долл. (при выборе модели «оплата по факту»), компания получает масштабируемое «облачное» решение без капитальных инвестиций и затрат на управление инфраструктурой. С точки зрения снижения затрат можно рассмотреть вариант хранения почтовых индексов в памяти каждого экземпляра веб-роли (вместо хранения данных в таблице). У такого варианта есть два преимущества – увеличение скорости поиска и отображения информации и снижения числа запросов к хранилищу, что уменьшает общую стоимость хостинга приложения.

/АФ