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

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

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

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

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

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

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

Azure Services Platform

При проектировании высоконагруженных Web-сервисов или Web-сайтов имеются типовые задачи, которые вполне по силам сервису из облака, поэтому разработчики Microsoft, проанализировав опыт разработки нагруженных систем, предложили свое решение для таких типовых задач. Речь идет о модели аренды сервис-хостинга высоконагруженных сайтов, сервисе исполнения произвольного кода клиента, сервисе хранения данных, а также сервисе для связывания других сервисов между собой. В результате возникла платформа Azure Services Platform, предоставляющая четыре основных сервиса: Windows Azure, .NET Services, SQL Services (SQL Server в облаке) и Live framework.

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

.NET Services решает задачи связывания сервисов между собой, управления доступом к методам сервиса и поддержки рабочих процессов. Такой класс решений называется Internet Service Bus (по аналогии с термином Enterprise Services Bus). Они позволяют произвольному сервису, который может быть спрятан глубоко внутри за сетевым адресом (NAT) или межсетевым экраном, выдать постоянный Internet-адрес для обеспечения ему доступа извне. Другая задача .NET Services – масштабируемый сервис уведомлений. Например, авиакомпания может предоставить сервис уведомления об отмене рейсов и появлении новых. В общем случае на такие уведомления может подписаться непрогнозируемое количество желающих: туристические агентства со всего мира, рядовые пассажиры, транспортные компании и т.п. Также в .NET Services имеется функция управления доступом Access Control, позволяющая подключать сервисы авторизации, собирать их в одном месте и через Internet Services Bus управлять доступом к методам сервисов.

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

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

Что все это дает на практике? Можно, например, написать приложение для игры в шахматы, запускать его со своего компьютера или напрямую с сайта Live Mesh CTP (developer.mesh-ctp.com), пригласить друга, который тоже сможет запускать приложение из облака или со своего компьютера, а инфраструктура Live Framework обеспечит синхронизацию данных.

Windows Azure

Платформа Windows Azure предоставляет: инструменты для разработки сервисов или сайтов; центр обработки данных, исполняющий код разработанного решения; масштабируемое хранилище данных; локальную эмуляцию сервиса, позволяющую полноценно отлаживать приложения на локальной машине; портал, на котором можно разворачивать разработанные решения, управлять выделенными мощностями и на ходу менять конфигурацию сервиса. Масштабируемые сервисы часто имеют модульную структуру, состоящую из «фасада», хранилища данных и портала для управления мощностями сервиса в зависимости от нагрузки (рис. 2).

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

Из Internet приходят запросы на ваш Web-сайт (или Web Role – это часть Azure-проекта), а в облаке на центре обработки данных Azure запущено несколько идентичных экземпляров вашего приложения. Балансировщик нагрузки (LB) выбирает экземпляр сайта и направляет ему запрос. Поскольку нельзя предсказать, какой экземпляр будет запущен, сайты надо (как это обычно и бывает в случае высоко нагруженных сайтов) разрабатывать таким образом, чтобы они не содержали истории своей работы.

Web-сайт может обращаться к одному или нескольким хранилищам, доступным через балансировщик нагрузки. К хранилищу, содержащему очереди, таблицы или неструктурированные данные, большие бинарные объекты (Binary Large OBjectS, BLOBS), также можно обращаться через Internet из других сайтов.

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

Ваши сайты или рабочие роли могу вызывать из Сети внешние Web-службы – любой доступ наружу из ЦОД Azure не ограничен. Вызов из Web-роли возможен только по определенным правилам, которые явно прописываются в настройках решения. Обычно это возможность вызвать по протоколу http (порт 80) или https (порт 443) сайт или встроенные в него сервисы Windows Communication Foundation. Вызов других Internet-сервисов из Azure-решения ничем не ограничен. Казалось бы, это угрожает безопасности, и не случайно промышленные программные и аппаратные сетевые экраны имеют фильтр не только входящего, но и исходящего трафика, однако никакой угрозы нет. В отличие от обычной ОС, в которой находятся сотни программ, в том числе, возможно, и вредоносные, в виртуальных машинах Windows Azure находится только код пользователя и код от Microsoft. Если вам для осуществления операции нужно вызвать сервис Windows Live, xml-сервис из Facebook или Yandex, то можно это беспрепятственно сделать.

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

Разработка приложений

Для полноценной работы разработчику необходимо установить систему Visual Studio 2008 sp1, а также специальный инструментарий Windows Azure SDK и модуль расширения Visual Studio. Разработка начинается с создания средствами Visual Studio специального решения, в котором присутствует код для Web-роли («фасад») и Worker-роли (рабочей роли), и проектирования структуры хранилища (рис. 3). После этого решение отлаживается локально с помощью компонентов локальной эмуляции и загружается в облако.

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

А можно ли взять уже существующее ASP.NET-приложение и «положить» его в облако? И да, и нет. С одной стороны, существует способ добавить приложение (это должно быть Web-приложение, а не Web-сайт) в проект на Azure путем редактирования (для этого надо добавить одну настройку в XML-файл проекта Visual Studio). С другой, не все так просто. Часто ASP.NET-приложения используют так называемые «провайдеры» – готовые компоненты, которые описывают пользователей, роли и хранилище профилей пользователей. Обычно все эти данные хранятся в SQL Server, однако хранилище Windows Azure совсем не похоже на SQL Server, но можно найти примеры реализации провайдеров поверх хранилища Windows Azure. Если это просто сервис (например Windows Service), то можно его переписать на Worker Role. Если же это какой-то другой сервис приложений, доступный через Web-сервисы, то можно организовать безопасный доступ из облака к сервису с помощью .NET Services.

***

Мир информационных технологий очень быстро эволюционирует. Когда-то мы были счастливы, что в компьютере появился винчестер на 500 Мбайт вместо 40 Мбайт, а сейчас в мобильном телефоне встроено 4 Гбайт памяти. То же самое происходит и с сетевыми технологиями, поэтому идея вынесения части сервисов в облако выглядит вполне разумной. Облачные технологии становятся реальной частью современного мира программирования. Платформа Azure Services Platform представляет собой готовую базу, которая позволяет автономно использовать как произвольные части ее самой, так и компоненты других продуктов облачных или корпоративных сервисов для построения масштабируемых решений.

Марат Бакиров (i-maratb@microsoft.com) – эксперт по разработке программного обеспечения компании Microsoft (Екатеринбург).

Платформа или операционная система?

Вокруг словосочетания «ОС для облаков» сегодня очень много маркетинговой шумихи и почти нет технических деталей. Windows Azure – серверная платформа для облачных вычислений, поддерживающая разработку приложений на PHP, «собственный» (native) код и режим «полного уровня доверия» (full trust). В отличие от поставщиков альтернативных решений, в которых можно запустить виртуальную машину как на локальном компьютере, так и в облаке, компания Microsoft на текущий момент не предоставляет кому-либо свою cloud-инфраструктуру. Все, что известно на данный момент, это то, что на облачных серверах используется версия Hyper-V.

По словам Прашанта Еткара, директора по маркетингу сервисов облачной инфраструктуры Microsoft, для Windows Azure реализован ряд усовершенствований, включая поддержку «собственного» кода (ранее был только управляемый код), возможность создания приложений и сервисов с неограниченным разрешением на доступ, поддержку интерфейса FastCGI. Благодаря последнему появилась возможность запускать в окружении Azure уже созданные PHP-приложения и сервисы. Аналогичным образом в Azure смогут выполняться приложения и на других языках, понимающих FastCGI, например Ruby. Azure будет запущена к концу 2009 года.

Ресурсы Windows Azure

www.azure.com – основной портал, посвященный Windows Azure
www.techdays.ru/Search.aspx?Quick=azure – доклады на русском языке
www.visitmix.com – материалы конференции MIX
www.remix.ru – материалы конференции REMIX
www.blogs.msdn.com/windowsazure/ – блог команды разработки Windows Azure
www.msdn.microsoft.com/en-us/azure/default(en-us).aspx – портал MSDN для разработчиков

Рис. 1, 2 Развитие компонентного подхода ; Windows в облаке

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