Презентация мультиоблачной стратегии всегда звучит безупречно. Избегайте привязки к поставщику. Оптимизируйте затраты, запуская рабочие нагрузки у того провайдера, который дешевле для конкретной задачи. Повышайте отказоустойчивость, распределяя ресурсы по независимым доменам сбоя. На бумаге это убедительный аргумент. На практике же команды, работающие с мультиоблачными развертываниями, часто описывают нечто противоположное: удвоенную операционную сложность, сниженную вдвое наблюдаемость и категорию проблем с надежностью, которые возникают только потому, что вместо одного облака их два.Команда, с которой я тесно сотрудничал, перенесла рабочие нагрузки на AWS и конвейеры инференса машинного обучения на GCP из-за лучшей доступности и ценообразования GPU в то время, и следующие восемь месяцев они боролись с классом инцидентов, который не предвидели: сбоями, которые были не виной приложения и не виной ни одного из облачных провайдеров, но существовали на границе между ними. Всплески задержки передачи данных, которые появлялись только под нагрузкой. Краевые случаи истечения срока действия токенов аутентификации, которые срабатывали только во время межоблачных вызовов. Взаимодействие сетевых политик, которое проходило все предпроизводственные тесты и давало сбой в продакшене в 3 часа ночи. Отдельные проблемы не были сложными. Они были сложными, потому что диагностические инструменты каждого облака смотрели внутрь, а сбой жил в пространстве, которое ни один из инструментов не охватывал.