А можно за месяц перевести десятки взаимосвязанных сервисов в новый Kubernetes-кластер так, чтобы пользователи вообще ничего не заметили?
Можно. Но это тот случай, когда «просто перенести» – вообще не вариант.
Мы работали с международным сервисом перевозок, где за четыре недели нужно было сменить инфраструктурного провайдера, перенести сервисы из старого Kubernetes-кластера в новый и одновременно адаптировать их к обновлённой инженерной платформе. При этом приложение нельзя было останавливать: пользователи должны были продолжать оформлять поездки и пользоваться сервисом 24/7.
Начали с аудита каждого сервиса: зависимости, базы, Redis, брокеры, сети, secrets, параметры запуска, health checks – всё, что может неожиданно сломаться после переезда. Потом синхронизировали разработчиков, команды старой и новой платформ и владельцев внешних систем.
А дальше – сервис за сервисом. Новый вариант разворачиваем, проверяем подключения, логи и пользовательские сценарии, только потом переключаем трафик. Старый при этом остается работать, чтобы в случае проблемы быстро откатиться.
К концу четвертой недели все сервисы были в новом окружении, а старую платформу полностью вывели из эксплуатации. Для пользователей как будто ничего не произошло.
Мне нравятся такие проекты: здесь мало просто хорошо знать Kubernetes. Нужно быстро разобраться в чужой системе, увидеть зависимости, договориться с несколькими командами и аккуратно провести изменения на работающем продукте.
Подробности про миграцию – в кейсе на сайте Evrone.
А если у вас тоже есть инфраструктура, которую давно хочется поменять, но страшно трогать работающий продукт – приходите, обсудим. Такие задачи мы умеем разбирать и доводить до результата.
Можно. Но это тот случай, когда «просто перенести» – вообще не вариант.
Мы работали с международным сервисом перевозок, где за четыре недели нужно было сменить инфраструктурного провайдера, перенести сервисы из старого Kubernetes-кластера в новый и одновременно адаптировать их к обновлённой инженерной платформе. При этом приложение нельзя было останавливать: пользователи должны были продолжать оформлять поездки и пользоваться сервисом 24/7.
Начали с аудита каждого сервиса: зависимости, базы, Redis, брокеры, сети, secrets, параметры запуска, health checks – всё, что может неожиданно сломаться после переезда. Потом синхронизировали разработчиков, команды старой и новой платформ и владельцев внешних систем.
А дальше – сервис за сервисом. Новый вариант разворачиваем, проверяем подключения, логи и пользовательские сценарии, только потом переключаем трафик. Старый при этом остается работать, чтобы в случае проблемы быстро откатиться.
К концу четвертой недели все сервисы были в новом окружении, а старую платформу полностью вывели из эксплуатации. Для пользователей как будто ничего не произошло.
Мне нравятся такие проекты: здесь мало просто хорошо знать Kubernetes. Нужно быстро разобраться в чужой системе, увидеть зависимости, договориться с несколькими командами и аккуратно провести изменения на работающем продукте.
Подробности про миграцию – в кейсе на сайте Evrone.
А если у вас тоже есть инфраструктура, которую давно хочется поменять, но страшно трогать работающий продукт – приходите, обсудим. Такие задачи мы умеем разбирать и доводить до результата.