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

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

Вычисления в облаке

Существует несколько определений вычислений в облаке, но больше всего мне нравится одно из них: вычислительный ресурс доставляется как коммунальная услуга с применением стандартов и протоколов Интернета. Это определение открывает возможности для концепций «общедоступное облако» (public cloud) и «закрытое облако» (private cloud). Общедоступные облака, как и предполагает их название, открыты любому, кто умеет обращаться с кредитной картой. Закрытые облака подразумевают их эксклюзивное использование каким-либо предприятием или консорциумом.

Платформа Windows Azure, веб-сервисы Amazon, Google App Engine и Force.com — вот несколько примеров общедоступных облаков. Любой закрытый информационный центр, принадлежащий крупному предприятию, может быть назван закрытым облаком, если он использует преимущества модели унифицированных ресурсов, которая за счет виртуализации позволяет интерпретировать процессорные мощности, хранилища и сетевые каналы как пул гомогенных ресурсов.

Вычисления как одна из коммунальных услуг были давней мечтой тех, кто занимался автоматизацией производственных процессов. Инициативы Microsoft Dynamic Systems Initiative (DSI) и аналогичные от других поставщиков были нацелены на то, чтобы операторы информационных центров могли реализовать соответствующие услуги: высокая автоматизация, самоуправление, самостоятельно оптимизируемое и измеряемое хранилище, сетевые и вычислительные ресурсы. Хотя этот замысел заслуживал всяческих похвал, его внедрение шло с переменным успехом. И лишь появление средств виртуализации превратило предоставление вычислительных сервисов как коммунальных услуг в реальность. Виртуализация помогла отделить операционную систему и приложения от физического оборудования. Они интерпретируются как данные, поэтому автоматизированные процессы можно разрабатывать по запросу и размещать нужную операционную систему и другие зависимые ресурсы на целевом оборудовании.

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

Рис. 1. Платформа Windows Azure как предложение PaaS

Software as a Service (SaaS)

SaaS Software as a Service (SaaS) — бизнес-модель доставки ПО, в которой приложение размещается у провайдера или третьей стороны и становится доступным клиентам по подписке. Клиенты SaaS используют выполняемое в инфраструктуре провайдера ПО на основе оплаты текущих расходов. Вносить предоплату не требуется, поэтому клиент может не заключать какие-либо долгосрочные контракты.

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

Многопользовательская архитектура может не устроить некоторые компании из-за самой природы их бизнеса, поэтому провайдеры могут предлагать таким клиентам физически изолированную инфраструктуру и взимать дополнительную плату, связанную с поддержкой программно-аппаратных средств. Хорошие примеры SaaS — Microsoft Business Productivity Online Suite (BPOS) и CRM Online. Microsoft также предлагает выделенный хостинг этих сервисов за дополнительную плату.

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

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

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

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

PaaS

SaaS выглядит правильным выбором для всех потребностей компании в ПО. Однако каждая компания имеет уникальную ИТ-среду, где могут использоваться самые разнообразные технологии — от устаревших до специфических для конкретной области бизнеса. Найти SaaS-сервис, удовлетворяющий все потребности специфической области бизнеса, зачастую невозможно, поэтому компаниям все равно приходится заниматься разработкой своих приложений. Platform as a Service (PaaS) как раз и отвечает потребностям компаний, желающих создавать и выполнять собственные приложения как сервисы. К таким компаниям могут относиться независимые поставщики ПО (ISV), провайдеры сервисов с добавочной стоимостью (value-added service providers), корпоративные вычислительные центры и все, кому необходимы собственные приложения. В случае PaaS предлагаются серверы приложений с почти бесконечной масштабируемостью за счет огромного пула ресурсов, а также необходимые вспомогательные сервисы, в том числе хранилища, защиту, инфраструктуру интеграции и средства разработки полной платформы.

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

IaaS

Infrastructure as a Service (IaaS) — аналог традиционного хостинга, где предприятие использует размещенную среду как логическое расширение своего информационного центра. Серверы (физические и виртуальные) арендуются по мере необходимости, а ИТ-специалисты, управляющие инфратсруктурой, имеют полный контроль над конфигурацией ПО. Некоторые провайдеры позволяют даже гибко настраивать аппаратную конфигурацию, что делает сервис более дорогим по сравнению с эквивалентным предложением PaaS.

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

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

Платформа Windows Azure обладает всеми преимуществами PaaS и в то же время обещает гибкость на уровне IaaS, как было показано на рис. 1. Платформа Windows Azure объединяет большие пулы вычислительных мощностей (серверов), сетевых ресурсов и ресурсов хранения в коммунальную вычислительную среду, из которой клиенты могут брать ресурсы по требованию и платить только за использованные ресурсы. Платформа Windows Azure (что типично для облачных сред) помогает клиентам избегать авансовых расходов и поддерживает наращивание ИТ-возможностей по мере необходимости.

Платформа Windows Azure

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

Рис. 2. Концептуальная схема вычислительной инфраструктуры (система Windows Azure может отличаться)

Пул вычислительных ресурсов включает ресурсы промышленного класса, сделанные отказоустойчивыми с помощью Fabric Controller. Архитектура последнего предусматривает раннее обнаружение сбоев приложения и создание дополнительных экземпляров для соблюдения соглашений об уровне обслуживания (service-level agreements, SLA). Так как среда Windows Azure является полной платформой хостинга приложений, она обеспечивает стабильность работы приложения, предлагая практически неограниченные ресурсы, выделяемые по требованию. Свободные ресурсы возвращаются в пул, что повышает степень их использования. Ресурсы включают процессорное время, виртуализованное хранилище и виртуализованные сетевые средства динамической перенастройки маршрутов в частных и общедоступных сетях. Физические конфигурации этих ресурсов невидимы архитекторам и разработчикам приложения.

Итак, каким образом владельцы приложения получают эти ресурсы? Берут телефон и звонят ИТ-специалисту, как это обычно делается в традиционных средах на предприятии? Нет, такой вариант никому даже в голову не приходил, так как массивы информационных центров на платформе Windows Azure управляются глубоко автоматизированными процессами под надзором специалистов. Рутинная эксплуатация информационного центра не требует участия человека. Платформа Windows Azure позволяет владельцам приложения получать необходимые ресурсы через машинно-читаемые модели, включающие использование дескрипторов ресурсов. В Windows Azure эти дескрипторы называют моделями сервиса (service models). Такие модели определяют ресурсы приложения и их зависимости, достаточные для обеспечения полноценной инфраструктуры в период выполнения без участия человека. В связи с таким уровнем автоматизации на создание инфраструктуры для приложения часто уходит менее пяти минут. Если вы сравните этот показатель с тем, что есть в типичных средах предприятия, то сразу же почувствуете всю мощь вычислений в облаке.