I have just finished reading “Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith” by Sam Newman.

This book is undoubtedly great; it explained a few critical aspects while moving away from a monolith to a Microservices architecture. In this article, I will try to summarize some of the elements from the book that impacted me.

This book contains five chapters, and each of them has a great deal of context and explanation. So I will go one by one.

Chapter # 1

This chapter starts with defining the concept, Microservices itself, the benefit and the problem it creates. So from the definition, Microservices will have the following key components-

1. A service that can be deployed independently. The idea is, a service has to have the ability to deploy in production without disrupting any other associated services. Therefore, any changes in a particular service shouldn’t affect any other service, which is essential for having Microservices.
2. A service has to be modelled around a business domain. The idea is, if you need to touch two or more services to deliver a feature, then that’s not an ideal scenario for Microservices. So we have to find a way so that his cross-service changes are less frequent.
3. Each service has to own its data. Again, we can compare this with the object-oriented design principle; the way a class encapsulates its fields, a service must encapsulate the data.

Now the question is, what are the benefits it brings to the table? Well many. It puts many options on the table; you can mix and match different technology. It offers us to choose mixing different programming languages, programming styles, deployment platforms or databases to find the right mix. Multiple services can be developed independently without getting each other ways. The developers can focus on their particular thing. Above all, it gives us flexibility. It opens up many more options regarding how we can solve a specific problem in future. Finally, it reduces the blast radius. If a particular service goes out of service, ideally, it shouldn’t impact any other services.

However, Microservice architecture does not give you a silver bullet; it also brings a lot of baggage. Communication between services becomes a bottleneck. We now have to worry about latencies, and they vary, and thus the system becomes unpredictable. The transactional behaviour that we cherish so much will go away out of the window. Network calls can and become a headache, for example, Service A is talking to Service B, but Service B might go offline. Since data are not in one place, getting a consistent view of data across multiple machines becomes difficult. In fact, microservice can be a terrible idea, except for all the good stuff it provides.

Putting all these pros and cons upfront, the book argues whether we really need to go forward with Microservices. Perhaps not, in many cases. There are still many benefits of having a monolith. For example, it has a much simpler deployment topology, much simpler developer workflow. Activities like monitoring, troubleshooting, end-to-end testing are relatively easy in the monolith. Besides, if you want to reuse code, it’s just there, and a method calls away.

Still, suppose you want to go for it. In that case, you must have a perfect reason for that: independent deployability, independent scalability, mix and max technology, reducing the blast radius, etc. Of course, it won’t be cheap, somewhat costly, but with Microservices, you can buy more options. Well, you certainly need to know that there is a cost associated with the term buying.

That’s for today; I will discuss the next chapter in the forthcoming article.