Здравствуйте, Дельгядо Филипп, Вы писали:

vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.

ДФ>Нее, миграции в БД надо делать несколько иначе.

Как?

A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса

vsb>>Кубер умеет.

ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary

Ну да, формально это дополнительный компонент. И там всего одна дополнительная версия возможна.

A>>>• Возможность быстрого масштабирования нагрузки

vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.

ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.

Почему?