Оригинал статьи по Windows Azure в журнале открытые системы

У меня тут статья вышла

https://www.osp.ru/os/2009/04/9277961/.

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

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

Итак, оригинал.

Лазурное облако Microsoft

“Take my time
I'll show you cloud nine”

(George Harrison , Cloud Nine.)

Марат Бакиров

В последнее время тема облачных вычислений получает все большую популярность. И на это есть реальные бизнес-причины.

В самом деле – допустим, мы решили сделать новый сервис. Это может быть новый необходимый сервис для бизнеса, это может быть новая разработка или стартап , или это может быть S+S (Software + Service) версия нашего существующего приложения. Допустим , что наш сервис реально будет востребован множеством пользователей. Что же нам нужно для построения такого сервиса?

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

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

Избежать указанных затрат и рисков позволяет модель аренды. Возьмем, к примеру, Exchange – систему можно развернуть у себя, а можно воспользоваться партнерским решением по типу Hosted Exchange. Тем самым мы снимаем с себя проблемы времени и масштабируемости и переходим на модель аренды ПО вместо покупки. Таким образом, в случае, если мы переоценили популярность проекта, мы перестаем арендовать мощности и не теряем много денег. В случае, если нагрузка недооценена, мы мгновенно увеличиваем мощность, увеличивая платежи.

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

Ну и наконец, самым важным плюсом является сокращение времени масштабируемости. Предположим, есть две компании, которые одновременно запускают аналогичный сервис. Одна компания разворачивает ЦОД самостоятельно, другая сразу разворачивает сервис на масштабируемой облачной платформе, такой как Windows Azure. Пусть в январе у нас 1000 пользователей, и каждый месяц число пользователей увеличивается в 10 раз. К марту первая компания понимает, что существующих мощностей недостаточно, и тратит месяц на увеличение мощности ЦОДа или на переписывание приложения с учетом масштабируемости. Вторая компания просто открывает страничку «редактировать мои настройки» и увеличивает число арендованных мощностей. К тому моменту, пока первая компания перепишет свой сервис и пройдет порог в 10 тыс. пользователей, вторая уже будет иметь миллион пользователей.

1.Эволюция компонентного подхода

В свое время с увеличением сложности программных систем возникла идея повторного использования кода, которая получила развитие в двух ипостасях – подпрограммы (процедуры и функции) и объекты.

Сначала мы имели реализацию этой идеи в статических библиотеках, потом поняли, что хотим динамически обновлять объекты – так появились DLL и компоненты (COM, сборки .NET). затем возникла сеть, и понадобилось вызывать компонент, который может находиться на другом компьютере. Для этого стали использовать ся протоколы типа RPC , а также DCOM или .NET Remoting для объектного взаимодействия. В процессе же стандартизации идея вызывать код по сети трансформировалася превратилась в концепцию сервис- ориентированной архитектуры (SOA), которая, на мой взгляд, представляет собой просто абстракцию вызова кода по сети.

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

Таким образом, современное приложение состоит из компонентов , которые живут на разных компьютерах. Типичным примером является семейство решений Microsoft для почты , в которое входит Exchange Server, Outlook , Outlook Web Access и Pocket Outlook. Причем Exchange Server вызывает другие сервисы, такие как Active Directory, для обеспечения авторизации пользователей.

С этой точки зрение «облако» – это дальнейшее развитие идей компонентного подхода. Если мы говорим о серверной части наших приложенией, то одной из возможных платформ могут быть серверы, распоженные не у нас, а в «облаке» – мы можем арендовать мощности у какого-либо вендора.

2. Azure Services Platform

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

Эти возможности реализует платформа Azure Services Platform ([1]), анонсированная в октябре 2008 года на конференции Microsoft PDC 2008. Платформа Azure предоставляет четыре основных сервиса - Windows Azure, .NET Services, SQL Services (или SQL Server в «облаке») и LIve framework.

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

.NET Services решает задачи связывания сервисов между собой, управления доступом к методам сервиса и поддержку рабочих процессов (workflow). Обычно такой класс решений называется Internet Service Bus (по аналогии с уже известным термином Enterprise Services Bus.NET Services позволяет взять произвольный сервис, который может быть спрятан глубоко внутри за сетевым адресом (NAT) или межсетвым экраном , и выдать ему постоянный Internet-адрес https://чтото.servicebus.windows.net. В результате сервис можно вызывать снаружи, например, организовать таким образом обмен информацией с партнерами.

Вторая важная задача, которую умеет решать .NET Services– это масштабируемый сервис уведомлений . Например, авиакомпания может предоставить в Internet сервис , через который будет уведомлять об отмене рейсов и появлении новых. Может существовать большое количество желающих подписаться на такие уведомления – например, туристические агенства по всему миру или агенства, организующие поездку для VIP персон. .NET Services берет на себя задачу рассылки одного уведомления миллионам подписчиков.Также в .NET Services имеется функция управления доступом Access Control , которая позволяет подключать сервисы авторизации , собирать их в одном месте и управлять доступом к методам сервисов, доступных через Internet Services Bus.

Последняя функция – Workflow Service – это масштабируемый и надежный сервис в «облаке», исполняющий пользовательские рабочие процессы (workflow) , которые задаются декларативно с помошью платформы Windows Workflow Foundation, входящей в состав .NET начиная с версии 3.0. Сервис работает как агент, который управляет взаимодействием различных сервисов между собой и, благодаря инструментам разработки на Java и Ruby, позволяет соединять гетерогенные информационные системы в единое целое.

Сервис SQL Services сейчас активно развивается в направлении предоставления в «облаке» сервисов хранения данных. В будущем возможно развитие дополнительных сервисов, таких как добыча данных (Data Mining) или генерация отчетов.

Интересным компонентом Azure Services Platform является Live framework. Существуют такие сервисы, как Live Mesh (htp://www.mesh.com) , позволяющие синхронизировать файлы и папки между устройствами , включая «облако», а также пользователями, или платформа Windows Live, которая дает возможность использовать в своих сайтах Web- компоненты типа live contacts (интерактивные списки конактов Windows Live или Live Messenger прямо на пользовательской странице) , Virtual Earth (двух и трехмерная модель земли на пользовательской Web-странице) и др. Live Framework развивает указанные сервисы в платформу для разработчика. Сервис позволяет разработать на Silverlight или DHTML так называемое Mesh Enabled Web Application, в котором посредством простой модели предоставляется доступ к live contacts, папкам и файлам пользователя (то есть тем самым обьектам, которые автоматически синхронизируются между устройствами или «облаком» в Windows Live или Live Mesh). При этом можно создавать дополнительно свои потоки данных , которые автоматически будут синхронизироваться с «облаком» и компьютерами пользователя.

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

Рассмотрим подробнее собственно платформу Windows Azure.

3. Windows Azure

Windows Azure - платформа для масштабируемого хостинга Web-приложений. Масштабируемые сервисы часто имеют модульную структуру. Нам необходим «фасад» (или front-end) – собственно обработчик Web-запросов. Поскольку сервис высоконагруженный, может потребоваться несколько экземпляров «фасада», между которыми балансировщик нагрузки будет переключать запросы пользователей. Отсюда следует, что необходимо отдельное от «фасада» хранилище данных, а «фасад» не должен сохранять состояние (stateless). В самом деле, мы никогда не можем предсказать, какой из идентичных экземпляров «фасада» будет выполнять запрос пользователя, так что в самом «фасаде» может быть разве что опредленный кеш.

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

Ну и, наконец, нам потребуется портал для управления мошностями нашего сервиса, в зависимости от нагрузки.

Исходя из вышесказанного, Windows Azure предоставляет следующие возможности:

1) Инструменты для разработки сервисов или сайтов в архитектуре Windows Azure;

2) Центр обработки данных Windows Azure, исполняющий код разработанного решения;

3) Высокодоступное, масштабируемое и надежное хранилище, позволяющее хранить данные в ЦОДе Azure;

4) Локальная эмуляция сервиса, позволяющая полноценно отлаживать приложения на локальной машине;

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

Как выглядит процесс разработки в Windows Azure? С помощью Visual Studio2008 SP1 пишется код для так называемых «Web-роли» (это уже упомянутый нами «фасад») и «рабочей роли» (Worker Role – фоновый процесс или сервис) проектируется структура хранилища. После этого решение отлаживается локально с помощью компонентов локальной эмуляции, после чего загружается в «облако» – наше решение готово.

Надо отметить несколько интересных моментов.

Во первых, развертывание решения и выделение виртуальных машин в ЦОДе занимает некоторое время. В то же время, обычно у нас уже работает старая версия сервиса, а мы хотим обеспечить его бесперебойную работу. Для решения этой задач предлагается так называемое промежуточное развертывание (staging). Суть проста. Предположим, что основное решение имеет адрес https://чтото.cloudapp.net. Мы разворачиваем новую версию на базе staging по адресу https://какойтоGUID.cloudapp.net, проверяем ее работоспособность и только после этого переключаем решение на основной адрес. Переключение выполняется на уровне таблиц соответствия DNS внутри ЦОД Azure, и таким образом время обновления системы можно считать практически равным нулю.

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

В третьих, вызов из интернета нашейWeb-роли возможен только по определенным правилам, которые явно прописываются в настройках решения. Обычно это возможность вызвать по http (порт 80) или https (порт 443) нашего сайта или встроенные в него сервисы Windows Communication Foundation. Но вызов других Internet-сервисов ИЗНУТРИ нашего Azure решения ничем не ограничен.

В четвертых, в Windows Azure SDK есть определенные компоненты , предназначенные для поддержки сервисов собственно в «облаке». Я бы выделил класс RoleManager, предоставляющий точки входа для управления протоколированием событий сервиса, а также получения конфигурационной информации ( напомню, что файл конфигурации может меняться на лету). Необходимость этого компонента очевидна – ведь нет технической возможности поставить точку останова (breakpoint) прямо в облаке. Так что разбирать, что и как не работает в нашем решении, можно только с помошью разбора протокола событий.

Рис. 2 Windows Azure – «Windows в облаке»

Рис. 3 . Типичная архитектура сайта или сервиса на Windows Azure

Рис. 4 Работа с порталом управления

РЕСУРСЫ

Для дальнейшего изучения «облачной» платформы Microsoft можно посоветовать следующие ресурсы:

www.azure.com – основной портал , посвященный Windows Azure;

https://www.techdays.ru/Search.aspx?Quick=azure доклады на русском языке по Windows Azure;

. https://platforma2009.ru/materials/default.aspx?s=azure - доклады на руском языке с конференции «Платформа»;

https://www.visitmix.com – материалы конференции MIX;

https://www.remix.ru  – материалы конференции REMIX;

https://blogs.msdn.com/windowsazure/ - блог команды разработки Windows Azure;

https://msdn.microsoft.com/en-us/azure/default(en-us).aspx - портал MSDN для разработчиков

[]

###

Мир информационных технологий очень быстро эволюционирует. Когда-то я был счастлив, что у меня появился винчестер в 500 мегабайт вместо 40. Сейчас в моем мобильном телефоне встроено 4 гигабайта памяти. То же самое происходит и с развитием сетевых технологий. В мире безлимитного Internet, доступного, в том числе, и во многих городах России, идея вынести часть сервиса в облако выглядит вполне разумной. Таким образом, облачные технологии становятся реальной частью современного мира программирования. На мой взгляд, Microsoft всегда серьезно подходила к любому рынку и всегда предлагала полную и открытую платформу. Причем открытость платформы всегда позволяла заменить какой то из компонентов на свой или сторонний, если стандартная функциональность почему-то не устраивает клиента.

Это происходит и с Azure Services Platform. Это готовая и продуманная платформа для построения масштабируемых сервисов, но в то же время можно автономно использовать произвольные части платформы и компоновать с другими продуктами. Можно, например, брать только хранилище Windows Azure или только .NET Services. Не случайно для .NET Services есть SDK для Java и Ruby.

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

Марат Бакиров (i-maratb@microsoft.com, https://blogs.msdn.com/mbakirov ) - эксперт по разработке программного обеспечения компании Microsoft

Литература

1. David Chappell. INTRODUCING THE AZURE SERVICES PLATFORM
https://download.microsoft.com/download/e/4/3/e43bb484-3b52-4fa8-a9f9-ec60a32954bc/Azure_Services_Platform.pdf