Распределенный монолит?

Даже удивительно, но значительно чаще, чем каждое второе решение, аудит которого проводим, – распределеный монолит. Сколько индустрия теряет, страшно представить. Это ж как нам не хватает архитектурной экспертизы (в широком смысле).

И иногда даже можно не смотреть на as-built, достаточно посмотреть на as-designed, это ведь так очевидно, на той же компонентной, по названиям даже (если исходить из смысла названий):
API Service -> Manager Service -> Data Service -> DB

Это типичный Layered Monolith:
Controller -> Manager -> Service -> Repository -> DB

То есть получили издержки на сетевые вызовы, сериализацию, ретраи, дискавери, трассировку, частичные отказы, если не считать координационных издержек, совместимости, распределенного внесения изменений, времени на деплой… и не получили главного преимущества микросервисов - автономности. Хотя называется оно в документах, конечно, «Микросервис UserService», «Микросервис Nginx».

Варианта тут всего два: компоненты, которые всегда изменяются вместе, следует либо объединить, либо действительно развязать.

Однако, стоит сделать важную оговорку. Названия – это, конечно, хорошо, однако мы ж про инженерию, а в инженерии нельзя просто сказать - должно быть больше или должно быть меньше, в инженерии для каждого распределенного компонента должно существовать экономическое или архитектурное обоснование (все, часть, одно из тех, что ниже, если оно критически важное, могут быть и другие):

• Независимое масштабирование
• Независимый жизненный цикл
• Отдельная команда
• Отдельный уровень безопасности
• Изоляция отказов
• Независимый темп изменения
• Отдельная модель данных
• Существенная внешняя интеграция

И если такого (никакого) обоснования нет, компонент добавляет сложность, но не создает архитектурной ценности.