emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

В продолжение статьи "Роль архитектуры в масштабировании команд, DDD и микросервисах"
- https://dckms.github.io/system-architecture/emacsway/it/team-topologies/harlan-mills%27-proposal.html

Превосходство Monolith First заключается в том, что он удешевляет изменение концептуальных контуров, что, зачастую, неизбежно в процессе Crunching Knowledge. На начальной стадии развития проекта обычно не возникает тех предпосылок, в которых может проявить свои превосходства микросервисная архитектура, что делает Monolith First экономически целесообразным.

Но означает ли это то, что Microservices First всегда экономически нецелесообразен? Нет, не означает. И, чтобы понять, когда наступает его экономическая целесообразность, нам нужно обратиться к известной работе Frederick P. Brooks, Jr. "The Mythical Man-Month Essays on Software Engineering Anniversary Edition".

С одной стороны, Monolith First получается дешевле, так как удешевляет эволюционирование Доменной Модели и изменение концептуальных контуров.

С другой стороны, Microservices First (не прямо, а косвенно, посредством концепции Bounded Contexts) позволяет достигнуть такого уровня автономности команд, который позволяет задействовать сразу большое количество разработчиков. Получается дорого, но быстро.

Каждое решение - это баланс выгод и затрат. Быстрота тоже выражается деньгами. Если оверхед от микросервисов перекрывается выгодой от более раннего выхода на рынок - TTM (time-to-market), то Microservices First может оказаться экономически целесообразней.

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

На другой чаше весов у нас ущерб упущенной выгоды от более позднего выхода продукта на рынок.

Решение является балансом. Для этого рассматривается график экономии от Monolith First и график ущерба упущенной выгоды от роста TTM.

Там где эти графики пересекаются - возникает точка баланса. Вопрос лежит исключительно в бизнес-плоскости.

Если ущерб упущенной выгоды перевешивает, то применяется Microservices First, иначе - Monolith First.

Зачастую, Monolith First оказывается выгоднее. Но экономическая целесообразность Monolith First может оказаться ниже ущерба упущенной выгоды от роста TTM, и тогда баланс решения качнется в сторону Microservices First. Этот баланс зависит от условий каждого конкретного проекта в отдельности. Серебрянной пули нет.


#DDD #Microservices #SoftwareArchitecture

👍2

www.tgoop.com/emacsway_log/343

2.33K viewsedited  Jan 19, 2021 at 19:53

В продолжение статьи "Роль архитектуры в масштабировании команд, DDD и микросервисах"
- https://dckms.github.io/system-architecture/emacsway/it/team-topologies/harlan-mills%27-proposal.html

Превосходство Monolith First заключается в том, что он удешевляет изменение концептуальных контуров, что, зачастую, неизбежно в процессе Crunching Knowledge. На начальной стадии развития проекта обычно не возникает тех предпосылок, в которых может проявить свои превосходства микросервисная архитектура, что делает Monolith First экономически целесообразным.

Но означает ли это то, что Microservices First всегда экономически нецелесообразен? Нет, не означает. И, чтобы понять, когда наступает его экономическая целесообразность, нам нужно обратиться к известной работе Frederick P. Brooks, Jr. "The Mythical Man-Month Essays on Software Engineering Anniversary Edition".

С одной стороны, Monolith First получается дешевле, так как удешевляет эволюционирование Доменной Модели и изменение концептуальных контуров.

С другой стороны, Microservices First (не прямо, а косвенно, посредством концепции Bounded Contexts) позволяет достигнуть такого уровня автономности команд, который позволяет задействовать сразу большое количество разработчиков. Получается дорого, но быстро.

Каждое решение - это баланс выгод и затрат. Быстрота тоже выражается деньгами. Если оверхед от микросервисов перекрывается выгодой от более раннего выхода на рынок - TTM (time-to-market), то Microservices First может оказаться экономически целесообразней.

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

На другой чаше весов у нас ущерб упущенной выгоды от более позднего выхода продукта на рынок.

Решение является балансом. Для этого рассматривается график экономии от Monolith First и график ущерба упущенной выгоды от роста TTM.

Там где эти графики пересекаются - возникает точка баланса. Вопрос лежит исключительно в бизнес-плоскости.

Если ущерб упущенной выгоды перевешивает, то применяется Microservices First, иначе - Monolith First.

Зачастую, Monolith First оказывается выгоднее. Но экономическая целесообразность Monolith First может оказаться ниже ущерба упущенной выгоды от роста TTM, и тогда баланс решения качнется в сторону Microservices First. Этот баланс зависит от условий каждого конкретного проекта в отдельности. Серебрянной пули нет.


#DDD #Microservices #SoftwareArchitecture

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.