Developing Micro-Services is all the rage now, and there is certainly a lot of hype around the key concept. Possibly many teams are engaged in the process of splitting their monolithic applications down and re-implementing them as Microservices. The trouble is there are so many conflicting idea, philosophies, ideologies and misunderstandings of what the hell Microservices even are!
When we at Denizon, started implementing our Energy Monitoring and Management service stack in 2009, we probably stumbled across this approach more by trial and error and learning by failing to implement a Service Oriented Architecture approach. Over the years we have continued to evolve, refine and perfect our approach and with the benefit of 20/20 hindsight we can see that actually we have implemented what would typically be called a Microservices architecture.
We took what we learned from that project and re-implemented it into our Workforce Management system, although we learned even more lessons about Kubernetes, Docker and the whole Cloud Native approach which also seems to have become synonymous with Microservices!
Why I read this book?
Over the past year, this book has been recommended to me on 3 separate occasions by different people. All 3 in different roles across the enterprise software space, each provided different viewpoints derived from the same book. I thought it was time I took the plunge and read it for myself, purely to explore what opinions I could derive.
Although, one of my goals for 2021 was to try read more books outside of the technical sphere I generally gravitate towards. I thought I'd make an exception, I also find myself on another Micro-services based project and like all micro-services projects there are always different ideas on how, when, what and why certain aspects need to be implemented. I thought it wouldn't be all that bad of an idea to learn more.
I was also look for a less technical, technical book and more of a high level philosophical approach. Which as I remember, how one of my referrals described this book. The book very few code samples and tutorials on how to do things and is much more about the why & when of implementations.
What I learned from this book
The narcissist in me would probably like to assert, this book more or less reaffirmed what I had learnt from my previous dalliances with microservices. However, the real truth is that implementing microservices correctly is actually a lot more hard work than one would really suspect and you only learn about implementing Microservices correctly by making mistakes, or as other like to euphemistically like to call experience. The other hard fact is that , with getting microservices wrong can take a lot longer than you would expect.
When developing microservices, you almost have to work against your intuition as programmer, because what you intuitively think would be a great solution will in turn out in practice to be a bad one. Newman addresses this concept really well in DRY and the perils of Code Resuse in a Microservices World. Intuitively as developers we're conditioned to think that re-writing the same code is bad and our intuition leads us to writing Shared Libraries, but in Microservices this can lead to wider problems,
One also has to appreciate just how much complexity there is in something that is commonly referred to as a Micro-Service. At first, you may assume functionality wise it may be simple, but when you get down to it there is a whole lot more complexity to appreciate. Often this complexity lies in the simple things!
I found it ironic that, I only made it to page 57 of the book before Sam Newnam describes the exact same sceanrio we stumbled across at Denizon, in a paragraph he titled Complexities of Asynchronous Architectures.
The associated complexity with event-driven architectures and asynchronous programming in general leads me to believe that you should be cautious in how eagerly you start adopting these ideas.Sam Newman - Building Microservices
I would have to say, that based on my experience, the author is bang on with this assertion. He is also 100% correct with the second part of the paragraph
Ensure you have good monitoring in place, and strongly consider the use of correlation ID's which allow you to trace requests across process boundariesSam Newman - Building Microservices
These two pieces of advice are worth the other 250 pages of insightful content alone!
I can assure you, that the minute you introduce a Queue System and Asynchronous events, you are opening yourself up to whole new world of things you were never going to expect!
The author discusses different inter-microservices integration communication styles i.e. synchronous versus asynchronous and the different approaches to managing business processes providing a discussion on orchestration versus choreography. He also provides detail on technology protocols (RPC, SOAP, REST) explaining the advantages and disadvantages. He emphasises preference for asynchronous-choreographic using REST style, but he also caveats it with that there is no ideal solution.
In my opinion, another chapter to pay particular attention too, especially if you're working in the enterprise software space, is Chapter 5 Splitting The Monolith, but be warned there are a lot more dragons to be found!
In chapter 5 the author presents some ideas about how to split a monolithic application into microservices. The first proposed step is to find portions of the code that can be treated in isolation and worked on without impacting the rest of the codebase (this portions of code are called seams, this word have been coined by Michael Feather in Working Effectively with Legacy Code. The seams are the perfect candidates for the service boundaries.
Why I recommend this book
In some ways, I feel that I am going to echo all 3 of the referrals I was given on this book. The first being that it was light enough to read, yet packed with lots of great technical insight and digestible knowledge. The second is that, although this is a technical book, you don't need to be a developer or programmer to understand it, there are 1 or 2 code samples in the book, but they are really short not complicated and only really serve as illustration purposes, there was no need to understand them in detail.
There are some great illustrations to explain some technical concepts, that could be easily understood by anyone in a business setting. The key strength of Building Microservices is that it is language-agnostic and does not necessarily steer you down any specific technology path.
Thirdly, I think this book can easily be read by anyone working within IT and related industries, irrespective of role. It provides a great primer on what to expect and potential pit falls to be wary of when embarking on a microservice implementation journey in your organisation.
I always determine the quality of a book, by the amount of highlighted sentences, paragraphs and phrases I make. This book certainly has a fair number of those!
Designing Fine-Grained Systems