Why I Wrote This Book
At one level, I wrote this book because I wanted to make sure that the information in the first edition remained up to date, accurate, and useful. I wrote the first edition because there were really interesting ideas that I wanted to share. I was fortunate that I was in a place where I had the time and support to write the first edition, and that I could do so from a fairly unbiased viewpoint because I didnt work for a big technology vendor. I wasnt selling a solution, and I hoped I wasnt selling microservices eitherI just found the ideas fascinating, and I loved unpacking the concept of microservices and finding ways of sharing it more broadly.
When I really break it down, I wrote a second edition for two main reasons. Firstly, I felt I could do a better job this time. Ive learned more, and I am hopefully a bit better as a writer. But I also wrote this second edition because I played a small part in helping these ideas hit the mainstream, and as such I have a duty of care to make sure they are presented in a sensible, balanced way. Microservices have become, for many, the default architectural choice. This is something that I think is hard to justify, and I wanted a chance to share why.
This book isnt pro microservices, nor is it anti microservices. I just want to make sure that Ive properly explored the context in which these ideas work well and shared the problems they can cause.
Whats Changed Since the First Edition?
I wrote the first edition of Building Microservices in around a year, starting at the beginning of 2014, with the book being released in February 2015. This was early in the microservices story, at least in terms of the wider industrys awareness of the term. Since then, microservices have gone mainstream in a way that I couldnt have predicted. With that growth has come a much wider set of experiences to draw on, and more technology to explore.
As I worked with more teams in the wake of the first edition, I started to refine my thinking around some of the ideas associated with microservices. In some cases, this meant that ideas that were only at the periphery of my thinking, like information hiding, started to become more clear as foundational concepts that needed to be better highlighted. In other areas, new technology presented both new solutions and new problems for our systems. Seeing so many people flock to Kubernetes in the hope that it would solve all their issues with microservice architectures certainly gave me pause for thought.
Additionally, Id written the first edition of Building Microservices to provide not just an explanation of microservices, but also a broad overview of how this architectural approach changes aspects of software development. So as I looked more deeply at aspects around security and resiliency, I found myself wanting to go back and expand on those topics that are increasingly important to modern software development.
Thus in this second edition, I spend more time sharing explicit examples to better explain the ideas. Every chapter has been reexamined, and every sentence reviewed. Not a lot of the first edition remains in terms of concrete prose, but the ideas are all still here. Ive tried to be clearer in my own opinions, while still recognizing that there are often multiple ways of solving a problem. This has meant expanding the discussion of inter-process communication, which is now split across three chapters. I also spend more time looking at the implications of technologies such as containers, Kubernetes, and serverless; as a result, there are now separate build and deployment chapters.
My hope had been to create a book around the same size as the first edition, while finding a way to pack in more ideas. As you can see, Ive failed to achieve my goalthis edition is bigger! But I think Ive succeeded in being clearer in how I articulate the ideas.