Но не все мне о моем своеобразном отпуске писать, поговорим снова о миграции.

Миграционные проекты могут быть краткосрочными и долгосрочными. Все это зависит от размера компании и продукта, а также от требований по uptime и методов переезда (переписываем продукт или lift-and-shift).

Так, например, наш проект GSMG в виду статуса бета-тестирования мог спокойно «полежать» час-другой, пока я не перенес базу и не запустил backend на стороне AWS.

А вот что касается моей основной работы, то тут имеются свои сложности.
Первое - приложение многокомпонентное и нельзя перетащить все сразу. Поэтому сначала мы хотели перенести RabbitMQ (очередь сообщений), затем базу и только в самом конце само приложение.

С «кроликом» пришлось вдоволь намучиться, потому что некоторые микросервисы выступали одновременно и producer’ами сообщений и consumer’ами, что усложняло порядок переключения приложений.
В итоге нам пришлось немного пострадать, но этот вопрос удалось закрыть.

Затем мне поставили задачу унести базу на Амазон. Обьем потерянных данных должен быть равен 0, допустимый downtime - 10 минут на отрезке с часу до двух ночи.

Под это дело я задействовал Database Migration Service (о чем я по приезду напишу в Medium), успешно перенес базу, убедился, что репликация работает без проблем (речь идет о тестовом окружении).
И после этого я получаю письмо от руководителя, что проект замораживается на неопределенный срок, потому что CTO малость надоели конфликты в планировании между Ops и Dev. Потрясающе.

По этому поводу хочу сказать следующее.

Когда вы столкнетесь с похожим проектом, решите все рабочие конфликты со смежными командами. Разберитесь с техническим долгом в максимально сжатые сроки. Приостановите разработку нового функционала. Сделайте все возможное, чтобы запланировать переезд на срок МАКСИМУМ полгода.
Объясните все бизнесу, убедитесь, что верхушка в курсе о рисках и последствиях.

Сделайте свою работу.

У меня все.