Привязка к вендору - это реальные деньги, а не абстракция
Как зависимость от одного облачного провайдера или платформы накапливается как конкретное финансовое и операционное обязательство, и как думать об этом до того, как это станет важно.
Привязка к вендору обычно возникает в архитектурных обсуждениях как теоретическая проблема. Инженеры упоминают её, кто-то фиксирует как риск, а затем команда продолжает использовать наиболее удобные инструменты от основного облачного провайдера. Пять лет спустя компания обнаруживает, что переход к другому провайдеру - или переговоры о лучших условиях с текущим - стоит значительно дороже, чем кто-либо ожидал.
Я не утверждаю, что привязки следует всегда избегать. Иногда выигрыш в продуктивности от глубокой интеграции с платформой действительно перевешивает затраты на переключение. Но эти компромиссы должны приниматься осознанно, с реалистичной оценкой того, во что обойдётся выход из зависимости. Такой расчёт почти никогда не проводится.
Из чего реально складывается привязка
Привязка - это не единственное решение. Это сумма сотен небольших решений, принятых со временем, каждое из которых по отдельности кажется тривиальным: используем управляемый сервис баз данных вместо своего; используем очередь сообщений провайдера вместо опенсорсной; пишем конвейер деплоя с помощью собственных инструментов провайдера.
Каждое из этих решений разумно само по себе. Управляемая база данных экономит инженерное время. Очередь сообщений хорошо интегрирована и удобна в использовании. Инструменты деплоя имеют хорошую документацию.
Накопление и создаёт проблему. После трёх лет таких решений система не просто размещена в облаке - она построена с облачной платформой в качестве несущей конструкции. Миграция - это не вопрос перемещения контейнеров на другое железо. Это замена десятка сервисов, у которых нет аналогов в другом месте и за которыми стоят годы операционной истории и настройки.
Самый сложный для обнаружения вид затрат
Наиболее конкретная форма затрат на привязку - невозможность договариваться. Компания, которая реально может работать на другом провайдере, имеет настоящие рычаги влияния при продлении контрактов. Компания, которая не может реально мигрировать, не может правдоподобно угрожать этим, и коммерческие условия это отражают.
На большом масштабе облачные счета согласовываются, а не публикуются. Возможность уйти - или правдоподобная угроза уйти - стоит чего-то измеримого в этих переговорах. Компания, построившая всё на проприетарных сервисах одного провайдера, отказалась от этого рычага влияния.
Что переносимо, а что нет
Не все облачные сервисы несут одинаковый риск привязки. Вычисления и хранилище на уровне инфраструктуры относительно переносимы - контейнеры могут работать на нескольких провайдерах, объектное хранилище имеет достаточно стандартные паттерны доступа, что инструменты миграции существуют. Более высокий риск привязки сидит в управляемых сервисах без прямого эквивалента в другом месте: проприетарных базах данных с функциями, недоступными в опенсорсных аналогах, serverless-средах выполнения с моделями триггеров, специфичными для провайдера, ML-платформенных интеграциях, построенных вокруг собственных API провайдера.
Архитектурный выбор не в том, чтобы избегать всех проприетарных сервисов. В том, чтобы знать явно, для каких сервисов принимается привязка, и оправдывает ли выгода накопленные затраты на выход.
Практический аудиторный вопрос
В любой момент времени полезный вопрос звучит так: если завтра наш облачный счёт удвоится и мы решим серьёзно оценить альтернативы, что реально будет стоить миграция - в инженерном времени и в пересоздании функциональности? Если ответ «несколько месяцев работы для умеренной команды» - привязка управляема. Если ответ «честно говоря, мы не сможем сделать это меньше чем за два года» - зависимость выросла за пределы того, на что большинство менеджментов явно соглашалось.
Этот вопрос значительно легче ответить, задавая его регулярно, небольшими дозами, чем когда он задаётся впервые в разгар коммерческого кризиса.