Основные принципы масштабируемости и устойчивости облаков

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

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

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

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

Облако – модель, обеспечивающая повсеместный и удобный сетевой доступ по требованию к общему пулу настраиваемых вычислительных ресурсов. Основное преимущество облачных вычислений – масштабируемость, способность быстро увеличивать или уменьшать объем ИТ-ресурсов по мере необходимости для удовлетворения меняющегося спроса.

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

Масштабируемость облачного приложения обеспечивается благодаря пяти свойствам облака:

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

Масштабируемость приложения не сводится только к динамическому увеличению или уменьшению объемов доступных ресурсов в соответствии с меняющимися требованиями, но предполагает задействование нескольких ЦОДов для обеспечения устойчивости. Устойчивость достигается за счет использования нескольких регионов и зон доступности.

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

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

Гиперскейлеры, в том числе Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud, IBM Cloud и Google Cloud Platform, заранее преду­преждают клиентов о возможности сбоев в пределах одной зоны доступности. Эталонная архитектура, предоставляемая этими провайдерами, определяет базовые конфигурации ресурсов, в число которых входит использование нескольких зон доступности для обеспечения устойчивости.

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

Согласно проведенному в 2021 г. Uptime Institute Intelligence глобальному исследованию, лишь 18% владельцев и операторов ЦОДов считают, что располагают достаточной информацией об эксплуатационной устойчивости. При этом почти каждый четвертый заявляет, что более высокая информированность побудит их использовать облако для критически важных приложений.

Масштабируемость и отказоустойчивую архитектуру в облаке лучше всего описать на примере простого веб-приложения, развернутого у провайдера публичного облака (рис. 1).

 

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

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

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

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

  

Виртуальные машины на обеих схемах работают по модели IaaS («Инфраструктура как услуга»). Это означает, что провайдер отвечает за ЦОД, физический сервер и механизм разделения серверов на блоки, доступные по требованию, – обычно через виртуализацию. В зону его ответственности входят установка, обслуживание и обновление аппаратного и программного обеспечения для реализации согласованного с пользователем уровня предоставления услуг. У пользователя нет доступа к ЦОДу, серверам или уровню виртуализации. При этом он отвечает за масштабирование и устойчивость. Архитектура, показанная на рис. 2, разработана так, чтобы виртуальные машины были масштабируемыми и устойчивыми.

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

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

Устойчивость прочих облачных сервисов, таких как базы данных, интерфейсы управления, службы хранения и шлюзы API, также обеспечивается облачным провайдером. Во время сбоя у AWS в регионе США-Восток-1 в декабре 2021 г. многие пользователи, скорее всего, пострадали от того, что не смогли реализовать устойчивость и восстановление в своих приложениях. API, которые использовались для управления сервисами системы доменных имен Route 53 DNS и сети доставки контента Cloudfront CDN, размещались только в одном регионе, и пользователи не могли вносить изменения в эти сервисы во время сбоя, поскольку в AWS не настроили отказоустойчивость между регионами.

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

Для повышения отказоустойчивости системы, показанной на рис. 2, трафик можно было бы распределять по нескольким регионам (с большей степенью разделения с точки зрения инфраструктуры ЦОДов), используя службы балансировки нагрузки на основе DNS. Такую архитектуру сложно и дорого проектировать из-за проблем с пропускной способностью: задержка между регионами может снизить производительность, а репликация данных между регионами – увеличить затраты на трафик. У пользователей как минимум должен быть резервный репозиторий кода и конфигураций, которые можно использовать для восстановления приложения в другом облачном регионе в случае выхода из строя основного региона.

Альтернативные облачные провайдеры, такие как OVHcloud, Linode и DigitalOcean, в отличие от гиперскейлеров предлагают гораздо более ограниченный спектр услуг и вариантов настройки. Стандартизация и автоматизация снижают накладные расходы и соответственно цены. Ключ к успеху – простота: эти провайдеры уделяют больше внимания рекламе устойчивости своей инфраструктуры, а не предлагают клиентам самим создавать устойчивые приложения с балансировкой трафика между ЦОДами. Но они также располагают набором услуг для обеспечения масштабируемости, в числе которых балансировщики нагрузки, зоны доступности и автомасштабирование.

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

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

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

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

Не составляет труда скопировать и вставить код, работающий на виртуальной машине в одном облаке, на виртуальную машину в другом, если операционная система на этих машинах одна и та же (обычно это Linux). Однако вспомогательные услуги PaaS, которые делают каждую услугу масштабируемой и устойчивой, скопировать затруднительно. Например, балансировщик нагрузки AWS создан только для внутреннего использования AWS, и его код недоступен для пользователей. Он использует API-интерфейсы AWS для связи с другими сервисами AWS и не может взаимодействовать с Microsoft Azure и Google Cloud.

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

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

Платформы управления облачными средами (Cloud management platform, CMP) предлагают стандартный графический интерфейс для управления как публичными, так и частными облачными площадками, взаимодействуя с ними с помощью соответствующих API. CMP могут также управлять ресурсами инфраструктуры, например, переместить виртуальную машину из одной среды в другую. Но они не могут переместить приложение от одного облачного провайдера к другому, потому что приложение, скорее всего, было создано с учетом особенностей конкретного провайдера.

Исторически CMP создавались компаниями – разработчиками ПО, такими как VMware, Turbonomic, IBM, Microsoft и ServiceNow. Не так давно гиперскейлеры начали поставлять локальные (on-premise) версии своих общедоступных облаков, обычно в виде сборки из серверов и СХД, устанавливаемых в ЦОДах клиента (два примера – AWS Outposts и Azure Stack Edge). Такие площадки функционируют как частные облака в том смысле, что услуги дата-центра здесь обеспечивает ИТ-отдел заказчика. Провайдер публичного облака отвечает за оборудование и промежуточное ПО, обеспечивающее облачную функциональность, и ИТ-отдел заказчика не может вносить в них какие-либо изменения.

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

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

Согласно данным Uptime Institute Intelligence, даже с CMP и локальными облачными площадками 20% провайдеров считают управление различными площадками самой большой проблемой для своих клиентов, уступающей по значимости только прогнозированию будущих требований к емкости.

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

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

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

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

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

  

Движок контейнеризации, установленный в операционной системе на сервере, поддерживает работу с несколькими контейнерами. Каждый контейнер исполняет код рабочей нагрузки.

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

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

 

На рис. 4 показано, как немикросервисная архитектура масштабируется в ходе работы. В этом примере требованиям к производительности облачного приложения удовлетворяет одна виртуальная машина. В момент времени 0 достигается максимальная мощность виртуальной машины. Система автомасштабирования создает новую виртуальную машину для увеличения емкости, но это занимает около 5 мин, так как каждой виртуальной машине необходимо полностью загрузить ОС. Балансировщик нагрузки (не показан на схеме) распределяет данные по виртуальным машинам. При падении спроса дополнительная виртуальная машина может отключиться автоматически. Принятие решения об ее отключении осложняется тем, что для повторного запуска снова потребуется 5 мин, а слишком раннее отключение может привести к задержкам при повторном повышении спроса.

В микросервисной архитектуре (рис. 5) приложение разделено на два сервиса, A и B. Каждый сервис может создавать дополнительную емкость, добавляя контейнеры для управления нагрузкой.

 

В момент времени 0 достигается пороговое значение емкости виртуальной машины или сервера. Сервис A имеет достаточно ресурсов, но сервис B испытывает затруднения и снижает производительность приложения. Через 10 с приложение завершает работу контейнеров с сервисом A и отдает приоритет сервису B для временного удовлетворения потребности в емкости. Сервисы взаимодействуют друг с другом с помощью API. Завершив свои задачи, контейнеры закрываются, а новые контейнеры, поддерживающие сервис A, создаются через 20 с.

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

Cloud Native Computing Foundation (CNCF), проект некоммерческой организации Linux Foundation, отслеживает свыше 1200 проектов, продуктов и компаний, связанных с облачно ориентированными технологиями. Цель CNCF – снизить сложность этих технологий. Но пока все они находятся в зачаточном состоянии, и не существует простого стандартного подхода к реализации облачно ориентированных концепций. Контейнеры и микросервисы, разбивая приложения на большое количество частей, затрудняют их отслеживание и управление ими. Облачно ориентированные инструменты могут снизить техническую сложность, но само их внедрение – задача нелегкая.

Поскольку контейнеры легки, абстрагированы от оборудования и операционных систем и управляются через API, поставщики облачных услуг все чаще используют их для поддержки мультиоблачных сред. Google Anthos и Microsoft Azure Arc – это платформы управления контейнерами, работающие в публичных и частных облаках. Изначально эти платформы имели дело только с контейнерной службой своего провайдера, но сейчас они также могут управлять контейнерами в промежуточном ПО, установленном пользователем в локальной инфраструктуре и конкурирующих облачных сервисах. Такая модель может повысить устойчивость, помогая создавать приложения для разных облачных провайдеров и площадок. Однако сложность управления контейнерами и микросервисами может привести к другим проблемам, способным повлиять на устойчивость. Технология применения контейнеров для обеспечения устойчивости и масштабируемости в облаках все еще находится в стадии разработки.

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

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

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

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

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

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

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

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

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>