Vendor lock-in: как думать о выходе из облака до входа в облако
Выгоду от PaaS нужно считать вместе с ценой выхода - иначе это не стратегическое решение, а дорогостоящая случайность.
Разговор о переносе в облако почти всегда начинается с плюсов: не нужно покупать и обслуживать железо, можно масштабироваться быстро, платишь только за то, что используешь. Всё это правда. Проблема в том, что разговор о минусах происходит редко, а разговор о цене выхода - почти никогда.
К тому моменту, когда вопрос о выходе становится актуальным, компания обычно уже плотно сидит на проприетарных сервисах. И тогда выясняется, что "облако" - это не просто другое место для тех же рабочих нагрузок. Это другие контракты, другие зависимости и другая стоимость смены решения. О том, что именно провайдер реально обещает, - и разрыве между тем, что написано в SLA, и тем, что в нём не написано, - стоит знать до того как зависимость накопилась.
Что создаёт реальный lock-in
Привязка к облачному провайдеру бывает разной по глубине.
Самый поверхностный уровень - инфраструктура: виртуальные машины, объектное хранилище, сети. Это относительно легко перенести, хотя и не бесплатно.
Следующий уровень - управляемые базы данных и очереди. Переход на аналогичный сервис у другого провайдера потребует работы, но это выполнимо при наличии воли и бюджета.
Самый глубокий уровень - проприетарные PaaS-сервисы: конкретные функции, конкретные аналитические платформы, конкретные ML-пайплайны, привязанные к конкретному облаку. Здесь переход уже не миграция, а фактически повторная разработка.
Глубина привязки растёт незаметно. Команда выбирает удобный сервис, потому что он есть рядом и хорошо интегрирован. Потом ещё один. Потом архитектура начинает выглядеть как нативная облачная, и это воспринимается как достижение. На самом деле это момент, когда выход становится по-настоящему дорогим.
Как считать реальную стоимость PaaS
Когда команда предлагает использовать проприетарный облачный сервис, разговор обычно ведётся в рамках операционной стоимости: сколько стоит в месяц, насколько это быстрее, чем строить самим.
Правильнее добавить ещё одно измерение: стоимость выхода через три-пять лет.
Эта стоимость складывается из нескольких компонентов:
- объём кода и конфигураций, которые придётся переписать;
- время простоя или параллельной работы во время миграции;
- потеря функциональности, у которой нет прямого аналога;
- время команды на переобучение и адаптацию;
- риск для бизнеса в период перехода.
Никто не считает эту сумму точно. Но даже грубая оценка меняет разговор. Решение, которое стоит дёшево сейчас, может оказаться очень дорогим потом - не потому что провайдер плохой, а потому что зависимость накопилась.
Где принцип переносимости оправдан, а где нет
Стремление к полной переносимости - такая же крайность, как полное игнорирование lock-in. Если компания пишет весь код так, чтобы он работал на любом облаке, она теряет значительную часть выгоды от использования облака вообще.
Разумный подход - дифференцировать.
Для компонентов, которые несут основную бизнес-логику или составляют ядро продукта, стоит предпочитать стандартные интерфейсы и переносимые решения. Это ядро не должно быть жёстко привязано к одному провайдеру.
Для вспомогательных сервисов - мониторинг, логирование, CI/CD - проприетарные облачные инструменты часто оправданы: они удобны, хорошо интегрированы и их замена не критична для продукта.
Для экспериментов и прототипов - можно использовать всё, что доступно. Прототип по определению не живёт вечно.
Вопросы, которые стоит задать до принятия решения
Перед тем как выбрать проприетарный сервис или платформу, я обычно задаю себе несколько вопросов:
- Что произойдёт с этим компонентом, если через три года мы захотим сменить провайдера?
- Есть ли у этого сервиса открытый или стандартный аналог, который решает задачу с приемлемыми дополнительными усилиями?
- Сколько нашего собственного кода будет завязано на проприетарный API?
- Понимает ли команда, что именно создаёт зависимость, и принимает ли это осознанно?
- Зафиксировано ли это решение как архитектурное с явным обоснованием?
Последний вопрос важнее, чем кажется. Большинство случаев глубокого lock-in возникают не из стратегического решения, а из серии удобных маленьких шагов, которые никто не отслеживал в совокупности.