Что такое «многооблачность» и почему это важно?

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

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

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

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

Когда переходить на мультиоблако?

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

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

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

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

Мультиоблако также полезно, когда вам нужно использовать технологию, которая не всегда связана с областью деятельности вашего текущего провайдера. У компании, использующей поставщика виртуальных вычислений, ориентированного на Linux, может возникнуть потребность в запуске сервера Windows. Такая рабочая нагрузка может иметь больше смысла в Microsoft Azure, где есть непосредственная поддержка операционной системы.

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

Проблемы, с которыми вы можете столкнуться

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

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

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

Согласованность — еще одна проблема, которую вам нужно решить с самого начала. Хотя вы хотите извлечь выгоду из достоинств каждой платформы, ваше собственное приложение должно быть единообразным в том, как оно разрабатывается и развертывается. Используете автоматизированное развертывание CI/CD в своих проектах на AWS? Убедитесь, что вы используете что-то подобное и со своими рабочими нагрузками Azure.

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

Мониторинг различных облаков, задействованных в вашей системе, может оказаться непростой задачей. Большинство организаций выберут форму кросс-облачной системы мониторинга, такую как Datadog, Grafana или New Relic. Эти инструменты имеют свою сложность и кривые обучения, но позволяют объединить все ваши ресурсы в единую визуализацию. Это более эффективно, чем пытаться работать с панелями управления нескольких облачных провайдеров, чтобы понять, откуда произошел сбой.

О чем еще следует подумать?

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

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

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

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

Заключение

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

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

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