Pull to refresh

Перевод Azure Services Platform Девида Чеппела 1 часть

Reading time 15 min
Views 3.1K
Original author: David Chappell
Вторая часть перевода

Обзор платформы.


Использование компьютеров в облаке часто может быть очень неплохой идеей. Вместо того, чтобы покупать и обслуживать свое собственное железо, почему бы не использовать массу серверов, доступных и предлагаемых сегодня через интернет? Для некоторых приложений и код, и данные – и то, и другое — может жить в облаке, где кто-то другой поддерживает и обслуживает используемые ими системы. В других случаях, приложения, которые работают внутри организации — локальные (on-premises) приложения, могут хранить свои данные в облаке или использовать другую инфраструктуру из облака. Приложения, которые работаю на десктопах или мобильных устройствах могут использовать сервисы в облаке для синхронизации данных между разными системами или в каких-то других целях.

В любом случае, работает ли приложение само в облаке или использует сервисы, предоставленные облаком, либо оба варианта, нужно что-то типа платформы для таких приложений. Смотря шире, под платформой для приложений можно понимать все, что предоставляет разработчику службы для создания приложений. Для примера, в локальном мире Windows это включает такие технологии как .NET Framework, SQL Server и т.д. Чтобы приложения могли использовать облако должна существовать облачная платформа для приложений. И поскольку есть много разных применений облака для приложений, разные виды облачных платформ полезны в разных ситуациях.

Microsoft Azure Service Platform — это группа облачных технологий, каждая из которых предоставляет определенный набор сервисов для разработчиков.

На рис.1, Azure Service Platform может использоваться как приложениями, работающих в облаке, так и работающими на локальной системе.
Схема Azure Service Platform
Рис.1 Azure Service Platform поддерживает приложения, работающие как в облаке, так и на локальной системе.

Компоненты платформы могут использоваться локальными приложениями, работающими на разных системах, включая разные версии Windows, мобильные устройства и др. Эти компоненты включают:
  • Windows Azure: предоставляет основанную на Windows среду для выполнения приложений и хранения данных на серверах в дата центрах Microsoft;
  • Windows .NET Services: предоставляют сервисы распределенной инфраструктупы для облачных и локальных приложений.
  • Microsoft SQL Services: предоставляют сервисы для работы с данными, основанные на SQL Server.
  • Live Services: Через Live Framework предоставляет доступ к данным из приложений на Microsoft Live. Live Framework также позволяет синхронизировать эти данные между десктопами и устройствами, искать и загружать приложения и другое.

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

Windows Azure.

На высоком уровне понять Windows Azure довольно просто: это платформа для запуска windows-приложений и хранения данных этих приложения в облаке. На рис.2 – основные ее компоненты.
Схема Windows Azure
Рис.2 Windows Azure предоставляет сервисы для выполнения и хранения данных облачным приложениям.

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

Сервисы выполнения Windows Azure основаны, конечно же, на Windows. Для первоначальной доступной версии (CTP стал доступен публике осенью 2008), на Windows Azure можно запускать только приложения, основанные на .Net Framework. Компания анонсировала планы по поддержке также и неуправляемого кода, то есть приложений, не построенных на .Net Framework, в Windows Azure в 2009.

В CTP версии Windows Azure, разработчики могут создавать основанные на .Net приложения, такие как ASP.NET приложения и WCF-сервисы. Для этого они могуть использовать C# или другие .Net-языки вместе с традиционными средствами разработки типа Visual Studio 2008. И хотя большинство разработчиков, скорее всего, будет использовать первоначальную версию Windows Azure для создания web-приложений, платформа так же поддерживает и фоновые процессы, которые работаю независимо от web-части – это не только платформа для веб-приложений.

Как приложения Windows Azure, так и локальные приложения, могут использовать сервисы хранения данных Windows Azure, в обоих вариантах одним и тем же способом – с использованием механизма типа REST. Однако используемое хранилище данных – это не SQL Server. В частности, это даже не реляционная система и ее язык запросов не SQL. Поскольку система хранения спроектирована для поддержи приложений на Windows Azure, она предоставляет более простые, более масштабируемые виды хранилищ. Соответственно, она позволяет хранить большие бинарные объекты (блобы), предоставляет очереди для взаимодействия между компонентами приложений Windows Azure, и даже что-то типа таблиц с обычным языком запросов.

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

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

Чтобы позволить клиентам создавать, конфигурировать и мониторить приложения, Windows Azure предоставляет доступный через браузер портал. Клиент предоставляет свой Windows Live ID, затем выбирает, создать ли хостинг аккаунт для выполнения приложений или аккаунт хранилища для хранения данных, либо оба. Приложение свободно в выборе способа взымания платы со своих клиентов – подписка, плата за каждое использование или что-то еще.

Windows Azure это общая платформа, которая может использоваться в различных сценариев. Вот несколько примеров, основанных на том, что позволяет CTP:
  • Стартап, создающий новый сайт, например новый ВКонтакте (в оригинале – Facebook), может построить свое приложение на Windows Azure. Поскольку платформа поддерживает и Web-facing сервисы и фоновые процессы, приложение может предоставить как интерактивный пользовательские интерфейс, так и асинхронное выполнение работ для пользователей. Вместо того, чтобы тратить время и деньги, беспокоясь о инфраструктуре, участники стартапа могут сфокусироваться исключительно на создании кода, который значим для их пользователей и инвесторов. Приложение также может стартовать в небольшом размере, требующем небольшие затраты пока у него немного пользователей. Если приложение «пойдет» и его использование возрастет, Windows Azure смасштабирует приложение, как потребуется.
  • ISV (Independent SoftwareVendor), создающий SaaS версию сущствующего локального .Net приложения может построить его на Windows Azure. Поскольку Windows Azure в основном предоставляет стандартное .Net окружение, перенос бизнес-логики приложения на облачную платформу не породит множество проблем. И опять же, разработка на существующей платформе позволит ISV сфокусироваться на бизнес-логике – именно том, что приносит ему деньги – вместо того чтобы тратить время на инфраструктуру.
  • Корпорация, создающая приложение для своих клиентов может выбрать Windows Azure. Поскольку Windows Azure основана на .Net, то и найти подходящих разработчиков будет не сложно, и стоить они будут не «зверски» дорого. Выполнение приложений на площадках Microsoft освобождает корпорацию от отвественности и затрат поддержки своих собственных северов, превращая капитальные затраты в оперативные. Особенно если у приложения есть пики использования – например, если это онлайн магазин цветов, который обязан выдерживать 8-мартовский наплыв (в оригинале – Mother's Day), то позволить Microsoft обслуживать большую серверную базу для этого может иметь немалый экономический эффект.

Выполнение приложений в облаке это один из самых важных аспектов облачных вычислений. С Windows Azure Microsoft предоставляет платформу и для выполнения приложения в облаке, и способы для хранения данных приложения.

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

.Net Services.

Выполнение приложений в облаке это важная часть облачных вычислений, но это далеко не все, что скрывается под этим термином. Так же можно предоставлять сервисы, основанные на облаке, которые могут использоваться или локальными, или другими облачными приложениями. Решение этой задачи – цель .Net Services.

Изначально известные как BizTalk Services, .Net Services решают основные инфраструктурные проблемы при создании распределенных приложений. На рис.3 – компоненты.
image
Рис.3 .Net Services предоставляют облачную инфраструктуру, которая может использоваться как облачными, так и локальными приложениями.

Компоненты Net Services:
  • Access Control: Все более частый способ идентификации, когда каждый пользователь предоставляет приложению токен, содержащий набор утверждений (claims). Приложение теперь может решить, что разрешено этому пользователю, основываясь на предоставленных утверждениях.
  • Service Bus: Открытие доступа снаружи к сервисам локального приложения сложнее чем думает большинство. Цель сервисной шины в том, чтобы сделать это проще за счет открытия конечных точек веб-сервисов, которые будут доступными другим локальным или облачным приложениям. Каждой такой точке доступа назначается URI, который клиенты могут использовать для обнаружения и доступа к сервису. Сервисная шина также решает проблемы работы с NAT (Network Address Translation) и с прохождением через файрволлы без открытия нового порта для каждого открытого наружу приложения.
  • Workflow: Создание композитных приложений, таких как приложения для интеграции enterprise-приложений, требует логики, координирующей взаимодействие между различными частями системы. Такая логика часто лучше всего реализуется за счет workflow, способного поддерживать продолжительные процессы. Построенный поверх Windows Workflow Foundation, сервис Workflow позволяет использовать логику такого типа в облаке.

Вот несколько примеров того, как могут использоваться .Net Services:
  • ISV, который предоставляет приложение, используемое клиентами в различных организациях может использовать Access Control для упрощения разработки и работы приложения. Для примера, этот компонент .Net Services может преобразовывать разнообразные утверждения (claims), используемые в различных организациях клиентов, каждая из которых использует у себя разные технологии идентификации, в единообразный набор, который будет использовать разрабатываемое приложение. Также это позволяет перенести работу identity federation на сервис Access Control в облаке, что освобождает ISV от необходимости запускать свое локальное federation software.
  • Представьте корпорацию, желающие дать приложениями своих торговых партенров доступ к одному из своих приложений. Она может открыть функции приложения через SOAP или REST веб-сервисы, затем зарегистрировать их конечные точки в Service Bus. Торговые партнеры теперь могут использовать Service Bus для того, чтобы найти эти открытые сервисы и получить доступ к ним. Поскольку это не требует открытия новых портов в файрволле организации, то это снижает риск от открытия доступа к приложению. Организация также может исползовать Access Control, который разработан для работы с Service Bus, для приведения к общему виду идентификационных данных, которые клиенты посылают приложению.
  • Вполне вероятно, что рассмотренный выше бизнес-процесс, включающий торговых партнеров компании, должен выполняться целостно. Для этого можно использовать сервисы Workflow для реализации WF-приложения, которое будет управлять процессом. Приложение может взаимодействовать с партнерами через Service Bus и положиться на Access Control в приведении идентификационных данных к общему виду.

Как и при работе с Windows Azure, есть доступный через браузер портал, который позволяет клиентам подписаться на .Net Services используя Windows Live ID. Цель Microsoft с их .Net Services проста и понятна: предоставить полезную облачную инфраструктуру для распределенных приложений.

SQL Services

Один из самых привлекательных способов использования доступных в Интернете серверов – это работа с данными. Конечно, обычно это означит предоставление движка баз данных, но не всегда дело ограничивается только этим. Цель SQL Services – предоставить набор облачных сервисов для хранения и работы с большим количеством разнообразных видов данных, от реляционных до неструктурированных.

Microsoft говорит, что SQL Services будут включать разные сервисы, связанные с данными, такие как отчеты, анализ данных и т.д. Однако самый первый компонент, который пояивился на свет, — это SQL Data Services.
Идея – на рис. 4.
image
Рис.4 SQL Services предоставляет сервисы для работы с данными в облаке.

SQL Data Services, ранее известные как SQL Server Data Services, предоставляют базы данных в облаке. Как видно из рисунка, эта технология позволяет локальным и облачным приложениям хранить и получать доступ к данным на серверах Microsoft в дата центрах Microsoft. Как и с другими облачными технологиями, организация платит только за то, что она использует. Использование (и цена) увеличивается и уменьшаяется в соответсвии с потребностями организации. Использование баз данных в облаке так же позволяет преобразовать то, что было бы капитальными затратами типа инвестиций в жесткие диски или системы управления базами данных, в оперативные затраты.

Основная задача SQL Services – быть максимально доступными. Для этого сервис делает доступным свои интерфейсы как через SOAP, так и через REST, что позволяет получить доступ к данным самыми разными способами. И поскольку данные доступны через стандартные протоколы, SQL Data Services могут использоваться на самых разных системах – это не только Windows технология.

В отличии от сервисов хранения Windows Azure, SQL Data Services построены на Microsoft SQL Server. Не смотря на это сервис не доступен через обычный реляционный интерфейс. Вместо этого, SQL Data Services предоставляют иерархическую модель данных, которая не требует предопределенной схемы данных. Каждый элемент данных в этом сервисе хранится как свойство со своим именем, типом и значением. Для запроса этих данных можно использовать запросы в стиле REST или LINQ.

Сразу встает очевидный вопрос, почему бы просто не предложить SQL Server в облаке? Зачем вместо этого предоставлять облачный сервис баз данных, который использует совсем другие методы, чем те к которым мы все привыкли? Один из ответов состоит в том, что предоставление немного отличного от привычного набора сервисов дает некоторые преимущества. SQL Data Services могут предоставить большую маштабируемость, доступность и надежность, чем дал бы простой запуск СУБД в облаке. Тот способ, которым новые сервисы организуют и получают данные, делает репликацию и балансировку нагрузки гораздо более легкими и быстрыми, нежели с обычными реляционным способом. Другое преимущество состоит в том, что SQL Data Services не трубуют от клиентов, чтобы те поддерживали свои собственные СУБД. Вместо того, чтобы заботиться о технических деталях, типа мониторинга использования жестких дисков, обслуживания логов, определения необходимого количества экземпляров и т.д., пользователи SQL Data Services могут сфокусироваться на главном – на данных. В конце концов, Microsoft анонсировала планы о добавлении новых реляционных возможностей в SQL Data Service, так что ожидайте роста их функциональности.

SQL Data Services могут использоваться самыми разными способами, вот несколько примеров:
  • Приложение может хранить старые архивные данные в SQL Data Service. Для примера, представьте приложение, которое предоставляет часто обновляемую RSS ленту. Информация, которая старее, допустим, 30 дней, вряд ли будет запрашиваться часто, но она все равно должна быть доступна. Перенос таких данных в SQL Data Service может быть дешевой и надежной альтернативой их локальному хранению.
  • Представьте производителя, который хочет сделать информацию о своих продуктах доступной как его сети дилеров, так и клиентам напрямую. Хранения таких данных в SQL Data Services позволит обеспечить доступ к данным как приложениям, которые работают у дилеров, так и веб-приложению для клиентов, которая работает у самого производителя. Поскольку данные доступны и через REST, и через SOAP, то приложения, которые используют эти данные, могут быть написаны на разных технологиях и для разных систем.

Как и с другими компонентами Azure Service Platform, начать использовать SQL Data Services просто – нужно идти на портал и заполнить там нужную информацию. Для дешевого архивного хранения, предоставления доступа к данными приложениям, расположенных в разных местах, или с другими целями, облачные базы данных могут быть очень привлекательным решением. С появлением новых технологий под эгидой SQL Services, компании смогут использовать облако для все большего количества задач, связанных с данными.

Live Services.

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

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

Для того, чтобы это стало возможным, Microsoft собрала весь этот разнообрзаный набор ресурсов в одну группу – Live Services. Существующие приложения Microsoft, типа семейства Windows Live, используют Livе Services для хранения и управления своими данными. Чтобы дать возможность новым приложениям использовать эти данные, Microsoft предоставляет Live Framework. Основные аспекты – на рис. 5.
image
Рис.5 Live Framework предоставляет приложениям доступ к данным Live Services, при необходимости синхронизируя эти данные между десктопами и мобильными устройствами.

Фундамент Live Framework – это Live Operating Environment. Как видно из рисунка, этот компонент выполняется в облаке и приложения получают через него доступ к данным Live Services. Доступ к данным происходит через HTTP, то есть любые приложения на .NET, Java, Java Script или других языках могут полчить доступ к данным Live Services. Также информация из Live Services может быть получена через Atom или RSS, что позволяет приложениям узнавать об изменениях этих данных. Для настройки и управления функциями Live Services, которые нужны конкретному приложению, разработчик может использовать веб-портал Live Services Developer Portal.

На рисунке 5 показан также другой аспект Live Framework – Live Operating Environment, который так же может выполняться и на системах с Windows Vista, Windows XP, Mac OS X, и на Windows Mobile устройствах. Чтобы использовать эту возможность, пользователь группирует все систему в одну штуку, известную как меш (mesh). Для примера, можно создать меш, который содержит ваш десктоп, ноутбук и сотовый. На каждом из устройств будет выполняться экземпляр Live Operating Environment.

Самая главная характеристика меша – это то, что Live Operating Environment синхронизирует данные между всеми системами, входящими в него. Пользователи и приложения могут указать, какие данные должны быть синхронизированными, и Live Operating Environment автоматически обновит все десктопы, ноуты и мобильные устройства, входящие в меш, данными, которые были изменены на одном из устройств. И поскольку облако это тоже часть любого пользовательского меша – оно представляется там как специальное устройство – то синхронизация работает и для данных Live Services. Для примера, если пользователь хранит свои контакты в Windows Live Hotmail, Windows Live Messenger или Windows Live Contacts, то они будут синхронизированы между всеми устройствами меша. (Правда в ноябрьском CTP Live Framework эта возможность еще не работает). Через Live Operating Environment также можно давать доступ к каким-то своим данным другим пользователям, что позволяет выборочно делиться какой-либо информацией.

Как показывает рис. 5., приложение может обращаться к данным меша через локальный или облачный экземпляр Live Operating Environment. В обоих случаях доступ производится одним и тем же способом – через HTTP-запросы. Такое единообразие доступа дает приложению одинаково работать не зависимо от наличия соединения с облаком, в любом случае данные достуны и обращаться к ним можно тем же способом.

Любое приложение, работает ли оно на Windows или другой операционной системе, может обращаться к данным Live Services в облаке через Live Operating Environment. Если приложение работает на устройстве, которое является частью меша, оно может использовать Live Operating Environment для обращения к локальным копиям данных Live Services. Есть и третья возможность – разработчик может сделать штуку, которая называется Mesh-Enabled Web Application. Такие приложения создаются с помощью мультиплатформенных технологий типа Silverlight и они обращаются к данным через Live Operating Environment. Благодаря таким ограничениям Mesh-Enabled Web Application может потенциально запускаться на любой машине пользовательского меша – Windows машине, Маке, коммуникаторе с Windows Mobile и она всегда будет иметь доступ к одним и тем же синхронизированным данным. Для поиска таких приложений, среда Live Framework предоставляет облачное приложение – каталог mesh-enabled web-приложений. Пользователь может посмотреть каталог, выбрать приложение и установить его. И чтобы дать создателям приложений возможность построить бизнес на таких приложениях, Microsoft планирует предоставить встроенную поддержку показа рекламы в их приложениях.
  • Вот примеры разнообразных способов применения Live Framework:
  • Java приложение, работающее на Linux может испоьзовать Live Framework для работы с контактами пользователя. Приложение не завязывается на какой-то технологии, через которую открыт доступ к этим данным; все, с чем оно работатет — это постоянный HTTP интерфейс к пользовательским данным.
  • Приложение на .Net может требовать от пользователя создания меша, а затем использовать Live Framework для кеширования и синхронизации данных. Когда у машины, на которой работает приложение, есть связь с интернетом, приложения работает с копией данных в облаке. Когда связи нет – например при работе на ноутбуке в самолете – приложение использует локальную копию тех же данных. Live Operating Environment.реплицирует изменения локальных данных в облако.
  • ISV может сделатьMesh-Enabled Web Application, которое позволяет пользователям узнавать, чем занимаются их друзья. Это приложение может работать без изменений на всех устройствах пользователя, использовать разные части Live Framework для социальных приложений. Поскольку Live Framework поддерживает открытие доступа к пользовательским данным в меше через RSS, то приложение, может, например подписаться и следить за обновлениями от любого из друзей пользователя. Поскольку Live Framework предоставляет механизм доставки для mesh-enabled web-приложений, то возможно «вирусное» распространения приложения, когда пользователи приглашают своих друзей пользоваться этим приложением. И поскольку в меше уже есть данные о контактах пользователя из Live Services, то пользователя может приглашать друзей через само приложение просто по имени, а заботиться о том, чтобы доставить приглашение друзьям, будет уже само приложение.

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

Вторая часть перевода
Tags:
Hubs:
+23
Comments 18
Comments Comments 18

Articles