Book Review: Monolith to Microservices (Part 1)

Posted on by


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.


Share on:

Author: A N M Bazlur Rahman

Java enthusiastic | Book author | Mentor | Helping Java Developers to improve their coding & collaboration skills so that they can meet great people & collaborate

100daysofcode 100daysofjava access advance-java agile algorithm arraylist article bangla-book becoming-expert biginteger book calculator checked checked-exceptions cloning code-readability code-review coding coding-convention collection-framework compact-strings completablefuture concatenation concurrency concurrentmodificationexception concurrentskiplistmap counting countingcollections critical-section daemon-thread data-race data-structure datetime day002 deliberate-practice deserialization design-pattern developers duration execute-around executors export fibonacci file file-copy fork/join-common-pool functional future-java-developers groupby hash-function hashmap history history-of-java how-java-performs-better how-java-works http-client image import inspiration io itext-pdf java java-10 java-11 java-17 java-8 java-9 java-developers java-performance java-programming java-thread java-thread-programming java11 java16 java8 lambda-expression learning learning-and-development linkedlist list local-type-inference localdatetime map methodology microservices nio non-blockingio null-pointer-exception object-cloning optional packaging parallel pass-by-reference pass-by-value pdf performance prime-number programming project-loom race-condition readable-code record refactoring review scheduler scrum serialization serversocket simple-calculator socket software-development softwarearchitecture softwareengineering sorting source-code stack string string-pool stringbuilder swing thread threads tutorial unchecked vector virtual-thread volatile why-java zoneid