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