Microservices Architecture — A Journey of Understanding
In the quest to always explore new things and expand my mind, I decided I would discover what the Microservices Architecture movement was all about. I started this new journey in a very old-school way — I bought a book. Specifically I picked up The Tao of Microservices by Richard Rodger.
Honest Moment: It took a lot to move past the author’s continual pot shots at developers who fail to adhere to his one true way — the first third of the book is replete with cynicism and down right anger and hatred towards all things non-microservices. While I agree with the fundamental message that he is carrying, I simply do not agree with the persistent negativity.
That being said, and the fact that I am only 62% through the book (thank you Kindle for that nice percentage!), the author so far has done a great job of explaining what microservices are, the mindset necessary to approach them, their benefits, and more.
So, what is a Microservices Architecture?
Fundamentally, based on my understanding thus far, it is an architecture where things are small islands of functionality accessible only by well defined messages. That is the nutshell, at least.
These islands are deployed independently, and they sit atop an underlying messaging infrastructure/platform that abstracts away the complexities of load balancing, service location, etc. This provides you the ability to code simply in your services, and to obtain operational goodies including highly distributed, vertical and horizontal scalablity, etc. These are traits that the underlying infrastructure provides (though you must be aware of them in your service coding).
But I have been OO for so long — Object Thinking?
I happened to have read Object Thinking by David West immediately before beginning the Microservices book — I, therefore, have an interesting set of juxtapositions running through my head. Object Thinking is not necessarily Object Oriented Programming as the masses will know it — it is a strict interpretation of how Object Programming should have been done all along.
A Functionality-First Focus
In Object Thinking, we are asked to become “Domain Anthropologists” exploring the rich world of our problem domain to understand the functionality we will later implement. It truly is the job of an anthropologist because you have to go in with no preconceptions, and you have to engage actively to understand unstated requirements (the art of active listening!). Requirements go unstated not because stakeholders are malicious; requirements go unstated because they are so fundamental and obvious in the domain.
According to West, from this domain-first perspective we then map the functionality into objects for implementation. Functionality typically takes the form of methods.
This is not unlike what I am understanding from Richard about Microservices — here he commands that we make messages the starting point of the design. What messages must you have in order to completely required functionality.
According to Richard, from this message-first perspective, we then map the functionality into services for implementation. Functionality typically takes the form of messages.
In both areas of study, we are called to consider the functionality required and then asked to map that into our implementation hierarchy. In Object Thinking that is mapped into objects, and Microservices it is into services.
Great Interfaces Make Great Objects and Microservices
In Object Thinking, David tells us that we are to keep objects short and to honor and obey the encapsulation barrier. This is one of the biggest things I adhere to as a software developer no matter where I am writing code — the encapsulation barrier is the most important thing to protect and a good interface with which to interact is an absolute must.
Richard tells us that Microservices gives you the encapsulation barrier for free because you can only communicate between services through a message. Microservices place the highest importance on the definition of the messages. In fact, Richard goes as far as to tell us that the downside of the monolith is that it is too easy to cheat and break barriers, and that you never have enough architects on a project to keep it from happening. I agree.
Deployment
In a monolith, you are typically building the kitchen sink and all of your functionality into one artifact. You then deploy that. There is a lot you can do to have zero downtime and good-clean rollback if something goes wrong, but the fact is that you are rolling out a complete update of the entire code base with your monolithic deployment — your code, someone else’s code, all rolled into one big bundle of joy. If any part of it needs to be rolled back, you are typically looking at rolling the whole thing back.
In the Microservices world you deploy each service by itself. You can deploy a new version of a given service and load balance only a portion of the load onto it as you monitor it for any bad behavior. Over time, your confidence will allow you to turn up more instances of the new version and ultimately turn down all of the old versions. While you are busy orchestrating that, someone else is orchestrating deployments of new code they wrote for services for which they hold responsibility.
Testing
Testing a monolith can be a pain. Depending on your language and platform, you are going to find yourself needing to figure out how to mock and test your code. It is perfectly doable, but in every project I have ever seen there have always been a lot of trade-offs made. More times than I wish to ever admit, the code coupling is so great that the unit tests I observe are really integration tests across broad swaths of code.
In the Microservices world, messages provide the bulk of input and output from the majority of the code. Code for which this is not true is code that talks directly to a data store or provides a client API. Those edges are relatively trivial to mock when they occur, and messages provides you the simplest mockable interface — you can send any message you want and you can validate any message you want. This is the first time I have seen an architecture for which testing looks simple.
More…
I will definitely have more to say as I move towards finishing Richard’s book, and I will certainly drop those thoughts here. I am looking forward to experiencing the code section of the book and then putting my fingers to some implementations of my own. From the book and from some online searching, it does appear that the marketplace is shallow on fully functional implementations and it looks like a bunch of home grown code is going to be called for; another thing I will report on as I move forward.
I have continued my exploration in Microservices Architecture: Early Thoughts Before That First Step.
If you have knowledge, pointers, thoughts, questions, musings about Microservices, throw me a response!
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
