Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, andsm, Вы писали:


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

Нее, миграции в БД надо делать несколько иначе.
Ну и приложения должны уметь работать с разными "версиями" БД, иначе не бывает.


A>>• Быстрота доставки изменений на рынок (time to market)

vsb>Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.

Это не всегда оптимальная стратегия, так как предполагает не TBD, а Gitflow, что больно.
А если такое делать с TBD, то нужно еще фичафлагами управлять.


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

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


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



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

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

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