Зависимость от облачного провайдера: стоимость, которой нет в счёте
Привязка к одному облачному провайдеру выглядит дёшево на бумаге - до момента, когда нужно переговорить условия, мигрировать или восстановиться после сбоя. Что учитывать, пока вы ещё не заперты.
Раз в несколько месяцев ко мне приходит CTO или IT-директор с вариацией одного и того же вопроса: «Мы на 100% у [провайдера] - это проблема?» Честный ответ: зависит от обстоятельств, но риск почти всегда недооценён, а стоимость становится видна только тогда, когда выйти дёшево уже не получится.
Это не аргумент за гибридное облако как принцип. Мультиоблако ради мультиоблака создаёт больше сложности, чем решает. Вопрос в другом: сделали ли вы осознанный выбор относительно своей зависимости - или она просто накопилась.
Из чего состоит lock-in
Lock-in - это не одна вещь. У него несколько слоёв, которые накладываются друг на друга.
Первый слой - egress-стоимость данных. Перемещение данных из облака стоит денег, и тарификация структурирована так, чтобы это было невыгодно. Если объёмы данных значительны и когда-нибудь понадобится мигрировать или запустить аналитику на своей инфраструктуре - эта стоимость может оказаться существенной.
Второй слой - проприетарные сервисы. Управляемые базы данных, serverless-функции, шины событий, ML-платформы - каждый глубоко используемый сервис создаёт абстракцию, которую предоставляет только этот провайдер. Перестроить на эквивалентных сервисах у другого займёт месяцы, а не дни.
Третий слой - операционные знания. Ваша команда знает консоль, CLI, IAM-модель и мониторинг одного провайдера. Эти знания не переносятся. При смене фактически придётся строить операционные компетенции заново.
Четвёртый слой - позиция на переговорах. Когда приходит продление контракта, провайдер, который знает, что уйти сложно, ведёт переговоры совсем не так, как тот, кто знает о реальной альтернативе.
Где концентрируется реальный риск
Не вся привязка одинакова. Наиболее высокорисковые ситуации, которые я встречаю:
- критически важные данные хранятся исключительно в проприетарном формате или движке базы данных;
- бизнес-логика жёстко завязана на платформенные системы событий или сообщений;
- мониторинг и алертинг работают только через инструменты провайдера;
- контракт с вендором не содержит SLA на скорость экспорта данных в сжатые сроки.
Именно в этих сценариях сбой провайдера, изменение ценообразования или провал переговоров по продлению оставляют вас без выхода, который не стоил бы дороже, чем остаться.
Тест на портируемость
Полезное упражнение: пройдитесь по тому, как выглядела бы миграция для трёх ваших наиболее критических рабочих нагрузок. Не «теоретически можем ли мы мигрировать» - а «что мы реально сделаем за 90 дней, если придётся?» Запишите блокеры. Этот список даёт более честную картину реальной зависимости, чем любая архитектурная диаграмма.
Если никто в команде не может ответить на этот вопрос для какой-то нагрузки - она заперта, хотели вы того или нет.
Что выглядит как разумное снижение риска
Полная портируемость обычно не окупается. Но несколько точечных решений существенно снижают риск:
- Хранить критические данные в открытых форматах (Parquet, Avro, JSON) везде, где это возможно, даже если запрашивать их через проприетарный движок.
- Предпочитать управляемые базы данных с открытым исходным кодом (Postgres, MySQL, Redis) проприетарным аналогам - если только проприетарный не решает конкретную задачу, которую открытый не решает.
- Держать infrastructure-as-code достаточно портируемым, чтобы другой провайдер мог его прочитать - даже если никогда не запустите там.
- Убедиться, что контракт включает чёткие обязательства по экспорту данных с определёнными сроками.
Эти решения требуют чуть больших усилий на поддержку, но не требуют философской приверженности мультиоблаку. Они просто оставляют варианты открытыми.