4 ms·
> Purpose 1: Minimize Costs of Change The cost of change is radically increased using micro services. With microservices you scatter the business complexity a
by tossandthrow 9mo ago
> Purpose 1: Minimize Costs of Change
The cost of change is radically increased using micro services.
With microservices you scatter the business complexity across multiple services and lift a considerable amount of complexity from the easily testable code base and into the infrastructure.
IMHO doing a micro service architecture for this reason is horrible.
- simianwords 9mo agoYou are right but from a different context. In a well thought out microservice architecture, you will not have business logic scattered across multiple services. We have had instances of microservice architecture where doing one change required changes in 4 different microservices defeating the whole point. Obviously this is bad.
- vjvjvjvjghv 9mo ago“ In a well thought out microservice architecture, you will not have business logic scattered across multiple services.” A “well thought out” architecture that holds up over years is a pipe dream. There will always be changes that require a rethinking of the whole system.
- tossandthrow 9mo agoAs the sibling say, the changes of the future are not predictable. The perimeter for business logic or bundled changes change. Having a monolith much nicer allows to make these types of changes.
- simianwords 9mo agoYes that's the tradeoff. Over time your architecture degrades and you need to rethink the services. But good part is that migration is simpler and less risky when you are just making changes to few microservices.
- tossandthrow 9mo agoI am curious, how is this the case? Is that because a failure of a service would only affect a single flow?