Привязка к облачному провайдеру: реальные компромиссы

Когда компания начинает планировать миграцию в облако, тема привязки к вендору всплывает рано. Беспокойство понятно: построив многое на сервисах одного провайдера, смена становится дорогой. Но обсуждение обычно застревает в абстракции. Люди говорят о переносимости в принципе, не задавая вопрос - а что они реально сделали бы иначе, если бы она была.

Попробую сделать этот компромисс более конкретным.

Что такое привязка к вендору на самом деле

Существует несколько разных типов, и они несут разные издержки:

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

Первый тип - это то, о чём обычно думают. Последние два - это то, что обычно бьёт сильнее.

Аргумент в пользу принятия привязки

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

Когда компания ниже определённого размера - скажем, меньше 20 инженеров - абстракция, которую даёт управляемый сервис, часто оправдывает зависимость. Строить мультиоблачный абстракционный слой стоит дороже в создании и поддержке, чем стоит получаемая опциональность.

Аргумент за сохранение дистанции

Компании, которые я видел сожалеющими о глубокой привязке, объединяет паттерн: они оптимизировали под скорость на раннем этапе, а потом обстоятельства изменились. Объект поглощения был на другом облаке. Требования compliance корпоративного клиента требовали хранения данных в регионе, которого провайдер не покрывал. Цены на сервис, на котором они построились, существенно изменились.

Трудность в том, что в момент принятия архитектурного решения эти сценарии кажутся маловероятными. Думать о них всё равно стоит.

Практический подход

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

• Разделяйте слой хранения данных и слой вычислений. Данные, читаемые из нескольких мест, более переносимы, чем данные, встроенные в проприетарный пайплайн.
• Избегайте проприетарных форматов для данных в покое там, где открытые форматы работают так же хорошо. Parquet вместо вендорского колоночного формата, например.
• Строите логику приложения на стандартных API там, где они существуют, а не на проприетарных SDK. Это не всегда возможно, но возможно чаще, чем принято думать.
• Отслеживайте, от каких сервисов вы зависите и есть ли альтернативы. Не чтобы быть готовым переехать, а чтобы знать, сколько будет стоить переезд, если придётся.

Вопрос, который стоит задать

Правильный вопрос не «привязаны ли мы к вендору?» Правильный вопрос: «что мы потеряем, если провайдер поднимет цены на 40 процентов, закроет этот сервис или будет лежать шесть часов в наш пиковый период?» Если ответ вызывает дискомфорт - лучше знать об этом до того, как это стало горящей проблемой.