Еще я бы добавил, что выбор подхода сильно зависит от специфики. Например, есть сайт для пользователей (невысокие нагрузки), поисковый движок, обмен данными с десятком партнеров по разным API (высокие нагрузки), требующий промежуточные базы и еще всякие вспомогательные штуки типа хранилищ статики. Все это в теории можно упаковать в монолит, но это вовсе не будет удобно. Если одна часть системы имеет нагрузку x10 по сравнению с другой, проще выносить такие куски в отдельные сервисы и масштабировать, нежели заниматься оптимизацией монолита. Также такой подход позволяет гибче подходить к вопросу рефакторинга (почти всегда продукт находится в состоянии легаси и его надо как то расширять). Можно не переписывать древнее легаси с нуля целиком, а потихоньку писать новые сервисы и настраивать коммуникацию. Если разделять монолит не на 200 микросервисов, а на 5-10 ключевых сервиса, поддерживать может быть не так уж и больно.
Сильно круто описали) Спасибо! В моей статье не хватает такой глубины. Это мы уже более подробно шатаем более конкретные кейсы из практики реализации реальных крупных проектов)
Только это не микросервисная архитектура, а просто изоляция части приложения в отдельном источнике данных. Архитектура - это свойство всего объекта, а не его части.
Еще я бы добавил, что выбор подхода сильно зависит от специфики. Например, есть сайт для пользователей (невысокие нагрузки), поисковый движок, обмен данными с десятком партнеров по разным API (высокие нагрузки), требующий промежуточные базы и еще всякие вспомогательные штуки типа хранилищ статики. Все это в теории можно упаковать в монолит, но это вовсе не будет удобно. Если одна часть системы имеет нагрузку x10 по сравнению с другой, проще выносить такие куски в отдельные сервисы и масштабировать, нежели заниматься оптимизацией монолита. Также такой подход позволяет гибче подходить к вопросу рефакторинга (почти всегда продукт находится в состоянии легаси и его надо как то расширять). Можно не переписывать древнее легаси с нуля целиком, а потихоньку писать новые сервисы и настраивать коммуникацию. Если разделять монолит не на 200 микросервисов, а на 5-10 ключевых сервиса, поддерживать может быть не так уж и больно.
Сильно круто описали) Спасибо! В моей статье не хватает такой глубины. Это мы уже более подробно шатаем более конкретные кейсы из практики реализации реальных крупных проектов)
Только это не микросервисная архитектура, а просто изоляция части приложения в отдельном источнике данных. Архитектура - это свойство всего объекта, а не его части.