Что не является веб службами в облаке

Облачные вычисления (Cloud computing)

Cloud computing (англ. Cloud — облако; computing — вычисления) — «облачные вычисления» — концепция «вычислительного облака», согласно которой программы запускаются и выдают результаты работы в окно стандартного веб-браузера на локальном ПК, при этом все приложения и их данные, необходимые для работы, находятся на удаленном сервере в интернете.

Компьютеры, осуществляющие такие вычисления, называются «вычислительным облаком». При этом нагрузка между компьютерами, входящими в «вычислительное облако», распределяется автоматически. Простейшим примером cloud computing являются p2p-сети.

В 2010-х годах cloud computing — группа технологий, возглавляющих развитие информационных технологий в целом, имеющая даже большее влияние, нежели в своё время электронный бизнес.

Развитие облачных вычислений

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

Облачные вычисления могут показаться относительно новым явлением. Тем не менее, их история уходит корнями в начало 1950-х, когда появление мейнфреймов позволило нескольким пользователям получить доступ к центральному компьютеру. В 1960-х появились некоторые идеи, напоминающие то, что сегодня мы называем облачными вычислениями – например, концепция «межгалактической компьютерной сети» Дж. К. Р. Ликлайдера [1] .

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

В 1970-е годы виртуализация подняла мейнфреймы на новый уровень, а в 1990-е телекоммуникационные компании начали предлагать подключение к виртуальной частной сети (VPN). В 1999 году Salesforce стала первой компанией, предоставляющей корпоративные приложения через Интернет. Несколько пользователей могли одновременно загружать эти приложения в браузере по невысокой цене.

Изображение:cloud.jpg

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

Современные «облака» появились в 2006 году, когда Amazon.com, в то время книжный интернет-магазин, представил Amazon Web Services (AWS), положив начало движению облачных вычислений. AWS предоставляет широкий набор сервисов, таких как вычислительные мощности и хранилища данных, по сей день оставаясь ведущей и очень надежной инфраструктурой платформ облачных веб-сервисов. Российский рынок мобильных приложений для бизнеса и госсектора: крупнейшие игроки, тенденции и перспективы. Обзор TAdviser

Скоро к Amazon.com присоединились Netflix, Microsoft, Google, Apple и IBM, и рынок облачных вычислений разросся.

В июле 2008 года корпорации HP, Intel, и Altaba (ранее Yahoo) объявили о создании глобальной, охватывающей множество площадок, открытой вычислительной лаборатории Cloud Computing Test Bed для развития исследований и разработок в области cloud computing. Данная лаборатория представляла собой глобально распределенную испытательную интернет-среду, которая поддерживала исследования, направленные на развитие ПО, совершенствование управления центрами обработки данных и решение аппаратных проблем, связанных с интернет-вычислениями гораздо большего масштаба, чем когда-либо раньше. Данная инициатива также должна была способствовать появлению новых интернет-приложений и услуг.

Не осталась в стороне и Microsoft: исполнительный директор корпорации Стив Баллмер сделал заявление о том, что Microsoft планирует выпустить новую операционную систему под кодовым названием «Windows Cloud», которая позволит разработчикам создавать и размещать интернет-приложения. Название «Windows Cloud» указывает на то, что новая ОС будет использовать в своей основе концепцию «вычислительного облака».

На 2014 год большинство крупнейших ИТ-вендоров на мировом рынке, включая Google, Microsoft, HP, Intel, SAP, IBM, Oracle и другие, имеют в своей линейке решения cloud computing.

Свойства и модели облачных вычислений

Основные свойства

NIST в своем документе `The NIST Definition of Cloud Computing` определяет следующие характеристики облаков:

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

Самообслуживание по требованию (On-demand self-service). У потребителя есть возможность получить доступ к предоставляемым вычислительным ресурсам в одностороннем порядке по мере потребности, автоматически, без необходимости взаимодействия с сотрудниками каждого поставщика услуг.

Широкий сетевой доступ (Broad network access). Предоставляемые вычислительные ресурсы доступны по сети через стандартные механизмы для различных платформ, тонких и толстых клиентов (мобильных телефонов, планшетов, ноутбуков, рабочих станций и т. п.).

Объединение ресурсов в пулы (Resorce pooling). Вычислительные ресурсы провайдера объединяются в пулы для обслуживания многих потребителей по многоарендной (multi-tenant) модели. Пулы включают в себя различные физические и виртуальные ресурсы, которые могут быть динамически назначены и переназначены в соответствии с потребительскими запросами. Нет необходимости в том, чтобы потребитель знал точное местоположение ресурсов, однако можно указать их местонахождение на более высоком уровне абстракции (например, страна, регион или центр обработки данных). Примерами такого рода ресурсов могут быть системы хранения, вычислительные мощности, память, пропускная способность сети.

Мгновенная эластичность (Rapid elasticity). Ресурсы могут быть эластично выделены и освобождены, в некоторых случаях автоматически, для быстрого масштабирования соразмерно со спросом. Для потребителя возможности предоставления ресурсов видятся как неограниченные, то есть они могут быть присвоены в любом количестве и в любое время.

Измеряемый сервис (Measured service). Облачные системы автоматически управляют и оптимизируют ресурсы с помощью средств измерения, реализованных на уровне абстрации применительно для разного рода сервисов ((например, управление внешней памятью, обработкой, полосой пропускания или активными пользовательскими сессиями). Использованные ресурсы можно отслеживать и контролировать, что обеспечивает прозрачность как для поставщика, так и для потребителя, использующего сервис.

Модели облачных служб

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

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

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

Модели развертывания

Частное облако (Private cloud). Облачная инфраструктура, подготовленная для эксклюзивного использования единой организацией, включающей несколько потребителей (например, бизнес-единиц). Такое облако может находиться в собственности, управлении и обслуживании у самой организации, у третьей стороны и располагаться как на территории предприятия, так и за его пределами.

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

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

Гибридное облако (Hybrid cloud). Облачная инфраструктура представляет собой композицию из двух или более различных инфраструктур облаков (частные, общественные или государственные), имеющих уникальные объекты, но связанных между собой стандартизированными или собственными технологиями, которые позволяют переносить данные или приложения между компонентами (например, для балансировки нагрузки между облаками).

Достоинства облачных вычислений

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

Недостатки облачных вычислений

зависимость сохранности пользовательских данных от компаний, предоставляющих услугу cloud computing;
появление новых («облачных») монополистов.

Безопасность

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

Задача поставщика — обеспечить как физическую, так и программную неприкосновенность данных от посягательств третьих лиц. Не случайно «облачные» дата-центры как правило проектируются с опорой на самые современные стандарты безопасности (включая вопросы шифрования, а также упомянутые средства антивирусной защиты и защиты от хакерских атак). [2]

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

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

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

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

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

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

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

Виртуализация может быть безопасной и соответствующей нормативным требованиям защиты информации. Тем не менее, запросы клиентов в сфере безопасности пока еще часто опережают возможности поставщиков.

Облачные вычисления: мифы и заблуждения

«Облако» основано только на программном обеспечении

Теоретически вполне можно построить облако на стандартных серверах (x86) и интеллектуальном программном обеспечении. Объединяем несколько виртуальных устройств и получаем «облако». Но на самом деле это далеко не так. По разным причинам, таким как поддержание адекватной производительности (специализированные ASICs или выделенные аппаратные ресурсы), обеспечение совместимости (установка драйверов для каждой новой платформы x86), или функций контроля (HIPPA, PCI-DSS, ведомственная изоляция, и т. д.), еще далеко не все системные разработчики отказались от использования выделенных аппаратных ресурсов для определенных элементов своих дата-центров. В принципе неизбежность виртуализации некоторых компонентов компьютерной среды очевидна. Поэтому лидеры рынка выпускают соответствующее оборудование. Например, Nexus 1000v, который обеспечивает прозрачность трафика виртуальных машин на уровне сетевой безопасности, с встроенной технологией VN-Link, обеспечивающей мобильность сети. А также виртуальный шлюз безопасности и vWAAS. В одних случаях, клиенты выбирают виртуальные устройства. В других случаях, они предпочитают комбинацию программных и аппаратных ресурсов, например, контрольных точек, представленных Nexus 1010v. Все эти унифицированные сетевые услуги обеспечивают системных разработчиков стандартным набором приемов, позволяющих в случае необходимости совместно использовать программные и аппаратные ресурсы.

«Облако» и эластичные ресурсы

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

«Облако» и объединенные ресурсы

Это еще одна область, которую многие связывают только с серверами и системами хранения данных. В течение многих лет, до появления «облака», сеть представляла собой комплексный ресурс, который предоставлял услуги (полоса пропускания, безопасность, сегментация или изоляция, функция QoS, и т. д.) отдельным группам систем. По мере того как сети становились более виртуальными, более автоматизированными, а также росло число их арендаторов, компании, предлагающие решения на этом рынке продолжали расширять интеллектуальную логику своих продуктов, требуемую для функционирования современных «облачных» систем. Эти решения позволяют клиентам развертывать модульные виртуальные системы (например такие, как Vblock и SMT от Cisco).

Виртуализация делает «облако» более гибким

С одной стороны, это абсолютная правда, в отношении динамического распределения ресурсов и оперативного включения новых виртуальных машин с помощью шаблонов и клонов. Однако, это требует некоторых структурных изменений. Например, при использовании vMotion, Live Migration или XenMotion исходная и конечная точки должны быть в одном логическом домене. А опросы администраторов виртуальных систем показывают, что за месяц им приходится выполнять тысячи миграций виртуальных машин. Итак, в дополнение к этой гибкости им осталось только упразднить традиционное разграничение уровней. Для этого им нужно дать возможность строить большие, двухуровневые сети, лишенные постоянных проблем иерархических сетей. И было бы еще лучше, если бы эта концепция охватывала не одну, а множество сетей, тем самым намного упрощая проблему мобильности приложений и предотвращения аварий. Точно также как в свое время сеть стала поддерживать передачу различных мультимедийных данных в масштабе реального времени, теперь она должна приспосабливаться к изменениям, связанным с виртуализацией и динамичными компьютерными средами.

Виртуальная машина – это тот же сервер, только программный

Это не совсем так. Действительно, приложение и гостевая операционная система, наверное, не видят никакой разницы, но сетевым администраторам и службе безопасности это совсем не безразлично. Виртуальная машина больше не начинается и не заканчивается на одном конце кабеля Ethernet. Фактически, ее трафик может вообще не иметь отношения к данному кабелю, если она общается с другой виртуальной машиной в пределах одного и того хоста. Или же она может по нескольку раз в день переходить с одного хоста на другой, занимая тем самым гигабайты трафика (виртуальная машина и система хранения данных). Поэтому гораздо разумнее ввести в «облаке» функцию регистрации всех этих миграций, назначить этим виртуальным машинам определенные политики (безопасность, функция QoS, ролевая система доступа, и т. д.), чтобы ограничить их перемещение в определенные места, и, тем самым, расширить возможности службы технической поддержки. Большинство администраторов виртуальных машин было бы радо получить такие возможности, особенно сейчас, когда у них стали требовать данные о виртуальных машинах, резервном копировании, восстановлении в аварийных ситуациях, гостевой операционной системе, системе хранения данных и всех остальных элементах, которые так или иначе связаны с виртуализацией.

«Облака» планируются, а сети администрируются

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

Оценки эффекта для экономик стран ЕС

В опубликованном в декабре 2010 г. отчете «Облачные дивиденды — 2011» Центр экономических и бизнес-исследований (CEBR) утверждает, что к 2015 г. благодаря облачным вычислениям экономика развитых европейских стран будет получать дополнительно по 177,3 млрд евро в год. Отчет, подготовленный по заказу EMC, стал первой в своем роде оценкой значения освоения облачных вычислений на макроэкономическом уровне для пяти крупнейших экономик Европы.

Авторы отчета CEBR пришли к заключению, что если в Великобритании, Германии, Италии, Испании и Франции внедрение облачных технологий будет продолжатся ожидаемыми темпами, то к 2015 г. они будут приносить экономике этих стран по 177,3 млрд евро в год. Важно отметить, что львиная доля этих средств, как показывает исследование, будет обеспечена за счет освоения частной и гибридной моделей облачных вычислений.

CEBR подсчитал, что годовой экономический эффект от облачных вычислений для каждой страны к 2015 г. составит: Эффект, млрд евро:

Германия — 49,6
Франция — 37,4
Италия — 35,1
Великобритания — 30,0
Испания — 25,2

177,3 млрд евро могут покрыть кредиты, предоставленные некоторым странам-должникам региона, таким как Ирландия (85 млрд евро) и Греция (110 млрд евро), и помогут правительству Великобритании выполнить план сокращения государственных расходов на 95,7 млрд евро за четыре года, о котором оно недавно объявило.

Облачные вычисления — это новый подход к ИТ, при котором технологии становятся доступными для предприятий в нужном объеме и тогда, когда они в них нуждаются, говорится в исследовании. Это ускоряет время вывода товаров на рынок, снимает традиционные входные барьеры и позволяет компаниям использовать новые коммерческие возможности. Усиливая конкуренцию, этот прямой эффект облачных вычислений окажет огромное влияние на структуру рынка во многих секторах экономики, а следовательно, и на мировые макроэкономические показатели, утверждает CEBR.

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

Исследование сосредоточено на трех наиболее распространенных моделях облачных вычислений:

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

CEBR прогнозирует, что к 2015 г. 133 млрд евро, или 75% от общего годового экономического эффекта в 177,3 млрд евро, придется на непубличные модели облачных вычислений. Модель частного облака позволяет убить сразу двух зайцев: организации получают динамичные, предоставляемые по требованию, самообслуживаемые и масштабируемые услуги облачных вычислений, но при этом контроль остается в руках ИТ-подразделения, так что требования безопасности и управляемости не нарушаются.

В процессе исследования CEBR обнаружил также, что частное облако внесет вклад в ускорение темпов развития и создания новых предприятий в размере 23,8 млрд евро. Результирующие косвенные и производные инвестиции и общие расходы создадут дополнительный спрос на товары и услуги, который, в свою очередь, увеличит валовую добавленную стоимость (ВДС) и степень занятости в экономике. CEBR прогнозирует, что до 2015 г. косвенные экономические выгоды в результате дополнительной ВДС во всех пяти странах составят в совокупности 280 млрд евро — по 60 млрд в год — и что косвенная и индуцированная занятость в период между 2010 и 2015 гг. может достичь 2 396 000 работников.

Ведущий экономист CEBR Оливер Хоган (Oliver Hogan) отметил: «Исследование CEBR показывает, что облачные вычисления — это не просто вопрос краткосрочного повышения эффективности ИТ-инвестиций отдельных компаний и, следовательно, их продуктивности. Эта технология может стать критическим макроэкономическим фактором, который будет иметь решающее значение для стимулирования экономического роста в Европе, что особенно важно в сегодняшней неопределенной экономической ситуации. Как фактор улучшения производительных показателей облачные вычисления, вероятно, будут играть особенно важную роль для гарантии сохранения конкурентоспособности Европы на мировом рынке, а значит, и повышения темпов роста экспорта. Более того, как одно из основных современных средств достижения максимальной эффективности инвестиций в ИТ, облачные вычисления могут также стать локомотивом европейских бизнес-инвестиций, которые, в свою очередь, будут двигать вперед европейские страны».

Президент EMC в регионе EMEA Райнер Эрлат (Rainer Erlat) считает: «Подвижность и конкурентоспособность, которую придают предприятиям частные и гибридные облачные вычисления, создают реальные благоприятные возможности для европейского бизнеса — они помогут компаниям наращивать свое преимущество, способствуя экономическому подъему собственных стран. Общепризнано, что для достижения экономического восстановления и сохранения экономической стабильности требуется сокращение задолженности при одновременном поощрении коммерческой конкуренции. Облачные вычисления, которые заменят многие современные ИТ-технологии, предложив более эффективные, гибкие и простые решения, служат реальным средством для этого».

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

Методология исследования

В отчете «Облачные дивиденды» подсчитывается экономия (капитальных затрат и текущих расходов), получаемая компаниями в результате внедрения услуг облачных вычислений, и измеряется влияние этой экономии на макро- и корпоративные экономические показатели, такие как благоприятные возможности для развития бизнеса; создание новых предприятий; косвенная валовая добавленная стоимость (ВДС); вклад в уплату налогов; а также расходы на услуги облачных вычислений с целью определения экономического значения данной технологии для каждой страны. «Облачные дивиденды — 2011» — первый в цикле из двух отчетов. Во втором отчете, который выйдет в феврале 2011 г., будет рассмотрен экономический эффект и влияние облачных вычислений на конкретные отрасли экономики Франции, Германии, Италии, Испании и Великобритании.

Отчет можно загрузить здесь

Прогнозы развития облачной модели

Основная статья: Облачные вычисления: 10 изменений, которые произойдут с ними к 2020 г.

Мы пребываем в начальной стадии развития облачных вычислений (Forrester, август 2012 г). Многие организации делают лишь первые, неуверенные шаги. Но к 2020 г. облако станет главной — и непременной — частью вычислительной инфраструктуры предприятия. Далее .

Примечания

↑Облачные вычисления: Эволюция концепции
↑Безопасность в «облаках»

Веб-службы в Облаке

Лекция 4. Веб-службы в Облаке. Краткая аннотация лекции: Рассмотрим некоторые из веб-служб, предоставляемые концепцией облачных вычислений. Инфраструктура является услугой в концепции облачных вычислений. Есть много разновидностей управления инфраструктурой в облачной окружающей среде. «Инфраструктура как Сервис» (Infrastructure-as-a-Service, IaaS) в основном предоставляется по запросу на базе современных вычислительных технологий и высокоскоростных сетей. «Коммуникаций как Сервис» (Communication-as-a-Service, CaaS). «Программное обеспечение как Сервис» (Software-as-a-Service, SaaS), такие как Amazon.com с их эластичной платформой облака, характеристики, преимущества, и архитектурный уровень обслуживания. Исследуем ключевые особенности использования внешних источников/ресурсов (outsourcing), доступные как «Платформы как Сервис» (Platforms-as-a-Service, PaaS). Поскольку технологии мигрируют от традиционной локальной модели в новую модель облака, сервисные предложения развиваются практически ежедневно. Предложения веб-служб часто имеют много общих характеристик. Часто от клиента требуются лишь минимальные затраты для получения услуги. Масштабируемость предполагается для каждого из типов предложений, но это невсегда необходимо. Многие из «облачных» вендоров еще работают над использованием масштабируемости, потому что их пользователи пока не нуждаются в данном виде услуг. Наконец, устройство и независимость местоположения позволяет пользователям получить доступ к системам независимо от того, где они находятся или какие устройства используют. Цель лекции: Целью данной лекции является обзор веб-служб, предоставляемые концепцией облачных вычислений. Особое внимание уделяется типу «Инфраструктура как Сервис». Текст лекции: Инфраструктура как Сервис (IaaS)

Рекомендуемые материалы

Ответы на Аттестацию официального партнера amoCRM 2023
Информатика
Тест 1 — Основы программирования Си
Программирование и алгоритмизация

Расчетно-графическая работа по курсу «Программирование». Семинар 2. Овладение навыками обработки символьных данных.Вариант 16

Программирование и алгоритмизация
РК №1 — Вопросы
Информатика
Семинар 2, вариант 4
Программирование и алгоритмизация
Пак ответов итоговый тест
Программирование и алгоритмизация

Свободный доступ к предварительно сконфигурированной окружающей среде;
Использование инфраструктуру последнего поколения;
Защищенные и изолированные вычислительные платформы;
Уменьшение риска, используя сторонние ресурсы, поддерживаемые третьими лицами;
Способность управлять пиковыми нагрузками;
Более низкие затраты;
Меньшее время, стоимость и сложность при добавлении или расширении функциональности.

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

Рисунок 4.1 Грид вычисления

Amazon

Рассмотрим один из примеров – Amazon’s Elastic Compute Cloud (Amazon EC2). Amazon EC2 – веб-служба, которая обеспечивает вычислительные мощности порядочного размера в облаке. Это разработано, чтобы сделать веб-вычисления доступнее для разработчиков и чтобы предложить множество преимуществ для клиентов:

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

Amazon EC2 представляет вычислительную окружающую среду, разрешая клиентам использовать веб интерфейс, для получения и управления услугами, необходимыми для запуска одного или более экземпляров операционной системы. Клиенты может загрузить окружающую среду с их настроенными приложениями. Они могут управлять сетевыми правами доступа и так много систем, сколько им нужно. Для использования Amazon EC2, клиентам сначала необходимо создать Amazon Machine Image (AMI). Этот образ содержит приложения, библиотеки, данные и связанные параметры конфигурации, используемые в виртуальной вычислительной среде. Amazon EC2 предлагает использование предварительно сконфигурированные образы, созданные с шаблонами, необходимыми для немедленного запуска. Кода пользователи определили и формировали их AMI, они используют инструменты Amazon EC2 для загрузки образа в Amazon S3. Amazon S3 – склад, который обеспечивает безопасный, надежный и быстрый доступ к клиенту AMI. Прежде, чем клиенты смогут использовать AMI, они должны использовать веб интерфейс Amazon EC2 для настройки безопасности и сетевой доступ.

Во время конфигурации пользователи выбирают, какой тип категории и какую операционную систему они хотят использовать. Доступные типы категорий составляют две различные категории: Стандартный процессор или High-CPU процессор. Большинству приложений лучше всего удовлетворяет Стандартный случай, в который входят маленький, большой и очень большой экземпляры платформы. В случае High-CPU используется пропорционально больше ресурсов центрального процессора, чем памяти произвольного доступа (RAM), что более подходит высоконагруженным приложениям. В случае High-CPU процессора для выбора есть средняя и очень большая платформы. После определения, какую сущность использовать, клиенты могут запустить, завершить, и контролировать так много экземпляров их AMI, сколько необходимо при использовании интерфейсов прикладного программирования веб-службы (API) или большое разнообразие других инструментов управления, которыми производится обслуживание. Пользователи могут выбрать, хотят ли они запускать приложения в разных центрах обработки данных, использовать статические IP адреса конечных точек, при этом они платят только за фактически потребляемые ресурсы. Пользователи также могут выбрать доступные AMI из библиотеки. Например, если необходим обычный Linux сервер, то клиентами может быть один из стандартных Linux сборок AMIs.

Есть довольно много особенностей сервиса EC2, которые обеспечивают существенные льготы для предприятия. Прежде всего, Amazon EC2 обеспечивает финансовую выгоду. Из-за крупного масштаба компании Amazon и большой клиентской базы, это недорогая альтернатива многим другим возможным решениям. Затраты понесенные на запуск и управление разделены между большим количеством клиентов, делая стоимость для любого клиента намного ниже, чем любая другая альтернатива. Клиенты платят очень низкий процент за вычислительные мощности, которые они фактически потребляют. Безопасность также обеспечена через интерфейсы веб-службы Amazon EC2. Эти интерфейсы позволяют пользователям формировать параметры настройки брандмауэра, которые контролируют сетевой доступ к и между группами экземпляров служб. Amazon EC2 предлагает очень надежную среду, где случаи замены могут быть быстро обеспечены.

Динамическая Масштабируемость.

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

Полный контроль над экземплярами.

У пользователей есть полный контроль над их экземплярами. У них есть полный доступ к каждому экземпляру, и они могут взаимодействовать с ними с любой машины. Экземпляры могут быть перезагружены, удаленно используя API веб-службы. Пользователи также имеют доступ к консоли своих экземпляров. Как только пользователи настроили их аккаунт и загрузили их AMI в сервис Amazon S3, им необходимо только запустить экземпляр. Возможно запустить AMI на любом числе экземпляров (или для любого типа), вызвав RunInstances API, который поддерживается Amazon.

Параметры настройки конфигурации могут значительно различаться среди пользователей. У них есть выбор из разных типов экземпляров, операционных систем, и пакетов программного обеспечения. Amazon EC2 позволяет им выбирать конфигурацию памяти, центрального процессора, и системы хранения, которая оптимально подходит для их выбора операционной системы и приложения. Например, выбор пользователя операционной системы может также включать многочисленные сборки Linux, Microsoft Windows Server, и даже OpenSolaris, все запущенные на действительных серверах.

Интеграция с Другими Веб-службами Amazon.

Amazon EC2 работает в соединении со множеством других веб-служб Amazon. Например, Amazon Simple Storage Service (Amazon S3), Amazon SimpleDB, Amazon Simple Queue Service (Amazon SQS) и Amazon CloudFront все интегрированы, чтобы обеспечить полное решение для вычислений, обработки запросов и хранение между широким диапазоном приложений.

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

Amazon SimpleDB — другой веб сервис, разработанный для того, чтобы выполнять запросы на структурированных данных Amazon Simple Storage Service (Amazon S3) в режиме реального времени. Этот сервис работает в соединении с Amazon EC2, чтобы предоставить пользователям возможность хранения, обработки и запросов наборов данных в пределах окружающей среды облака. Эти сервисы разработаны, чтобы сделать веб масштабируемые вычисления легче и более прибыльными для разработчиков. Традиционно данный тип функциональности был обеспечен использованием кластерной реляционной базы данных, которая требует значительных инвестиций. Внедрение данных технологий вызывало больше сложности и часто требовало услуг администрирования и поддержки базы данных.

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

Amazon Simple Queue Service (Amazon SQS) – сервис принимает очереди сообщений для хранения. При использовании Amazon SQS, разработчики могут просто переместить данные, распределённые между компонентами своих приложений, которые выполняют различные задачи, не теряя при этом сообщения. При этом достигается высокая масштабируемость и надёжность. Amazon SQS работает как демонстрация масштабируемой передачи сообщений Amazon, инфраструктуры как сервиса. Любой компьютер, связанный с Интернетом, может добавить или прочитать сообщения без необходимости в установке какого-либо программного обеспечения или специальный конфигурации брандмауэра. Компоненты приложений, использующие Amazon SQS, могут запускаться независимо и не должны обязательно размещаться в той же самой сети, использующей те же самые технологии или работающие в то же самое время.

Amazon CloudFront – веб-сервис для доставки контента (содержания). Amazon CloudFront интегрируется с другими Amazon Web Services. Цель сервиса — дать разработчикам и предприятиям простой способ распространять контент для конечных пользователей с низкой задержкой, высокой скоростью передачи данных, при этом не требуя никаких обязательств. Запросы объектов автоматически маршрутизируются на самый близкий граничный сервер. Таким образом, содержание доставлено с лучшей возможной производительностью. Граничный сервер получает запрос от компьютера пользователя и соединяется с другим компьютером, вызывая оригинальный сервер, где расположено приложение. Когда оригинальный сервер выполняет запрос, он отправляет данные приложения назад на граничный сервер, который передает данные обратно компьютеру клиента, который выполнял запрос. Сервис не является свободным для пользования.

Платформа как Сервис (PaaS)

Развитие «облачных» вычислений привело к появлению платформ, которые позволяют создавать и запускать веб-приложения. Платформа как сервис (Platform as a Service, PaaS) — это предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, организованная на основе концепции облачных вычислений.

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

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

PaaS предлагает более быструю, более экономически выгодную модель для разработки и доставки приложений. PaaS обеспечивает всю инфраструктуру для запуска приложений через Интернет. Аналогичные сервисы предоставляют большое количество компаний, таких как Microsoft, Amazon.com, Google. PaaS основан на модели учета лицензий или модели подписки, таким образом, пользователи платят только за то, что они используют. Предложения PaaS включают рабочие процессы для создания приложений, разработки приложений, тестирования, развертывания и размещения. Также сервисы приложений, виртуальные офисы, командное сотрудничество, интеграцию баз данных, безопасность, масштабируемость, хранение, работоспособность, управление состоянием, инструментарий приборных панелей и много другое.

Главные особенности PaaS включают сервисы для разработки, тестирования, развертывания, размещения и управления приложениями для поддержки жизненного цикла разработки приложений. Веб интерфейсы инструментов создания, как правило, обеспечивают некоторый уровень поддержки чтобы упростить создание пользовательских интерфейсов, основанных на таких технологиях как HTML, JavaScript и других технологиях. Поддержка многопользовательской архитектуры помогает избежать проблем при разработке относительно использования приложений многими пользователями одновременно. Провайдеры PaaS часто включают услуги для управления параллельной обработкой, масштабируемостью, отказоустойчивостью и безопасностью. Другая особенность – это интеграция с веб-службами и базами данных. Поддержка протокола обмена структурированными сообщениями в распределённой вычислительной среде (Simple Object Access Protocol, SOAP) и других интерфейсов позволяют приложениям PaaS создавать комбинации веб-сервисов (которые называют mashup) так же легко, как наличие доступа к базам данных и повторному использованию услуг внутри частных сетей. Способность формировать и распространять код между специализированными, предопределенными или распределенными командами очень увеличивают производительность предложений вендоров PaaS. Интегрированные предложения PaaS обеспечивают возможность для разработчиков, чтобы наиболее хорошо понимать внутреннюю работу их приложений и поведение пользователей при использовании инструментов, подобных приборной панели, чтобы рассмотреть внутренние параметры, основанные на измерениях количества параллельных соединений и т.д. Некоторые предложения PaaS расширяют этот инструментарий, что позволяет составлять счета оплаты за использование.

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.4.

Рисунок 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 поддерживаются в режиме 27/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) через корпоративные сети, что значительно изменило картину. Данные средства включают две важных вещи:

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

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

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

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

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

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

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

Бесплатная лекция: «Содержание» также доступна.

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

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

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

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

1. John W. Rittinghouse, James F. Ransome – «Cloud Computing: Implementation, Management, and Security»

Какие типы служб облачных вычислений существуют?

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

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

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

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

Веб-службы в Облаке

Развитие «облачных» вычислений привело к появлению платформ, которые позволяют создавать и запускать веб-приложения. Платформа как сервис (Platform as a Service, PaaS) — это предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, организованная на основе концепции облачных вычислений.

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

Главные особенности PaaS включают сервисы для разработки, тестирования, развертывания, размещения и управления приложениями для поддержки жизненного цикла разработки приложений. Веб интерфейсы инструментов создания, как правило, обеспечивают некоторый уровень поддержки чтобы упростить создание пользовательских интерфейсов, основанных на таких технологиях как HTML, JavaScript и других технологиях. Поддержка многопользовательской архитектуры помогает избежать проблем при разработке относительно использования приложений многими пользователями одновременно. Провайдеры PaaS часто включают услуги для управления параллельной обработкой, масштабируемостью, отказоустойчивостью и безопасностью. Другая особенность – это интеграция с веб-службами и базами данных. Поддержка протокола обмена структурированными сообщениями в распределённой вычислительной среде (Simple Object Access Protocol, SOAP) и других интерфейсов позволяют приложениям PaaS создавать комбинации веб-сервисов (которые называют mashup) так же легко, как наличие доступа к базам данных и повторному использованию услуг внутри частных сетей. Способность формировать и распространять код между специализированными, предопределенными или распределенными командами очень увеличивают производительность предложений вендоров PaaS . Интегрированные предложения PaaS обеспечивают возможность для разработчиков, чтобы наиболее хорошо понимать внутреннюю работу их приложений и поведение пользователей при использовании инструментов, подобных приборной панели, чтобы рассмотреть внутренние параметры , основанные на измерениях количества параллельных соединений и т.д. Некоторые предложения PaaS расширяют этот инструментарий, что позволяет составлять счета оплаты за использование.

Microsoft Azure

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

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

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

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

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

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

Windows Azure предоставляет

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

Вычислительная служба 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), приложения, которые выполняются как независимые фоновые процессы, или приложения, сочетающие и то и другое.

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

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

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

В отличие от службы хранилища 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 самыми разными способами. Приведем несколько примеров.

Приложение 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 для синхронизации этих реплик. Возможно, в каждой из географических точек требуется собственная копия данных для повышения производительности, обеспечения доступности или по каким-то иным причинам. Автоматическая синхронизация может сделать такое обязательное распределение менее проблематичным.

Службы .NET Services обеспечивают инфраструктуру в

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

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

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

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

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

Что не является веб службами в облаке

Облачные вычисления (Cloud computing)

Развитие облачных вычислений

Свойства и модели облачных вычислений

Основные свойства

Модели облачных служб

Модели развертывания

Достоинства облачных вычислений

Недостатки облачных вычислений

Безопасность

Рекомендации по использованию облаков

Подготовьте сеть

Сначала уясните суть облака

Знайте все детали SLA

Имейте рабочий план

Имейте план аварийного восстановления

Знайте, где ваши данные

Многоплатформная облачность

Нужна стратегия выхода

Облачные вычисления: мифы и заблуждения

«Облако» основано только на программном обеспечении

«Облако» и эластичные ресурсы

«Облако» и объединенные ресурсы

Виртуализация делает «облако» более гибким

Виртуальная машина – это тот же сервер, только программный

«Облака» планируются, а сети администрируются

Оценки эффекта для экономик стран ЕС

Прогнозы развития облачной модели

Примечания

Веб-службы в Облаке

Рекомендуемые материалы

Какие типы служб облачных вычислений существуют?

Веб-службы в Облаке

Microsoft Azure

Добавить комментарий Отменить ответ