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
Zero-downtime independent deployability.
- usecase: SaaS business where you can’t afford downtime.
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”.
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.
- Create a deployment mechanism
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.
- 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.
(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.
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.