Recently, I had an interesting conversation on the microservices architecture with a good friend of mine, an enterprise architect. Microservices has grown popular over the last few years and has been hogging the IT boardroom discussions. My friend, the enterprise architect, lamented vociferously that the mindless marketing & sales pitch masks the reality of microservices and has created a mess.
ranted on and quipped that Stephen Leacock has aptly described us mortals in IT sales. I didn’t have a clue about Stephen Leacock, but I knew for sure that it wasn’t a compliment. I googled, and my intuition was right!
Stephen Leacock, a Canadian humourist & economist, in his book, “The Perfect Salesman” described advertising “ as the science of arresting the human intelligence long enough to get money from it.“ Definitely not a compliment but I have to grudgingly admit that he’s partly right. Many in our domain tend to brazenly and mindlessly “techwash” our sales pitch with all the possible tech words. Some of them include Microservices Architecture, AI, Blockchain, Quantum Computing, Dark Data, Digitalization, API-fication ( I am told that API-fication is officially accepted as a legit word), etc. Many of these are often judiciously strung together and touted as an armory of silver bullets to attain digital nirvana.
Well..he is both right and wrong ! This article is an attempt to provide a rebuttal clarify and hopefully redeem the credibility of a true salesperson.
So, back to the pertaining question. Is Microservices good or bad? The honest answer is, it can either be good or bad. It depends! That may sound like a tried and tested salesperson cop-out answer. It’s not. Let me explain.
To make it easier (for myself) and for the sake of brevity, I’m going to skip the definition of Microservices and stay away from the arguments whether it’s an architecture or design pattern or if it’s just a brand washed evolution of SOA
What are the fanboys saying?
The FAANGs are doing it!
FAANG envy is indeed a reality. FAANG and other modern enterprises (Twitter, Uber, et al) have not only pioneered adoption of cutting-edge technologies but also (thanks to their massive success) wield a powerful influence on the direction of technology domain. In any significant technology transformation pitch, it would be amiss not to have a slide that highlights how FAANG are succeeding at DevOps through microservices.
Flexible Deployment & Replaceability
Breaking down a monolith software into independent microservices allows the ability to package them into containers which in turn enables swift deployment. This also means that individual services can be updated or replaced with little or no impact.
Scalability
One of the primary advantages of microservices is scalability. More importantly, each service can be scaled independently and hence more efficient and cost-effective. For example, if you anticipate an increased viewing of Oscar-nominated movies, you can scale up relevant services to manage the increased load. Microservices provide the much-needed flexibility to scale up or down and align with the business.
Polyglot Programming
1996 - James Gosling invents Java, the first truly overly verbose object oriented programming language where design patterns rule supreme over pragmatism.Its super effective, the manager provider container provider service manager singleton manager provider pattern is born.
languages are principal tools to solve a problem and the sheer number of programming languages indicates the variety of tools at your disposal. Microservices lets you choose the right tool for the right job.
What are the hyper-observant saying?
Ignores talent premium
Microservices as technology promises a lot of benefits. However, a successful implementation requires significant expertise. Moreover, the required skill sets spans across multiple areas of technology and are very hard to find. Finally, most IT organizations may neither have the deep pockets nor the risk appetite to manage the associated overheads making microservices less ideal.
Adds complexity
Microservices indeed adds complexity, and you can ignore this at your peril. For example, an introduction of a single feature that has dependencies on multiple services, requires extensive collaboration between the teams, effective orchestration and deployment methodologies and so on.
Ignores operational premium
Martin Fowler “Being able to swiftly deploy small independent units is a great boon for development, but it puts additional strain on operations as half-a-dozen applications now turn into hundreds of little microservices. Again a level of maturity that is useful for monolithic applications becomes necessary if microservices are in the mix.”
The above quote from Martin Fowler says it all!
Drawing services boundaries is not easy
Microservices mandates that you break down the application into independent components with clearly defined boundaries. This is a known problem, and though practitioners have been advocating options (e.g., Domain Driven Design Concepts), it suffices to say that decomposition of services and definition of service boundaries is a tedious and hard exercise.
Inter-service communication can be slow and complex
Unlike monolithic applications where components are called through methods or functions, services in the microservices application are considered processes and they communicate through Inter Process Communication (IPC). Designing service interaction ( asynchronous messaging or synchronous request/response), service failure management, API definition and management requires careful analysis and is complex. Needless to add, IPC introduces latency problem
Microservices – Recent developments & Getting started
Both the proponents & detractors have valid points. The challenges with microservices implementation are certainly acknowledged by the practitioners, and several solutions/tools are being developed to address those problems. Google’s Istio, gRPC, and Netflix,s NEWT are some examples that highlight the developments in this space. If you are exploring microservices, I strongly suggest you check out the recommendation from Martin Fowler and Susan Fowler.
Martin Fowler recommends a more pragmatic modular-monolith-first pattern that lets you gain insights into your application and help you identify areas of code that can be wrapped up into microservices.
Susan Fowler, in her book, production-ready microservices, presents a sensible approach to building production-ready microservices and is based on her experience in implementing microservices at Uber. The book also provides a detailed checklist to evaluate your microservice across several areas including Stability & Reliability, Scalability, Fault Tolerance & Catastrophe Preparedness, Monitoring and Documenting & Understanding.
My Final Take - Deliberate hard and then proceed!
Before you take the plunge, it is critical to assess if your organization is ready for microservices and more importantly, if it’s relevant to your application. Some of the questions you may want to answer are
* Do we have the right skill sets/competence?
* Does this align with our organizational culture?
* Do we have the flexibility to re-organize ourselves ( small independent teams & devops)?
* Do we have a fair understanding of the complexities and operational overheads of adoption of microservices?
* Do the benefits outweigh the challenges?
* Is microservices relevant for my application?
The bottom line is that when it comes to architectural decisions, there are always tradeoffs. That said, the ultimate objective is to deliver value at the speed of business. Choose the option that best meets your business requirement.Remember, there are no silver bullets!
References :
1. Microservices sock shop Demo
2. Communication in a microservices architecture
3. Microservices Antipatterns
4. From Monolith to Microservices
5. A Brief Totally Accurate History Of Programming Languages. One Hundred Percent Inspired by Facts.
6. Designing microservices – Identifying microservices boundaries
7. Designing a system of microservices
8. Adopting Microservices at Netflix: Lessons for Architectural Design
Disclaimer : This post does not represent the thoughts,intentions, plans or strategies of my employer.It is solely my opinion. Feel free to challenge me, disagree with me and share your thoughts in the comments section.