monolith → microservices

February 12, 2021

A couple of takeaways and learning points from Oreilly’s Monolith to Micro services by Sam Newman

When to use Microservices?

  • Problem: We focus on the tech tool, not the thing that tech tool let’s you do.
  • What can it give you ?

    • More options to scale up applications
    • Independent deployability
    • Limit the “blast radius” of failure

“Microservice architectures buy you options” - James Lewis

Takeaway: Our industry tends to focus on tech instead of the outcome. One should you micro services as a means to obtain a desired outcome rather than for the sake of using a new technology.

Don’t use microservices as a default option

  • They are not an on/off switch.
  • Distributed systems are hard to do.
  • A single process monolithic architechure is not distributed… but actually it is. If you are reading data from a database on a seperate computer, that’s a distributed system, but a really simple one.
  • One should firstly try to dial up or make small changes towards distributed system arch, in order to see the benefits and if it is really a thing which is needed or not.

Takeaway: Microservices should not be the default option. If you think a service architecture could help, try it with one of the modules from a very simple monolith typology and let it evolve from there.

Top 3 reasons to introduce microservices

  1. Zero-downtime independent deployability.

    • usecase: SaaS business where you can’t afford downtime.
  2. Isolation of processing around data. You isolate the data and processes which act on that data.

    • usecase: Healthcare industries, GDPR.
    • How to know where my customer data is.
    • How implement the “right to be forgotten”.
  3. Enable a higher degree of organizational autonomy

    • Distribute responsibilities into teams to reduce the amount of coordination with the rest of the organization.
    • Reduce the amount of coordination those teams need with other parts of organization.

How to avoid a distributed monolith ?

Example: In order to deploy X services, which is dependant on service Y, which is dependant on another service and goes on … This becomes a monolithic behaviour although being distributed from each other.

If you have a theory on deploying microservices for your designed architecture, do not make it a theoretical thing, make it an actual thing.

  1. Create a deployment mechanism
  2. Look for patterns

    • Example: A collection of microservices often being changed together
    • A Ticket tracking tool like Jira, to tie a commit to a piece of work. Look back at the stories you have completed and the commits. Map the commits to the services those have impacted. Decide if
    • You want to merge those services back together again.
    • You want to look at different ways to slice and dice them.
  3. The idea of information hiding. With a smaller interface to the rest of the world, it’s easier to make sure that any changes you make inside the boundary won’t affect the interface. Challenge: Not knowing the concept of information hiding. Encapsulation is an implementation.

Why strive for independent deployment ?

  • It’s easier to limit the impact of each release with microservices.
  • With a microservice architectute, if I am just deploying a single service, I can reduce the scope of that deployment and do it more effectively and efficiently.
  • Incase of zero-downtime deployment, the impact of the release should be reduced.
  • For a monolithic architecture, if an organization has to do for example a database migration, they have to do it on days when the network is quite and less traffic is ingressed due to the big impact on the release. While on a microservices architecture, isolation enables the migration to take place anytime with a faster pace and therefore less impact on the whole system.

Takeaway: As the team size increases it gets exponentially harder to coordinate a deployment.

Organizations and Teams
  • Modules within a monolith system should work better than they do. We find ways to violate those modules.
  • When you make that service a process boundary, violating those things become really painful.
Handling Data

(Observations to data for a better monolith with a microservice style)

  • A lot of the complexity of breaking complex systems lies in the data.
  • After extracting the microservice you need to understand what part of the old database this system uses.
  • Read more about this in the book.
Handling people

The one thing that is more complicated than data, when it comes to software development, is people.

  • People aren’t used to managing distributed systems to the degree that microservices requires it and thinking about the independence.

    “No matter what they tell you, it’s always a people problem”

  • There has to be a willingness to change as an organization if you want to make the most out of using microservices.


  • Microservices architectures will very rarely save you money. They can make you more money, but they are costly.
  • It doesn’t have to be overnight.
  • Organizations instead of experimenting on introducing microservices to their system should first experiment on their teams in order to grow and for the betterment of the employees.
  • If you spend all your time and efforts to deploy a microservice architecture and do not focus on changing the old fashioned, top-down approach, command and control way to do stuff in the organization, you are going to end up with probably the worst of both worlds.

Takeaway: There has to be a willingness to change as an organization if you want to make the most out of using microservices.

Profile picture

Written by Idrees Dargahwala who is a Software Engineer building useful things on the web. You should follow him on Twitter