Microsoft Azure

Платформа корпорации Майкрософт Windows Azure (первоначально известная под названием Azure Services Platform) — это группа "облачных" технологий, каждая из которых предоставляет определенный набор служб для разработчиков приложений. На рисунке 4.2 показано, что платформа Windows Azure может быть использована как приложениями, выполняющимися в "облаке", так приложениями, работающими на локальных компьютерах

Рис. 4.2. Платформа Windows Azure поддерживает приложения, данные и инфраструктуру, находящиеся в "облаке"

Платформа Windows Azure состоит из следующих компонентов:

• Windows Azure. Обеспечивает среду на базе Windows для выполнения приложений и хранения данных на серверах в центрах обработки данных корпорации Майкрософт.
• SQL Azure. Обеспечивает службы данных в "облаке" на базе SQL Server.
• .NET Services. Обеспечивают распределенную инфраструктуру для "облачных" приложений и локальных приложений.

Каждый компонент платформы Windows Azure играет собственную роль.

На высоком уровне понять Windows Azure очень легко. Это платформа для выполнения приложений Windows и хранения их данных в Интернете ("облаке"). На рисунке 4.3 показаны ее основные компоненты.

увеличить изображение
Рис. 4.3. Windows Azure предоставляет " облачные " приложениям службы для вычисления и хранения на базе Windows

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

Вычислительная служба Windows Azure, естественно, работает на базе Windows. Для обеспечения первоначальной доступности этой службы осенью 2008 г. была открыта для широкой публики CTP-версия. Корпорация Майкрософт разрешила выполнять на Windows Azure только приложения, разработанные на платформе.NET Framework. Сегодня, однако, Windows Azure также поддерживает неуправляемый код, позволяя разработчикам выполнять приложения, которые разработаны не на базе.NET Framework. В любом случае такие приложения написаны на обычных языках Windows — C#, Visual Basic, C++ и других — с помощью Visual Studio 2008 или других средств разработки. Разработчики могут создавать веб-приложения с помощью таких технологий, как ASP.NET и Windows Communication Foundation (WCF), приложения, которые выполняются как независимые фоновые процессы, или приложения, сочетающие и то и другое.

Как приложения Windows Azure, так и локальные приложения могут получать доступ к службе хранилища Windows Azure, делая это одним и тем же способом: с помощью подхода RESTful. Однако Microsoft SQL Server не является базовым хранилищем данных. Фактически хранилище Windows Azure не относится к реляционным системам, и язык его запросов не SQL. Поскольку оно изначально предназначено для поддержки приложений на базе Windows Azure, то обеспечивает более простые и масштабируемые способы хранения. Следовательно, оно позволяет хранить большие двоичные объекты (binary large object — blob), обеспечивает создание очередей для взаимодействия между компонентами приложений и даже что-то вроде таблиц с простым языком запросов. (Для тех приложений Windows Azure, которым требуется обычное реляционное хранилище, платформа Windows Azure предоставляет базу данных SQL Azure, описанную далее.)

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

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

Чтобы позволить своим заказчикам создавать, настраивать приложения и наблюдать за ними, Windows Azure предоставляет портал, доступный с помощью браузера. Заказчик предоставляет Windows Live ID, а затем решает, создавать ему учетную запись размещения для выполнения приложений, учетную запись хранения для хранения данных или и ту и другую. Оплата использования приложения заказчиками может производиться любым удобным способом: с помощью подписки, повременно или как-нибудь иначе.

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

• При создании нового веб-сайта, скажем, такого как Facebook, можно разрабатывать приложения на платформе Windows Azure. Благодаря тому, что данная платформа поддерживает как веб-службы, так и фоновые процессы, приложение может предоставлять интерактивный интерфейс пользователя и асинхронно выполнять работу для пользователей. Вместо того, чтобы тратить время и деньги, думая об инфраструктуре, пусковая группа может полностью сосредоточить свое внимание на разработке кода, который будет приносить пользу пользователям и инвесторам. Компания может также запустить небольшой веб-сайт, требующий незначительных затрат, если у ее приложения очень мало пользователей. Если приложение приобретает популярность и количество пользователей растет, Windows Azure при необходимости позволяет масштабировать его.
• Независимые поставщики программного обеспечения, создающие версию программы как службы имеющегося локального приложения Windows, могут разработать его на базе Windows Azure. Благодаря тому, что Windows Azure главным образом обеспечивает стандартную среду Windows, перемещение бизнес-логики приложения на эту "облачную" платформу не должно создавать особых проблем. Еще раз подчеркнем: разработка на базе имеющейся платформы позволяет независимым поставщикам ПО сосредоточить внимание на бизнес-логике, то есть на том, что позволяет им делать деньги, а не тратить время на инфраструктуру.
• Компания, создающая приложение для своих заказчиков, может выбрать для его разработки платформу Windows Azure. В силу того что Windows Azure поддерживает.NET, не представляет труда найти разработчиков с соответствующими навыками к тому же за разумную плату. Выполнение приложения в центрах обработки данных Microsoft освобождает предприятия от ответственности и расходов на поддержку собственных серверов, превращая капитальные затраты в эксплуатационные расходы. В особенности если у приложения имеются периоды пиковой нагрузки (если это, например, сетевой магазин цветов, которые необходимо вручить во время всеобщего ажиотажа 8 марта), предоставление корпорации Microsoft функции поддержки большой серверной базы, необходимой для этого, может оказаться экономически выгодным.

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

Один из наиболее привлекательных способов использования серверов, доступных через Интернет, — это обработка данных. Цель SQL Azure — решить эту проблему, предлагая набор веб-служб для хранения самой разной информации и работы с ней. В то время, как представители Microsoft заявляют, что постепенно SQL Azure будет содержать целый ряд возможностей, ориентированных на данные, включая создание отчетов, анализ данных и многое другое, первыми компонентами SQL Azure станут база данных SQL Azure Database и средство синхронизации данных Huron. Это наглядно продемонстрировано на рисунке 4.42.

Рис. 4.4. SQL Azure обеспечивает средства в Интернете, ориентированные на работу с данными

База данных SQL Azure Database (ранее известная под названием SQL Data Services) обеспечивает систему управления базами данных (СУБД) в Интернете. Эта технология позволяет локальным и веб-приложениям хранить реляционные и другие типы данных на серверах Microsoft в центрах обработки данных Microsoft. Так же как при работе с другими веб-технологиями, компания платит только за то, что использует, увеличивая и уменьшая объем использования (и затраты) по мере возникновения необходимости в изменениях. Использование базы данных в "облаке" также меняет характер капитальных затрат: на место инвестиций в жесткие диски и ПО для СУБД приходят эксплуатационные затраты.

В отличие от службы хранилища Windows Azure база данных SQL Azure разработана на основе Microsoft SQL Server. Тем не менее в первоначальной CTP-версии 2008 г. база данных SQL Azure Database не предоставляла традиционный реляционный подход к данным. Учитывая отзывы заказчиков, корпорация Microsoft решила внести соответствующие изменения. В дальнейшем база данных SQL Azure Database будет поддерживать реляционные данные, обеспечивая среду SQL Server в "облаке" с индексами, представлениями, хранимыми процедурами, триггерами и многим другим. Доступ к этим данным можно получить с помощью ADO.NET и других интерфейсов доступа к данным Windows. Фактически приложения, которые сегодня получают доступ к SQL Server локально, будут работать почти точно так же с данными в SQL Azure Database. Для работы с этой информацией в "облаке" заказчики могут также использовать локальное ПО, такое как службы отчетов SQL Server.

В то время, как приложения могут использовать базу данных SQL Azure Database в значительной степени также, как локальную СУБД, требования к управлению существенно сокращены. Вместо того, чтобы беспокоиться о технике, например, обеспечивать мониторинг использования диска и обслуживание файлов журнала, заказчик SQL Azure Database может сосредоточить внимание на том, что действительно важно, на данных. Корпорация Microsoft будет отвечать за вопросы эксплуатации. Кроме того, так же как в случае с другими компонентами платформы Windows Azure, использование SQL Azure Database не составляет труда. Нужно просто зайти на веб-портал и предоставить необходимую информацию.

Второй компонент SQL Azure был заявлен под названием Huron Data Sync. Эта технология, разработанная на основе Microsoft Sync Framework и SQL Azure Database, позволяет синхронизировать реляционные данные в разных локальных СУБД. Владельцы данных могут определять, что именно должно синхронизироваться, как должны разрешаться конфликты и многое другое.

Приложения могут использовать SQL Azure самыми разными способами. Приведем несколько примеров.

• Приложение Windows Azure может хранить данные в SQL Azure Database. Несмотря на то, что Windows Azure обеспечивает собственное хранилище, реляционные таблицы не входят в число предлагаемых вариантов. Учитывая то, что многие имеющиеся приложения используют реляционное хранилище, а многие разработчики знают, как с ним работать, значительное количество приложений Windows Azure, скорее всего, будет работать с данными привычным способом, то есть с опорой на SQL Azure Database. Для повышения производительности заказчики могут указать, что определенное приложение Windows Azure должно выполняться в том же центре обработки данных, где SQL Azure Database хранит информацию этого приложения.
• В небольшой компании или подразделении большой организации приложение может использовать SQL Azure Database. Вместо того, чтобы хранить данные в базе данных SQL Server или Access, работающей на компьютере под чьим-то столом, приложение может использовать преимущества надежного и отказоустойчивого "облачного" хранилища.
• Предположим, производитель хочет сделать информацию о продукте доступной для своей дилерской сети и непосредственно для заказчиков. Размещение данных в SQL Azure Database позволит сделать их доступными для приложений, выполняемых на стороне дилеров, и для ориентированных на заказчиков веб-приложений, которые выполняются на стороне производителя.
• Компания с клиентской базой данных, реплицированной в географически удаленных местах, должна использовать компонент Huron для синхронизации этих реплик. Возможно, в каждой из географических точек требуется собственная копия данных для повышения производительности, обеспечения доступности или по каким-то иным причинам. Автоматическая синхронизация может сделать такое обязательное распределение менее проблематичным.

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

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

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

увеличить изображение
Рис. 4.5. Службы.NET Services обеспечивают инфраструктуру в "облаке", которая может быть использована для веб-приложений и локальных приложений

Службы.NET Services состоят из следующих компонентов.

• Управление доступом. Получающий все большее распространение подход к удостоверениям заключается в том, что каждый пользователь должен предоставить приложению маркер, содержащий некоторый набор утверждений. На основании этих утверждений приложение решает, что разрешено делать пользователю. Эффективное осуществление этой процедуры в масштабах компании требует федерации удостоверений, которая позволяет принимать утверждения, сделанные в одной области удостоверений, в другой области. Может также потребоваться преобразование утверждений, изменяющее их при передаче из одной области удостоверений в другую. Служба управления доступом обеспечивает реализацию обеих функций на основе "облака".
• Шина служб. Предоставление служб приложений в Интернете гораздо труднее, чем может показаться. Задача шины служб — упростить эту процедуру, позволяя приложениям предоставлять конечные точки веб-служб, доступ к которым может быть получен другими приложениями — локальными или работающими в "облаке". Каждой предоставленной конечной точке присваивается URI, который клиенты могут использовать для поиска службы и получения доступа к ней. Шина служб также решает проблему преобразования сетевых адресов и прохождения через межсетевые экраны без открытия новых портов для предоставленных приложений.

Приведем несколько примеров использования службы.NET Services.

• Независимый поставщик ПО, который поставляет приложение, необходимое заказчикам из разных организаций, может использовать службу управления доступом для упрощения разработки и эксплуатации приложения. Например, этот компонент.NET Services может преобразовывать различные утверждения, применяемые в разных организациях с различными технологиями идентификации в согласованный набор, подходящий для приложения независимого поставщика ПО. Такое преобразование позволяет также разгрузить механизм федерации удостоверений за счет службы управления доступом, освобождая независимых поставщиков ПО от необходимости выполнения собственной локальной программы федерации.
• Предположим, предприятие хочет открыть доступ к одному из своих приложений торговым партнерам. Оно может распределить функции приложения с помощью веб-служб SOAP или RESTful и зарегистрировать их конечные точки с помощью шины служб. Затем торговые партнеры могут использовать шину для поиска конечных точек и доступа к службам. Это позволяет снизить риски, связанные с предоставлением приложения, поскольку не требует открытия новых портов в межсетевом экране компании. Организация может также использовать службу управления доступом, предназначенную для работы с шиной служб, для рационализации сведений о проверке подлинности, отправленной приложению ее партнерами.

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

Программное обеспечение как Сервис (SaaS)

Программное обеспечение как сервис (Software as a service, SaaS) или программное обеспечение по требованию (Software on Demand, SoD) — бизнес-модель продажи программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя заказчикам доступ к программному обеспечению через Интернет. Основное преимущество модели SaaS для потребителя состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и работающего на нём программного обеспечения. Программное обеспечение как сервис является моделью распространения программного обеспечения, в которой приложения размещены у вендора SaaS или поставщика услуг и доступны для клиентов по сети, как правило, Интернет. Модель SaaS доставки приложений становится все более и более распространенной технологией, которая поддерживает веб-службы и сервис-ориентированную архитектуру (SOA). SaaS также часто ассоциирована с моделью лицензирования, когда оплата происходит по мере получения услуг. Тем временем, услуги широкополосных сетей стали все более и более доступными, для поддержки доступа пользователей из большего количества мест по всему миру.

Огромные успехи, достигнутые поставщиками услуг интернет (ISP), чтобы увеличить полосу пропускания и сохранить возможность использования более мощных микропроцессоров вместе с недорогими устройствами хранения данных. Это обеспечивает огромную платформу для того, чтобы проектировать, разворачивать и использовать программное обеспечение через все области бизнес- и частных вычислений. Приложения SaaS также должны быть в состоянии взаимодейстововать с другими данными и другими приложениями среди большого разнообразия окружающих сред и платформ. Компания IDC описывает две немного отличающихся модели поставки SaaS.

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

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

• Архитектурный Уровень 1 — Специальный/Настраиваемый.

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

• Архитектурный Уровень 2 — Конфигурируемость.

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

• Архитектурный Уровень 3 — Эффективность Мультиарендатора.

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

• Архитектурный Уровень 4 — Масштабируемость.

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

Развертывание приложений в сервис-ориентированной архитектуре является более сложной проблемой, чем развертывание программного обеспечения в традиционных моделях. В результате стоимость использования приложения SaaS основывается на числе пользователей, которые осуществляют доступ к сервису. Довольно часто возникают дополнительные расходы, связанные с использованием услуг сервисной службы, дополнительной полосы пропускания, и дополнительного дискового пространства. Доходы поставщиков услуг SaaS обычно первоначально ниже, чем традиционный расходы за лицензии на программное обеспечение. Однако компромисс для более низких затрат лицензии – ежемесячно возвращающий доход, который рассматривается финансовым директором компании, как более предсказуемый критерий существования бизнеса. К ключевым особенностям программного обеспечения SaaS относятся:

• Управление по сети и сетевой доступ к коммерческому программному обеспечению в централизованных центрах обработки данных, а не на сайтах клиентов, предоставление возможности клиентам получить доступ к приложениям удаленно через Интернет.
• Доставка приложений по модели "один ко многим", в противоположность традиционной модели "один к одному".
• Централизованная модернизация и обновления, что позволяет избежать необходимости в загрузке и установке приложений пользователем. SaaS часто используется в крупных сетях коммуникаций и программного обеспечения для совместной работы, иногда как программное расширение к архитектуре PaaS.

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

• Рациональное управление;
• Автоматизированное обновление и исправление;
• Целостность данных в рамках предприятия;
• Совместная работа сотрудников предприятия;
• Глобальная доступность.

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

Коммуникация как Сервис (CaaS)

Коммуникация как Сервис (CaaS) - построенное в облаке коммуникационное решение для предприятия. Поставщики этого типа облачного решения отвечают за управление аппаратным и программным обеспечением, требуемым для того, чтобы предоставить:

• систему связи, обеспечивающую передачу речевого сигнала по сети Интернет или по любым другим IP-сетям (VoIP),
• обмен мгновенными сообщениями (IM),
• видеоконференц-связь.

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

Модель CaaS позволяет деловым клиентам выборочно разворачивать средства коммуникаций и услуг на оснований оплаты услуг в срок для используемых сервисов. CaaS разработан на ценовой политике общего назначения, которая предоставляет пользователям всесторонний, гибкий и легкий в понимании сервисный план. Согласно Gartner, рынок CaaS, как ожидается, будет насчитывать $2,3 миллиарда в 2011 году, с ежегодным темпом роста более 105 %.

Сервисные предложения CaaS часто связаны и включают интегрированный доступ к традиционному голосу (или VoIP) и данным, дополнительная функциональность объединенных коммуникаций, такие как видео вызовы, совместная работа, беседы, присутствие в реальном времени и передача сообщений, телефонная сеть, местная и распределенная голосовые услуги, голосовая почта. CaaS решение включает избыточное переключение, сеть, избыточность оборудования, WAN failover – что определенно подходит к потребностям клиентов. Все транспортные компоненты VoIP расположены в географически распределенных, безопасных информационных центрах для высокой доступности и жизнеспособность. CaaS предполагает гибкость и масштабируемость для мелкого и среднего бизнеса, чего зачастую сами компании не могут обеспечить. Поставщики услуг CaaS подготовлены к пиковым нагрузкам, оказывают услуги по расширению емкости устройств, состояний или области покрытия по требованию заказчика. Пропускная способность сети и наборы средств могут быть изменены динамически, таким образом, функциональность идет в ногу с потребительским спросом и ресурсы, находящиеся в собственности поставщика не используются впустую. В отличие от поставщика услуг, перспектива клиента фактически не приводит к риску обслуживания устаревшего оборудования, так как обязательства поставщика услуг CaaS заключается в том, чтобы периодически модернизировать или заменять аппаратное и программное обеспечение, чтобы подерживать платформу в технологически актуальном состоянии.

CaaS не требует контроля от клиентов. Это избавляет от необходимости клиентов совершать какие-либо капиталовложения в инфраструктуру, и это устраняет накладные расходы для инфраструктуры. С решением CaaS клиенты в состоянии усиливать коммуникационные услуги класса предприятия, не имея необходимости к построению собственное решение внутри своей организации. Это позволяет клиентам перераспределять бюджет и трудозатраты персонала, использовать их в тех местах, где это наиболее необходимо.

От телефонной трубки, которую можно найти на столе каждого сотрудника до клиентского программного обеспечения на ноутбуке сотрудника, VoIP частная основа, и все необходимые действия между каждым из компонентов в решении CaaS поддерживаются в режиме 24/7 поставщиком услуг CaaS.

• Решения размещения и управления

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

• Удобство управления и функциональность

Когда клиенты пользуются услугами связи на стороне поставщика услуг CaaS, они платят только за необходимую функциональность. Поставщик услуг может распределять стоимость услуг. Как отмечалось ранее, это способствует более экономичному внедрению и использованию общей необходимой функциональности для клиентов. Экономия за счет роста производства позволяет поставщикам услуг производить обслуживание достаточно гибко, они не привязаны к единственному поставщику инвестиций. Поставщики услуг в состоянии усилить решения лучших среди аналогичных поставщиков, таких как Microsoft, Google, Amazon, Cisco, Nortel более экономично.

• Нет затрат средств на оборудования

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

• Гарантируемая непрерывность бизнеса

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

Мониторинг как Сервис (MaaS)

Мониторинг как Сервис (Monitoring-as-a-Service, MaaS) является обслуживаемым в облаке обеспечением безопасности, прежде всего на бизнес платформах. За прошлое десятилетие MaaS стал все более и более популярным. С появлением облачных вычислений, популярность MaaS стала больше. Контроль безопасности затрагивает защиту клиентов – предприятий или правительства от кибер угроз. Служба безопасности играет важную роль в обеспечении и поддержании конфиденциальность, целостность, и доступность средств ИТ. Однако время и ограниченные ресурсы ограничивают мероприятия безопасности и их эффективность для большинство компаний. Это требует постоянной бдительности безопасности инфраструктуры и критических информационных средств. Много промышленных правил требуют, чтобы организации контролировали свою среду безопасности, журналы серверов, и другие информационные средства, чтобы гарантировать целостность этих систем. Однако обеспечение эффективного контроля состояния безопасности может быть пугающей задачей, потому что она требует передовых технологий, квалифицированных экспертов по безопасности, и масштабируемые процесс, ни один из которых не является дешевым. Сервисы контроля состояния безопасности MaaS предлагает контроль в реальном времени, в режиме 24/7 и практически немедленные реагирование по инцидентам через инфраструктуру безопасности. Эти сервисы помогают защитить критические информационные активы клиентов. До появления электронных систем обеспечения безопасности, контроль состояния безопасности и реагирование зависели в большой степени от человеческих ресурсов и человеческих способностей, которые ограничивали правильность и эффективность контролирующих усилий. За прошедшие два десятилетия, были разработаны информационные технологии в системах обеспечения безопасности, которые способны взаимодействовать с центрами операционной безопасности (SOC) через корпоративные сети, что значительно изменило картину. Данные средства включают две важных вещи:

1. Общая стоимость владения центром операционной безопасности намного выше, чем для современной технологии SOC;
2. Достижение более низких операционных затрат безопасности и более высокая эффективность средств безопасности.

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

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

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

Краткие итоги:

В данной лекции была рассмотрена технология предоставления веб-сервисов "инфраструктура как сервис". Был получен базовый материал о технологиях ведущих вендоров Amazon и Microsoft.

Ключевые термины:

Инфраструктура как Сервис, IaaS - предоставление компьютерной инфраструктуры (как правило, это платформы виртуализации) как сервиса.

Платформа как сервис, PaaS – предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, организованная на основе концепции облачных вычислений

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

Коммуникация как Сервис, CaaS - построенное в облаке коммуникационное решение для предприятия MaaS.

4. Лекция: Windows Azure SDK

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

Содержание

• Краткие итоги:

Цель данной лекции – ознакомиться с комплектом средств разработки Windows Azure SDK.

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

Azure Cloud Fabric и службы Azure Storage не поддерживают разработку или отладочные операции в облаке, поэтому Azure SDK позволяет делать это локально в виде приложений Development Fabric (DF) и Development Storage (DS), которые устанавливает Windows Azure SDK. Вместе с SDK также устанавливаются коллекция приложений примеров и библиотеки упакованных классов для облегчения программирования приложений.

Должны быть установлены.NET Framework 3.5 SP1 и SQL Express 2005 или 2008, также необходимо включить ASP.NET и WCF HTTP Activation для IIS 7.0 для Windows Server 2008, Windows Vista SP2, или Windows 7 RC или позже для установки и запуска SDK. Заметки к выпуску включают инструкции для настройки этих опций. Использование SDK не является обязательным, потому что есть возможность пользоваться любыми операционными системами и языками программирования, которые поддерживают HTTP запросы и ответы. Однако, вы увидите что использование SDK интерфейсов прикладного программирования.NET и библиотек для приложений и хранилищ позволяет наиболее просто работать с HTTP напрямую.

После того, как вы установили Azure SDK, Вы должны скачать и установить инструменты Windows Azure для Visual Studio для добавления шаблонов проектов Web Cloud Sevice, Worker Cloud Service, Web and Worker Cloud Service Workflow Service. Вы можете скачать текущую версию Windows Azure SDK и Windows Azure Tools для Visual Studio с главной страницы Windows Azure по ссылке www.microsoft.com/azure/windowsazure.mspx.

После установки Windows Azure Tools в Visual Studio появляются шаблоны Cloud Service в диалоге создания нового проекта. При выборе узла Cloud Service открываются New Cloud Service, который позволяет добавить ASP.NET Web Roles, Worker Roles или CGI Web Roles для нового проекта. Windows Azure SDK позволяет добавить более чем одну роль для каждого типа Cloud Service. Каждая роль использует отдельный экземпляр Windows Azure CPU, так минимальная стоимость запуска проекта в облаке будет примерно 4 * $0.12 = $0.48 в час.

Рис. 5.1. Создание нового проекта Cloud Service в Visual Studio

Добавив указанные роли и нажав ОК, откроется новое решение с проектами WebRole и Worker-Role в Solution Explorer как показано на рис. 5.2.

Узел Roles содержит элементы WebRole, которые указывают на каждую WebRole, которая обеспечивает пользовательский интерфейс ASP.NET для приложения и каждый WorkerRole для вычислительный операций, которые не требуют пользовательского интерфейса или используют страниц ASP.NET WebRole вместо этого.

Рис. 5.2. Solution Explorer Cloud Service

В зависимости от типа Cloud Service проекты включают пространство имен Microsoft.ServiceHosting.ServiceRuntime, которое содержит классы, указанные в таблице ниже.

Таблица.
Класс	Описание
RoleEntryPoint	Обеспечивает методы для управления инициализацией, запуском и остановкой методов сервиса, так же используется для мониторинга состояния сервиса.
RoleException	Сообщает об ошибках когда происходят недопустимые операции внутри роли
RoleManager	Обеспечивает методы для журналирования сообщений и поступающих предупреждений, извлекает настройки конфигурации сервиса и возвращает местоположение ресурса
RoleStatus	Информирует о текущем статусе роли: Healthy, NonExistent, Started, Starting, Stopped, Stopping или Unhealthy

Проекты, которые используют шаблон WebRole определяют веб страницу ASP.NET Default.aspx как начальную точку для пользовательского интерфейса приложения в облаке.

Это сервис объединяет библиотеку класса Common из приложения-образца HelloFabric для содействия в журналировании проблем приложения. Журналы приложения – это практичные средства откладки приложений, запущенных в Cloud Fabric. Для чтения журналов, вы должны скопировать их в Blob массив использую инструментарий портала.

Образец проекта StorageClient включает библиотеку класса StorageClient, которая обеспечивает в объединении с библиотекой.NET Client для сервиса данных ADO.NET, интерфейсный класс Microsoft.NET для HTTP операций над Azure Blob, Queue и Table Storage сервисами. Этот проект также включает консольное приложение, которые позволяет Вам тестировать возможности библиотеки. Консольное приложение C# запускается в Development Fabric с Development Storage.

При установке Windows Azure SDK не устанавливаются образцы приложений, которые включены в Program Files\Microsoft Windows Azure SDK\v1.0\samples.zip. Установите образцы, разархивировав samples.zip в директорию, где Вы имеете права на запись. В таблице ниже можно найти описание некоторых образцов приложений.

Для запуска примера CloudDrive необходим PowerShell.

Директория, в которую было извлечено содержимое архива samples.zip также содержит следующие три пакетных файла (cmd), которые можно запустить из командной строки:

• buildall.cmd строит все образцы проектов без использования Visual Studio:
• createtables.cmd вызывает buildall.cmd и создает базу данных и таблицы, необходимые для образцов, которые используют Table Storage.
• rundevstore.cmd вызывает createtables.cmd и запускает разработку хранилища, размещая его в базе данных, созданной createtables.cmd.

В состав Development Fabric входят следующие исполняемые файлы: DFAgent.exe, DFLoadBalancer.exe, DFMonitor.exe и DFService.exe, которые по умолчанию устанавливаются программой установки Azure SDK в каталог \Program Files\Windows Azure SDK\v1.0\bin\devfabric. После запуска Development Fabric в диспетчере задач вы можете увидеть эти четыре процесса. Сделать это можно выполнив:

• Выберите Программы\Windows Azure SDK\Development Fabric для запуска службы Development Fabric и его пользовательского интерфейса DFUI.exe
• Правый щелчок мыши по значку Development Fabric в области уведомлений панели задач и выбрать запуск службы Development Fabric (рис. 5.3)
• Скомпилировать и запустить приложение Azure в Visual Studio.

Рис. 5.3. Сообщения, отображаемые нажатии правой кнопкой мыши по значку Development Fabric в области уведомлений панели задач

поддержка курса Введение в облачные вычисления
информация [+] Авторы: И.П. Клементьев, В.А. Устинов

рис. 5.4 показывает пользовательский интерфейс DFUI. Когда вы запускаете или останавливаете отладку, соответствующие приложения появляются или пропадают из пользовательский интерфейс DFUI. увеличить изображение Рис. 5.4. Пользовательский интерфейс приложения Development Fabric Платформа Windows Azure поддерживает три типа масштабируемых хранилищ: Неструктурированные данные (blob) Структурированные данные (таблицы) Сообщение между приложениями и сервисами (очереди) Запуская rundevstore.exe или собирая и запуская пользовательский код Azure в Visual Studio, запускаются все три сервиса, даже если Ваш проект требует только один сервис и отображается в пользовательском интерфейсе Development Storage Для защиты от потери данных, облако Azure хранит блобы, таблицы и очереди в минимум трех раздельных контейнерах в одном центре обработки данных. Инструмент геолокации Azure позволяет дублировать данные в нескольких центрах обработки данных Microsoft для уменьшения последствий восстановления после катастроф и для повышения производительности в специфичных географических регионах. Приложение Azure, которые Вы запускаете в Development Framework, могут иметь доступ к локальным данным в Development Storage или к данным, загруженным в облако Azure. Приложение обращается к определенному порту и данным, расположенным в определенных местах в файле конфигурации проекта ServiceConfiguration.cscfg. Файл конфигурации проекта Azure ServiceDefinition.csdef определяет стандартные точки входа и настройки конфигурации, которые хранятся в файле ServiceConfiguration.cscfg. В распечатке 5.1 показано содержимое файла ServiceDefinition.csdef по умолчанию, когда Вы создаете проект Azure, используя один из стандартных шаблонов Windows Azure Tools для Visual Studio (отмечены важные значения). <ServiceDefinition name="SampleWebCloudService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"> <WebRole name="WebRole"> <InputEndpoints> <!-- Must use port 80 for http and port 443 for https when running in the cloud --> <InputEndpoint name="HttpIn" protocol="http" port="80" /> </InputEndpoints> <ConfigurationSettings> <Setting name="AccountName"/> <Setting name="AccountSharedKey"/> <Setting name="BlobStorageEndpoint"/> <Setting name="QueueStorageEndpoint"/> <Setting name="TableStorageEndpoint"/> </ConfigurationSettings> </WebRole> </ServiceDefinition> Листинг 5.1. Содержимое файла ServiceDefinition.csdef (html, txt) Значение InputEndpoint применяется только для хранилищ в облаке. Распечатка 5.2 показывает содержимое файла ServiceConfiguration.cscfg для веб приложения SampleWebCloudService с конфигураций по умолчанию для Development Storage (выделено): <?xml version="1.0"?> <ServiceConfiguration serviceName="SampleWebCloudService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"> <Role name="WebRole"> <Instances count="1"/> <ConfigurationSettings> <Setting name="AccountName" value="devstoreaccount1"/> <Setting name="AccountSharedKey" value="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ 1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="/> <Setting name="BlobStorageEndpoint" value="http://127.0.0.1:10000/"/> <Setting name="QueueStorageEndpoint" value="http://127.0.0.1:10001/"/> <Setting name="TableStorageEndpoint" value="http://127.0.0.1:10002/"/> <!--<Setting name="AccountName" value="oakleaf"/> <Setting name="AccountSharedKey" value="3elV1ndd... Coc0AMQA==" /> <Setting name="BlobStorageEndpoint" value="http://blob.core.windows.net" /> <Setting name="QueueStorageEndpoint" value="http://queue.core.windows.net" /> <Setting name="TableStorageEndpoint" value="http://table.core.windows.net" /> </ConfigurationSettings> </Role> </ServiceConfiguration> Листинг 5.2. Содержимое файла ServiceConfiguration.cscfg (html, txt) Описания элементов файла конфигурации ServiceConfiguration.csfg: Instances count – количество экземпляров вашего приложения, которое будет создано в облаке, когда вы развернете его. AccountName– имя, ассоциированное с Вашим Hosted Service, с которым в создавали учетную запись, для Development Storage это devstoreaccount1. AccountSharedKey шифрует несколько элементов в HTTP запросе. BlobStorageEndpoint– это публичный постоянный Universal Resource Identifier (URI). Для Developer Storage это адрес интерфейса компьютера loopback (localhost = 127.0.0.1) с TCP портом по умолчанию 10000. QueueStorageEndpoint для хранилища в облаке это публичный постоянный URI. Для Developer Storage это интерфейса компьютера loopback с TCP портом по умолчанию 10001. TableStorageEndpoint публичный постоянный Universal Resource Identifier (URI). Для Developer Storage это адрес интерфейса компьютера loopback с TCP портом по умолчанию 10002. Значения конечных точек в пользовательском интерфейсе Development Storage представлены на рисунке 6-6. Вы можете настроить собственные номера TCP портов если при использовании значений по умолчанию возникает конфликт с текущей конфигурацией. Краткие итоги: В данной лекции мы получили первоначальные сведения о работе с Windows Azure SDK. Рассмотрели процедуру создание Cloud Service, пользовательский интерфейс Development Fabric

5. Лекция: Azure Services Platform

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

Содержание

• Архитектура Windows Azure Platform
• Windows Azure Storage
• Azure Table Services
• Пример
• Краткие итоги:
• Ключевые термины

Цель данной лекции – получить представление об архитектуре Windows Azure