Мультиоблако — это модно. Но возможны проблемы

Мультиоблака все популярнее

Согласно прогнозам IDC, в ближайшие годы расходы на публичные облачные сервисы увеличатся более чем вдвое: с $229 млрд в 2019 г. до почти $500 млрд в 2023-м. И один из трендов этого рынка — мультиоблачная стратегия. По данным компании Gartner 81% компаний, использующих облака, работают с двумя или более провайдерами публичных облаков. Как ожидается, мультиоблачность останется ключевой тенденцией и в 2021 г. Мультиоблачные сервисы все чаще приходят на выручку в случаях, когда компании не могут сделать что-то на своих мощностях, и нельзя все вынести в одно публичное облако.

Сценариев использования мультиоблачности существует немало: например, ИТ-отдел может размещать базы данных в одном облаке, объектное хранилище — в другом, а третье использовать для аварийного восстановления. Разработчики могут выбрать облачную платформу, которая обеспечит наилучшую работу всех сервисов и приложений.

Между тем мультиоблачная стратегия — не панацея, считает эксперт Дэвид Линтикум (David Linthicum), имеющий за плечами опыт руководящей работы в компаниях уровня Fortune 100. Она подходит не всем и имеет свои минусы. Лишь знание принципов работы мультиоблака в совокупности с грамотной стратегией перехода к его внедрению поможет организации выстроить надежную инфраструктуру и эффективно распределить нагрузки.

Распределенные приложения

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

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

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

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

Сценарии развертывания

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

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

Больше облаков — больше проблем

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

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

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

Единственная причина, по которой стоит создавать приложение для нескольких облачных провайдеров — особая необходимость. Например, если удается найти подходящую систему искусственного интеллекта/машинного обучения только в одном облаке, а требуемую базу данных в другом. Конечно, стоит поискать способы их объединения в одном облаке, но бывают случаи, когда распределение между разными облаками остается единственным выбором. При создании облачных приложений происходит такое довольно редко — лишь в 2-3% случаев.

Лучше проще, да лучше

Таким образом, у мультиоблака есть свои ограничения, о которых следует знать и помнить. Мультиоблачность предполагает объединение технологически разных платформ. Из-за этого возникают сложности управления приложениями или сервисами, снижается гибкость. Мультиоблако, одновременно работающее на платформах нескольких провайдеров, даже самых крупных, таких как Amazon AWS, Microsoft Azure и Google Cloud, будет функционально ограниченным, поскольку у каждой из платформ свои стандарты.

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

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

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

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

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

Короткая ссылка на материал: //cnews.ru/link/a17271