- Все используют мультиоблачные технологии, так что это правильно, верно?
- Как компании подходят к созданию мультиоблачной среды?
- Повествование о мультиоблачности: отделяем факты от вымысла
- Разоблачение мультиоблачной стратегии: за пределами заблуждения блокировки
- Мультиоблако для непрерывности бизнеса: критическая оценка
- Заключение
Возможно, вас заставили поверить, что это необходимо для адекватного контроля рисков и во избежание привязки к поставщику. Но оправдывает ли такая стратегия свои обещания?
Основываясь на своем опыте облачной трансформации, я рассмотрю, что на самом деле представляет собой мультиоблако, почему так много бизнес-лидеров думают, что они уже находятся в его среде, и как они к этому пришли. Я также углублюсь во всю эту шумиху и в то, кто ее разжигает. Далее я рассмотрю концепцию привязки к поставщику облачных услуг и то, насколько далеко действительно стоит заходить в направлении независимости от поставщика. Наконец, я выясню, является ли такая среда лучшим (или даже необходимым) решением для обеспечения непрерывности бизнеса.
Все используют мультиоблачные технологии, так что это правильно, верно?
Вы, наверное, видели часто упоминаемую цифру: 87% компаний уже используют мультиоблачные технологии. Часто это используется как аргумент в пользу того, что такой подход — правильный выбор: "раз так поступает большинство, значит, это оптимальный путь". Но стоит ли слепо следовать за трендом, не понимая сути?Но стоп, погодите, что же на самом деле подразумевают под мультиоблачным подходом? В большинстве случаев это значит, что компании используют одного гиперскейлера (например, AWS, Azure, Яндекс или VK) в сочетании с несколькими SaaS-решениями вроде Microsoft 365 или Salesforce. Но такой сценарий не охватывает всех сложностей и преимуществ настоящей мультиоблачной стратегии.
Реальная мультиоблачность — это более сложная архитектура, включающая использование нескольких публичных облаков для управления инфраструктурой и платформенными решениями (IaaS и PaaS). Это не просто распределение рабочих нагрузок между разными провайдерами, но и комплексное решение задач отказоустойчивости, гибкости и снижения рисков, связанных с зависимостью от одного поставщика.
Прежде чем принимать такой подход как универсальное решение, важно понять, зачем это делают другие компании и какие сложности могут возникнуть при внедрении такой стратегии.
Как компании подходят к созданию мультиоблачной среды?
Когда слышите, что компании внедряют мультиоблачные стратегии, часто предполагается, что это было осознанное и стратегически выверенное решение. Однако реальная картина зачастую гораздо сложнее. Такие среды часто возникают не по причине глобальной стратегии, а как результат стечения обстоятельств.Во многих случаях данный подход появляется случайно. Например, при слияниях и поглощениях приобретенная компания может использовать другую облачную платформу. Перевод всей инфраструктуры в единое облако может быть слишком затратным и трудоемким, поэтому компании предпочитают сохранить существующую среду.
Другой распространенный сценарий — автономия отдельных подразделений. В крупных организациях подразделения могут самостоятельно выбирать поставщиков облачных услуг, что приводит к разнородности инфраструктуры. Хотя центральная ИТ-служба может рекомендовать определенное облако, автономные команды иногда принимают решения в пользу других платформ из-за влияния поставщиков или других внутренних причин.
Важно понимать, что мультиоблачная стратегия не всегда является результатом обоснованного планирования. Часто это просто следствие естественной эволюции IT-инфраструктуры под воздействием различных факторов. Поэтому, когда кто-то ссылается на 87% компаний в контексте таких стратегий, стоит задуматься, насколько осознанным был этот выбор, и не стоит ли за ним случайный набор обстоятельств.
Данный подход может возникнуть не только как результат четкой стратегии, но и как следствие организационных особенностей или рыночных условий. Это понимание помогает трезво оценивать необходимость перехода к мультиоблачной модели, взвешивая реальные выгоды и риски.
Итак, в следующий раз, когда кто-то попытается использовать цифру 87%, чтобы убедить вас в том, что данная стратегия — это правильная стратегия, проявите критическое мышление и подумайте, почему они пытаются повлиять на ваше мнение.
Это плавно подводит нас к следующей части статьи – нарративному контролю.
Повествование о мультиоблачности: отделяем факты от вымысла
Эти стратегии часто окружены нарративами, которые больше напоминают маркетинговые кампании, чем объективные рекомендации. Возникает вопрос: кто стоит за этим и с какой целью?В статье на ту же тему «Мультиоблачность — худшая практика» автор отмечает, что сторонники этого подхода входят в одну из категорий:
- Продавцы облачных решений, которым выгодно предлагать свои сервисы, увеличивая продажи через архитектуры, предполагающие несколько облаков.
- Нишевые игроки, стремящиеся конкурировать с крупнейшими провайдерами, такими как AWS, Azure и Google Cloud.
Приведу пару примеров последнего: как определить «нативное облачное приложение»? Скорее всего, вы ответите, что это приложение может работать в любом облаке. Однако несколько лет назад оно означало решение, оптимизированное под конкретные управляемые сервисы облачного провайдера. Вопрос о том, кто изменил это определение и почему, заслуживает анализа. Оставлю читателю в качестве упражнения рассмотреть, кто и почему породил это изменение.
Другим примером этого является «гибридное мультиоблако». Если вы поищете примеры успешных внедрений такого подхода, большинство из них будут касаться автоматизированного переноса виртуальных машин из локальной среды в одно облако. Но если все, что у нас есть сейчас, — это сценарий, в котором некоторые виртуальные машины работают локально, а некоторые другие — в (едином) общедоступном облаке, то разве это не то, что называют «гибридным облаком»? Как и почему сюда вкрался этот корень «мульти»? Локальный гипервизор, на котором работают некоторые виртуальные машины, не соответствует определению облака, поэтому «мультиоблако» здесь не имеет значения.
Разоблачение мультиоблачной стратегии: за пределами заблуждения блокировки
Для многих организаций данная стратегия кажется очевидным решением, особенно когда речь идет о снижении рисков привязки к одному поставщику. В теории, распределение рабочих нагрузок между несколькими облаками позволяет избежать зависимости от конкретного провайдера и связанных с ней рисков, таких как повышение цен, снижение уровня поддержки или необходимость трудоемкой миграции в будущем. Но что скрывается за этим видимым преимуществом, и действительно ли такой подход оправдан?Принятие мультиоблачной стратегии связано с рядом технических и организационных трудностей. Несмотря на схожие предложения от AWS, Azure и GCP, у каждого провайдера есть свои особенности в управлении идентификацией, доступом, автоматизацией и безопасностью. Эти различия приводят к необходимости адаптации при переносе рабочих нагрузок между облаками, что влечет за собой дополнительные расходы и требует значительных усилий.
Компании, стремящиеся избежать зависимости от одного поставщика, часто пытаются создать уровни абстракции, которые будут унифицировать использование облачных сервисов. Однако такие решения несут свои риски. Во-первых, они дорого обходятся в разработке и поддержке. Во-вторых, абстракция может ограничить использование продвинутых функций, предлагаемых отдельными облаками, и свести эксплуатацию к базовому набору возможностей. В итоге компании оказываются в ситуации, где они вынуждены выбирать между гибкостью и доступом к передовым технологиям.
Создание независимых от провайдера решений часто требует значительных вложений, которые могут не окупиться. Более того, отказ от использования специфичных сервисов и инструментов каждого облака может привести к снижению эффективности и замедлению инноваций. Парадоксально, но стремление избежать привязки к одному поставщику может привести к новым ограничениям и барьерам, когда компании не могут воспользоваться всеми преимуществами конкретной платформы.
Итак, действительно ли такая стратегия — панацея от всех рисков? Ответ не так однозначен. Хотя мультиоблачные решения и предлагают определенные преимущества в плане гибкости и снижения рисков, на практике они могут быть чрезмерно сложными и дорогостоящими в реализации. Вместо универсального подхода к управлению несколькими облаками, многие компании могут найти более рациональные и экономичные альтернативы, такие как рефакторинг приложений при переходе на нового поставщика или оптимизация использования конкретного облака.
Такие стратегии обещают свободу и независимость, но часто приводят к усложнению инфраструктуры, высоким затратам и снижению эффективности. Для многих компаний оптимальным подходом может стать фокус на углубленной интеграции с одним провайдером с возможностью гибкого перехода, а не попытка распылить ресурсы на управление несколькими облаками. Прежде чем принимать решение о внедрении мультиоблачной среды, важно трезво оценить все риски, затраты и потенциальные выгоды.
Мультиоблако для непрерывности бизнеса: критическая оценка
Многие компании рассматривают такой подход как способ гарантировать непрерывность бизнеса в случае недоступности основного поставщика облачных услуг. Опасения относительно сбоев, банкротства или потери доступа к сервисам толкают их на внедрение резервных стратегий. Однако стоит ли подобный сценарий тех затрат и сложностей, которые влечет за собой мультиоблачная архитектура?Поддержание такой архитектуры требует синхронизации всех компонентов, версий ПО и настроек безопасности в нескольких облаках. Это не только сложно технически, но и требует значительных финансовых и людских ресурсов. Такой подход ограничивает доступ к уникальным возможностям каждого облака, вынуждая использовать базовые решения и обходные пути для поддержки функционала. Результатом становятся высокие операционные издержки и увеличение сложности систем.
Вместо дорогостоящих мультиоблачных решений, компании могут сосредоточиться на других стратегиях обеспечения непрерывности бизнеса. Одна из таких — использование инфраструктуры как кода (IaC) и автоматизации. Этот подход позволяет быстро переносить системы с одного облачного провайдера на другой при необходимости. Вместо постоянного поддержания данной среды, компании могут инвестировать в гибкие инструменты миграции и проработку сценариев перехода, оставаясь при этом в рамках одного провайдера.