Статья
11/20/2015

Октябрь 2015

Том 30, номер 10

Microsoft Azure - Microsoft Azure — общая картина

Тони Мелег | Октябрь 2015

Продукты и технологии:

Microsoft Azure

В статье рассматриваются:

платформенные сервисы;
инфраструктура информационных центров Azure;
инфраструктурные сервисы.

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

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

Крупная ставка Microsoft

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

Azure можно грубо разделить на три уровня: инфраструктуру информационных центров, инфраструктурные и платформенные сервисы, как показано на рис. 1.

Рис. 1. Концептуальная схема Microsoft Azure

Microsoft Azure	Microsoft Azure
PaaS (Platform Services)	PaaS (платформенные сервисы)
IaaS (Infrastructure Services)	IaaS (инфраструктурные сервисы)
Cloud Scale Global Datacenters	Глобальные информационные центры масштаба облака

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

Эти сервисы доступны не только в общедоступном облаке Azure, но и где угодно — в вашем информационном центре, на хосте или у субподрядчика. Microsoft недавно объявила о выпуске Azure Stack, который делает это возможным: считайте, что это пакет, содержащий «ноу-хау» и сервисы Azure и развертывающий все это на вашем аппаратном обеспечении. В конце концов, это просто программное обеспечение, опирающееся на основные принципы Windows Server и Hyper-V. Однако в этом новом мире все это на самом деле вас не интересует, потому что вы сосредоточены только на необходимых вам сервисах и на том, как правильно проектировать архитектуру своего решения и программировать с использованием этих сервисов.

Строительные блоки платформы

Итак, давайте окинем широким взглядом всю Azure. На рис. 2 расположены все сервисы в наборе групп возможностей (capability groups), разделенные между инфраструктурными и платформенными сервисами. Вы должны рассматривать инфраструктурные сервисы как те возможности, которые позволяют вам создавать низкоуровневую инфраструктуру для ваших существующих приложений. Вам нужны компьютеры с дисками, компьютеры должны быть соединены друг с другом сетью, диски должны быть общими, их требуется подключать к другим системам и сетям в других местах и т. д.

Рис. 2. Сервисы Microsoft Azure

Рисунок – по-хорошему его нужно полностью перевести, но возникает две проблемы: 1) не весь текст на нем разборчив, хотя о многом можно догадаться, и 2) русская версия будет заметно длиннее и совершенно точно не уместится даже на такой иллюстрации

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

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

Отступление: инфраструктура информационных центров Azure

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

Рис. 3. Глобальное распределение информационных центров Microsoft Azure

Operational	В эксплуатации
Announced/not Operational	Объявлены/пока не эксплуатируются
* Operated by 21Vianet	* Обеспечивается 21Vianet

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

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

Инфраструктурные сервисы: больше контроля, больше работы

Глядя на 60 или около того сервисов на рис. 2, понимаешь, насколько этот список приводит в замешательство. Но большинство приложений, созданных вами, в основном содержат лишь несколько возможностей. Обычно имеются веб-сервер и реляционная база данных, плюс набор других частей для идентификации, отчетности и, возможно, для каких-то пакетных процессов (batch processes). Давайте пока сфокусируемся только на веб-инфраструктуре и базе данных.

Прямо сейчас вы должны сделать выбор: на каком уровне абстракции вы работаете — инфраструктурном или платформенном? Запускаете ли вы какие-то VM, устанавливаете веб-сервер и базу данных и просто приступаете к работе? Вспомните: эта абстракция в основном охватывает физические серверы, хранилище/диски и сеть, но не ПО, которое вам нужно выполнять на этих серверах. Вроде бы все просто, звучит знакомо, и, знаете ли, так оно и есть. Это как раз то, что вы делаете и делали на протяжении всей своей карьеры. Посмотрите на рис. 4. В VM есть виртуальные диски, и они могут быть общими между разными VM или подключаемыми к конкретной машине. VM можно размещать внутри виртуальных сетей, чтобы они могли взаимодействовать, а сети можно подключать к вашему информационному центру, равно как и к региональным информационным центрам Azure. Все это делается через абстракцию программного обеспечения, а значит, в конечном счете вы получите компьютер с одним или более дисками, который находится в сети, подключенной к другим компьютерам.

Рис. 4. VM-абстракция серверов, дисков и сетей

Load Balancer	Средство балансировки нагрузки
Virtual Machines	Виртуальные машины
Virtual Network	Виртуальная сеть
Gallery Windows	Галерея Windows Linux SQL
Storage Blobs / Files (Virtual Disks)	Storage Blobs / Files (виртуальные диски)

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

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

Скажем, вашему приложению требуется приличный уровень масштабирования и отказоустойчивости. Можно легко создать веб-ферму VM и веб-серверов, а также создать кластер для базы данных. Вы знаете, как это все делается (или это знает ваш лучший друг из IT-отдела), — не легко, но выполнимо. Вы можете сделать это в любое время дня и ночи, вы можете подготовить это в любой точке мира, вы платите только за то, что используете, и в любой момент можете передумать, освободить все и вообще ничего не платить. Звучит слишком хорошо, чтобы быть правдой. В чем же подвох?

А подвох на инфраструктурном уровне в том, что вам по-прежнему надо выполнить уйму работы, чтобы все развернуть и запустить. Как только все запущено и выполняется, вам придется потрудиться еще больше, чтобы это продолжало работать. Однако помощь можно получить, особенно для той части, где вы готовите свою систему к выполнению. При развертывании на предприятии (on-premises) развернуть сложный набор взаимосвязанных VM более проблематично, но в Azure можно задействовать такие средства, как Azure Resource Manager и автоматизацию через Windows PowerShell, а также множество других сторонних решений. Как только все заработало, вы по-прежнему должны применить обновления ко всему программному обеспечению, используемому вами в VM, в том числе к ОС, с которой вы работаете. Вы должны управлять работоспособностью всего прикладного ПО, что в случае веб-сервера и базы данных не слишком трудно, но гораздо сложнее при масштабировании или добавлении других возможностей.

Вы расплачиваетесь за контроль большей работой. Если вам нужен контроль, то придется потратить больше усилий на создание нужной системы и ее поддержание в работоспособном состоянии.

Платформенные сервисы: меньше контроля, меньше работы

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

Это верно, и платформенные сервисы — отличный тому пример. Картина сервисов Azure на рис. 2 показывает две абстракции платформенных сервисов для двух строительных блоков, необходимых в примере: веб-сервер и база данных. В Azure этими абстракциями являются Web Apps (в разделе Web and Mobile) и SQL Database (в разделе Data). Вы подготавливаете эти сервисы в Azure так же, как и любой другой сервис, т. е. переходите на Azure Management Portal, выбираете нужный сервис и заполняете требуемые детали: название сервиса, местоположение информационного центра, уровень начальной производительности/оплаты и т. д.

Здесь мы наглядно видим, что такое «меньше контроля — больше работы». Возьмем, к примеру, базу данных. Я подготавливаю базу данных в информационном центре North Europe (Северная Европа). Менее чем за минуту я получаю полностью работающую базу данных, а затем я должен развернуть свою схему и данные в базе данных и подключить свое веб-приложение. Никакого ПО устанавливать не требуется; я получаю то, что хотел, а именно: базу данных SQL. По сути, я получаю не просто базу данных, я целых три базы данных, которые совместно работают в кластере с высокой доступностью, обеспечивая мне невероятные уровни отказоустойчивости. Я могу подстраивать производительность этих трех баз данных в большую или меньшую сторону, просто выбирая другой уровень производительности (что, естественно, меняет расценки). Обойти создание этой кластеризованной базы данных нельзя — вы просто получаете это, так как сервис всегда стремится к тому, чтобы ваша база данных работала без перебоев, а такой вариант — лучший способ добиться этого.

Как видно на рис. 5, похожая модель применяется, когда вы подготавливаете веб-инфраструктуру для своего приложения с помощью Azure Web Apps. Вы можете выбрать количество экземпляров, используя простой ползунок. Вы уменьшаете или увеличиваете количество экземпляров, а остальное делает сервис. Вы можете даже сообщить системе делать это за вас, исходя из текущей нагрузки или расписания. Еще важнее, что задача сервиса — всегда предоставлять указанное вами количество экземпляров, вести мониторинг и исправлять поврежденные экземпляры. Ваша задача — просто написать код своего веб-приложения и передать его сервису, чтобы тот убедился, что все в порядке.

Рис. 5. Изменение количества экземпляров веб-приложения

Итак, абстракция платформенных сервисов, в принципе, предоставляет сервис, который берет на себя заботу о подготовке, отказоустойчивости и управлении. «Дополнительная проблема», созданная этой абстракцией, заключается в том, что вы теряете какую-то часть контроля. Вы не в состоянии выбрать ПО и не можете попасть «внутрь песочницы», чтобы настроить и оптимизировать ПО, используемое из ОС по всему стеку, — для вас это черный ящик. Вы также теряете контроль над возможностями сервиса, лишаетесь доступа к API этого сервиса, т. е. над тем, как код вашего приложения взаимодействует с сервисом. Может быть, вам нужно нечто специфическое, например, в базе данных, что данный сервис не обеспечивает. Возможно, это какой-то специфический тип данных или даже целая возможность вроде полнотекстового поиска. Или же вы переносите существующее приложение в облако и возможности, используемые в вашем приложении, не совпадают с возможностями сервиса в Azure. Что делать?

Строительные блоки сервисов Azure на рис. 2 разделяют все сервисы на IaaS или PaaS, но не думайте, что их нельзя использовать совместно, пересекая границу между ними. Отнюдь, как раз можете. Нет никаких причин, почему вы не могли бы, например, задействовать PaaS-сервис Web App, скажем, с VM, где вы установили Oracle под управлением Linux или SQL Server под управлением Windows. Тем самым вы можете сбалансировать уровень контроля и объемы работ. По сути, можно зайти еще дальше. Поскольку все эти строительные блоки просто ожидают, когда ими воспользуются, разумеется, их можно задействовать откуда угодно. Нужен лишь простой API или какой-то существующий протокол, уже используемый вами для взаимодействия с этими сервисами. Вы можете применить любой из блоков в существующих системах в вашем информационном центре. Или использовать в сочетании со сторонними блоками и даже от провайдеров других облаков. Конечно, это предполагает, что приложение устойчиво к задержкам, которые могут появиться при таких комбинациях.

Другие сервисы

Зачем нужны все эти возможности в Azure? Что ж, если вы оглядите собственное IT-пространство, все приложения, работающие сегодня в производственной среде, то обнаружите довольно широкий набор прикладного ПО, обслуживающего эти приложения: системы обмена сообщениями, средства анализа данных, инфраструктуру идентификации, уровни защиты, системы резервного копирования, хранилища данных, системы мониторинга и управления и многое другое. В совокупности вам нужно все. Я предпочитаю рассматривать Azure как набор «деталей конструктора Lego для IT». Вам не потребуется все время использовать каждый тип блока при создании следующего приложения, но все они необходимы в вашем конструкторе, т. е. в инструментарии.

Как решить, какие блоки задействовать при создании нового приложения? На самом деле здесь нет никаких отличий от того, как это было всегда: вы должны понимать, что делают конкретные строительные блоки, отобрать те из них, которые подходят под специфические потребности вашего приложения, и принять решение. Вся штука в том, что создание приложений в облаке происходит иначе и сложнее. Вам придется проделать некоторые дополнительные вещи из-за фундаментальной концепции, заключающейся в том, что вы работаете в «общей» инфраструктуре. Это означает, что у многих сервисов есть ограничения, и эти ограничения различаются в зависимости от различных функциональных уровней и тарифных планов, используемых вами; вы должны знать, что они собой представляют. Вспомните: вам незачем делать их константами, вы предпочтете варьировать их на основе нагрузки на приложение. Вы должны программировать с учетом этих ограничений, а также доступности и отзывчивости сервиса. Вы можете использовать те же инструменты, языки и инфраструктуры при создании решений, а также применять все сервисы, которые на самом низком уровне имеют API на основе REST плюс оболочки, специфичные для инфраструктуры. То есть вы можете обращаться к строительным блокам буквально откуда угодно, где есть простой веб-стек, будь то хоть датчик. (Кстати, это стало причиной того, что облако создало такой мощный стимул к взрывному появлению решений для Интернета вещей.)

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

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

Работа в условиях постоянных перемен

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

Теперь осуществляется поддержка версий сервиса (service versioning), а это означает, что к сервису добавляются новые возможности, которые могут разрушить текущую реализацию этого сервиса и приложения, опирающиеся на него. Поэтому приходится принимать решение о поддержке очередной версии, т. е. о создании новой реализации, существующей бок о бок со старой. Такое было недавно сделано в Azure с Azure SQL Database. Статью, описывающую новшества в Azure SQL Database версии 12, см. по ссылке bit.ly/1Dcjpo4.

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

Хотите узнать больше? На виртуальном мероприятии AzureCon вы сможете послушать экспертов в области Azure, просмотреть вопросы и ответы и найти сведения обо всех последних новшествах в Azure. Кроме того, вы можете подписаться на доступ ко всему архиву конференций по ссылке bit.ly/1KRD76d.

Тони Мелег (Tony Meleg) — технический руководитель по продуктам в группе Microsoft Azure. Занимается созданием технического контента для различных аудиторий, популяризацией Azure. Умеет рассказывать о сложных вещах простым языком.

Выражаю благодарность за рецензирование статьи экспертам Microsoft Мэтту Нунну (Matt Nunn) и Хосе Мигелю Паррелле (Jose Miguel Parrella).

Share via