История изменений

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

Если кратко расписать, как я это вижу:

Монолит: легко начинать писать, до определённого размера оптимальный подход, легко масштабировать, не требуют выделенной инфраструктуры для логгирования и метрик, не требуют выделенной инфраструктуры для запуска (типа куба).

Сервисы с одной базой: легко вырастают из монолита (просто какой-то кусок выносим в отдельное приложение и заменяем вызовы функций на HTTP вызовы), HTTP даёт хорошую границу, которую пересечь не так просто, полезно для соблюдения разграничения. В целом удобней для работы нескольких людей.

Микросервисы с разными базами: оптимальная архитектура для масштабирования, оптимальное распределение задач между людьми или командами, система перестаёт упираться при росте в отдельные компоненты.

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

Также сложность перетекает между архитектурой и реализацией. К примеру в случае с микросервисами архитектура всего решения должна быть хорошей, а реализация конкретного сервиса может быть написана студентом за полставки. Будут проблемы - обвешают ретраями, рестартами, в конце концов перепишут. В случае с монолитом архитектуру менять проще, но проблемы в реализации могут стать фатальными (к примеру какой-нибудь модуль жрёт память и всё приложение грохается). Если у нас сервисы с общей базой - тут что-то посредине, вроде разные сервисы независимы, но вполне может быть ситуация, что они друг другу под ногами будут мешаться, к примеру нагружая базу и замедляя все остальные сервисы тем самым или блокируя таблицы и тд. Разбираться с этим, конечно, можно, но нет уже той независимости в командах. Если это большая организация, то все начнут друг на друга спихивать ответственность.

Почему я придрался - все апологеты микросервисов подчёркивают, что база должна быть разная. Иначе это уже не то, что они называют микросервисами и «продают». Соблюдать терминологию считаю правильным. А так - сервисная архитектура и 20 лет назад была известна.

Микросервисы в том числе нужны, чтобы решать организационные проблемы. Когда команда контролирует всё, уйти от ответственности уже так просто не получится. База тормозит - а почему она тормозит, её же никто кроме вас не использует, решайте проблему с тормозами.

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

Если кратко расписать, как я это вижу:

Монолит: легко начинать писать, до определённого размера оптимальный подход, легко масштабировать, не требуют выделенной инфраструктуры для логгирования и метрик, не требуют выделенной инфраструктуры для запуска (типа куба).

Сервисы с одной базой: легко вырастают из монолита (просто какой-то кусок выносим в отдельное приложение и заменяем вызовы функций на HTTP вызовы), HTTP даёт хорошую границу, которую пересечь не так просто, полезно для соблюдения разграничения. В целом удобней для работы нескольких людей.

Микросервисы с разными базами: оптимальная архитектура для масштабирования, оптимальное распределение задач между людьми или командами, система перестаёт упираться при росте в отдельные компоненты.

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

Также сложность перетекает между архитектурой и реализацией. К примеру в случае с микросервисами архитектура всего решения должна быть хорошей, а реализация конкретного сервиса может быть написана студентом за полставки. Будут проблемы - обвешают ретраями, рестартами, в конце концов перепишут. В случае с монолитом архитектуру менять проще, но проблемы в реализации могут стать фатальными (к примеру какой-нибудь модуль жрёт память и всё приложение грохается).

Почему я придрался - все апологеты микросервисов подчёркивают, что база должна быть разная. Иначе это уже не то, что они называют микросервисами и «продают». Соблюдать терминологию считаю правильным. А так - сервисная архитектура и 20 лет назад была известна.

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

Если кратко расписать, как я это вижу:

Монолит: легко начинать писать, до определённого размера оптимальный подход, легко масштабировать, не требуют выделенной инфраструктуры для логгирования и метрик, не требуют выделенной инфраструктуры для запуска (типа куба).

Сервисы с одной базой: легко вырастают из монолита (просто какой-то кусок выносим в отдельное приложение и заменяем вызовы функций на HTTP вызовы), HTTP даёт хорошую границу, которую пересечь не так просто, полезно для соблюдения разграничения. В целом удобней для работы нескольких людей.

Микросервисы с разными базами: оптимальная архитектура для масштабирования, оптимальное распределение задач между людьми или командами, система перестаёт упираться при росте в отдельные компоненты.

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

Также сложность перетекает между архитектурой и реализацией. К примеру в случае с микросервисами архитектура всего решения должна быть хорошей, а реализация конкретного сервиса может быть написана студентом за полставки. Будут проблемы - обвешают ретраями, рестартами, в конце концов перепишут. В случае с монолитом архитектуру менять проще, но проблемы в реализации могут стать фатальными (к примеру какой-нибудь модуль жрёт память и всё приложение грохается).