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

Что такое мультиоблако и какие пути к нему ведут 

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

Развитие подобной инфраструктуры обычно начинается с одного облака. Компания выбирает облачного провайдера и переносит к нему необходимые приложения. Далее начинает присматриваться и к другим облачным провайдерам, планируя наиболее выгодные комбинации. AWS и Azure часто используют для контейнеризированных систем, GCP (облако Google) — для больших объемов данных и машинного обучения. Так постепенно формируется мультиоблако. Иногда поиск новых провайдеров связан с ограничениями местных регуляторов или жесткими требованиями к непрерывности бизнеса. Здесь появляется и такой вариант, как портативное облако — когда приложение является cloud-agnostic, то есть не имеет специфических требований и может быть развернуто на любой конфигурации облачных инфраструктур.

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

Проблемы мультиоблака по сравнению с выбором одного провайдера

Основные проблемы мультиоблачной инфраструктуры связаны с ее автоматизацией. Если вы используете AWS CloudFormation для облака Amazon и Google Deployment Manager для облака Google, то, вероятно, вам придется прописывать все свои политики отдельно для каждого провайдера — даже самые простые правила вроде допустимых конфигураций виртуальных машин. Здесь есть смысл прибегнуть к IaS-инструментам (Infrastructure as Code), таким как, например, Terraform.

Упоминая мультиоблако, люди нередко подразумевают именно создание портативных, cloud-agnostic приложений — эту концепцию мы упоминали несколько абзацев назад. Такой подход требует дополнительных затрат, поэтому стоит предварительно убедиться, действительно ли вам нужен cloud-agnostic подход и какие преимущества он даст именно в вашем случае. «Мы хотим двигаться в сторону cloud-agnostic, потому что для компании стратегически важно иметь поддержку различных облаков» — если это всё, к чему вы пришли, подумайте еще раз, конкретнее. Возможно, вы привязаны к жесткому SLA в пользовательском приложении, но при этом ориентируетесь на active-active или active-passive облачную инфраструктуру? Да, это один из случаев, когда cloud-agnostic может себя оправдать.

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

Для аналогии здесь можно привести две модели создания сложных программных комплексов, когда-то распространенные в индустрии — с использованием реляционных БД SQL или стандартизированной модели J2EE. Для первого решения существует общепринятый стандарт ANSI, на его возможности настолько слабы, что без проприетарных надстроек от вендоров эта модель бесполезна. Поэтому если вы выбираете конкретного вендора SQL, то становитесь привязаны к нему на уровне инфраструктуры. J2EE была разумной альтернативой такого вендор-лока до тех пор, пока в этой сфере не распространились решения на открытом коде.

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

Очень важно систематизировать нагрузочные потоки приложений. Если размещать в облаке нечто реально критичное для бизнеса, то возникают определенные риски. Да, cloud agnostic — это выход: но будьте готовы к дополнительным расходам и отказу от вендорских «вишенок на торте».

Что стоит учитывать при переходе от одного облака к мультиоблаку

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

Далее при планировании автоматизации стоит по возможности придерживаться cloud-agnostic решений. Для деплоя и интеграции можно выбрать уже упомянутый Terraform, для защиты — Hashicorp, для раскатки политик — Open Policy Agent. Подойдите к этому более глобально, с учетом потенциальных потребностей и изменений в будущем.

Иногда о мультиоблаке задумываются для того, чтобы гарантировать работу бизнес-критичных приложений в разных регионах. Но прежде чем планировать такой переход, убедитесь: а ваш текущий, единственный облачный провайдер точно не способен обеспечить требуемую инфраструктуру во всех зонах доступности? Если вам необходим disaster recovery, то, может, будет логичней создать его в другой зоне доступности вашего текущего провайдера?

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

Другой важный вопрос — мониторинг. Если вам нужно будет сравнить данные. У каждого провайдера есть для этого свои инструменты, поэтому, если вы не можете поставить рядом несколько экранов при любой необходимости, подумайте о том, как объединить мониторинг в рамках одного инструмента — например, New Relic или Datadog.

Если обобщить и дополнить сказанное выше, можно выделить пять направлений для описания требований и оценки перехода на мультиоблако:

• расходы на инфраструктуру;

• идентификация и доступ;

• реализация внутренних политик;

• выделение и развертывание ресурсов;

• мониторинг.

Антипаттерны работы в мультиоблачной модели

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

Не стоит планировать такой переход, если у вас отсутствуют универсальные метрики для деплоя приложений. Бывает, что один юнит в пределах организации использует AWS, другой начинает использовать GCP; без некоего общего знаменателя вы просто не оцените результат преобразований .

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

Еще один вопрос связан с управлением — если, например, вы используете контейнеры в разных средах, то как вы организуете для них единые политики? Оцените возможные инструменты для этого — Rancher, Kublr, IBM Satellite, Google Anthos или что-нибудь еще.

Не стоит задумываться о мультиоблаке, если у вас в принципе не было опыта работы с облачными провайдерами. Некоторые начинают свой путь с того, что сразу выбирают пару провайдеров, у которых будет крутиться приложение. Выбрать Azure и GCP? Или AWS и Azure? Начинайте с чего-нибудь одного, а потом уже будет логично задуматься о совместимости. Иначе есть риск столкнуться с проблемами, которые съедят очень много времени — потому что вам придется разбираться как с работой каждого облака, так и с их совместимостью.

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