Published on

Monoliths vs Microservcies

Authors

Is a microservice architecture a good choice for a given system?

It Depends

Kent Beck says, "any decent answer to an interesting question begins, 'it depends...'".

It Depends on Complexity

Martin Fowler writes, "my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith." Once a system reaches a certain base complexity, microservices improves productivity.

It Depends on Organizational Complexity

David Heinemeier Hansson argues its about team size saying microservices are, "an organizational pattern for dealing with intra-company communication at crazy scale when API calls beat scheduling coordination meetings."

There is a Happy Medium

Kelly Goetsch says, "It's not monolith vs. microservices. I think that's a false dichotomy. We can all agree that a giant monolith isn't very good, nor are thousands of little microservices. As with most of life, the truth lives somewhere in the pragmatic middle"

Microservice Pros and Cons

PROS

  1. Reduces data coupling (domain data models can evolve more easily)
  2. Reduces deployment coupling (teams can evolve part of the system without releasing everything)
  3. Reduces code coupling (e.g., teams can replace a Java implementation with a Node implementation without rearchitecting everything)
  4. Can improve vertical scaling (scale parts of the system independently)

CONS

  1. Adds deployment complexity (more things need QA, CI/CD, etc)
  2. Adds operational complexity (more things to monitor and maintain)
  3. Increases network calls which adds latency and complexity (i.e., monolith method calls become microservice network invocations)

My Take for E-commerce

E-commerce has high complexity - it's one of the reasons why Shopify, commercetools and related vendors exist. For the code we write for customers, the right thing is a service boundary for each major domain. At minimum, a BFF service makes sense to abstract the commerce engine from the front end to get the pros listed above. All other domains could be wrapped into a single service (e.g., monolith) depending on the complexity of the remaining requirements.