Уходим с Google Cloud — кто-нибудь реально упёрся в vendor lock-in? Как вы это разруливали

[egor9725]

Сидим на GCP: BigQuery, Pub/Sub, Cloud Functions, Firestore. Сейчас начальство хочет мультиклауд ради переговорной позиции по скидкам. Но мы так глубоко в их сервисах, что переезд выглядит как переписать половину. Кто проходил, насколько это больно?

[luka4904]

BigQuery — это самое больное место. Аналог по UX/скорости найти трудно, Athena и ClickHouse близко, но запросы переписывать придётся. Если у вас тонна SQL на BQ-диалекте — закладывайте месяцы, а не недели.

[asyncflux983]

Мой совет: не делайте мультиклауд ради мультиклауда, это удвоение операционной сложности на ровном месте. Лучше абстрагируйте только то что реально может понадобиться перенести: очереди через Kafka вместо Pub/Sub, compute в контейнерах, а не в проприетарных функциях.

[neonapi460]

То есть ты предлагаешь не съезжать целиком, а развязать самые критичные зависимости и дальше торговаться, мол мы технически готовы уйти?

[omegadns845]

Именно так это и работает на практике. Перенеси stateless-нагрузку в k8s (он одинаковый везде), данные держи в открытых форматах типа Parquet на объектном хранилище. Тогда переезд это вопрос конфига, а не переписывания. Сам факт такой готовности уже даёт рычаг в переговорах.

[platon4017]

И помните: реальный lock-in это не API, а команда, которая знает только один клауд. Терраформ-модули, привычки, рантбуки — всё под GCP. Переезд это ещё и переобучение людей, заложите это в смету, а то менеджмент про это вечно забывает.

[oleg_linux]

Отрезвляет. Понесу руководству план: развязываем Pub/Sub и Functions, BigQuery оставляем но готовим Parquet-экспорт, и считаем стоимость переобучения. Спасибо, очень помогли структурировать.

[sqlreact9621]

Проходили похожий путь: BigQuery заменили на ClickHouse Self-Hosted — SQL почти тот же, но миграция ETL заняла 3 месяца из-за нюансов с ARRAY_AGG и оконными функциями. Pub/Sub заменили на Kafka в MSK (AWS) — API другой, пришлось переписать все consumer group логики. Firestore вообще не трогали, оставили как есть через мультиклауд VPN. Честно: если у вас Firestore глубоко вшит в логику с realtime listeners — это самая болезненная часть миграции, аналогов с той же простотой нет.

[danila_rust33]

Мультиклауд ради переговорной позиции — это чаще всего иллюзия. GCP даёт скидки за committed use, но реальный рычаг давления появляется только когда 30%+ нагрузки реально ушло на другую платформу. Без этого скидочный отдел просто улыбнётся. Более рабочая стратегия: выделить один новый сервис, написать его сразу cloud-agnostic (Cloud Run → любой k8s, Pub/Sub → Kafka-compatible), и использовать это как пилот для переговоров.

[roman_js5]

Cloud Functions на GCP и Lambda на AWS совместимы по идее, но не по деталям: таймауты, способы передачи env, лимиты на размер пакета — везде свои. Мы добавили промежуточный слой через функции-обёртки и terraform-модули, которые деплоят одну и ту же бизнес-логику в обе среды. Это +40% кода в infra-репе, но позволяет переключаться. Если бюджет на это не закладывали — честнее говорить что мультиклауд у вас будет на бумаге.