Monolithic or Microservices: Decoding the Puzzle
The debate centered around the supremacy of Monolithic or Microservices architecture in software engineering has sparked a confusion regarding the one to use.
To clear the mist, look at what top business leaders say about the software architectures.
Khalid Rashid, the CTO of Talabaat, shares on the social media
I have been talking to many startups lately, and one common pattern I have observed is over-engineering, which adds complexity without providing any measurable benefits.
A prime example of this is replacing Monolithic systems with Microservices. Trust me, they won’t give you the benefits you think they will, and they will only make your life more complex and slow you down in the long run.
If the argument is that you need Microservices for scalability, think again. I have seen Monolithic systems handle millions of requests per second.
If your Monolithic system is a ‘big ball of mud’, with a team that can’t create a clean and modular Monolithic, they have little chance of creating a clean and effective distributed system with Microservices.
If your goal is for teams to be able to deploy independently, your Monolithic system should be able to continuously deploy to production which eliminates the need.
Obviously, there is a place for building distributed systems, but most startups have very different problems that they should be focusing on. Stick to simpler solutions and build the muscle of continuous refactoring and improvements.
David Heinemeier Hansson, the CTO of 37 Signals, shares on the social media
I won't deny there may well be cases where a Microservices-first architecture makes sense, but I think they're few and far in between. The vast majority of systems are much better served by starting and staying with a majestic monolith. The Prime Video case study that blew up the internet yesterday is but the latest illustration.
Maybe once you reach the scale of Netflix or Amazon, there are areas where it starts to make sense, but remember that even the likes of GitHub and Shopify run their main applications as monoliths with millions of lines of code and have thousands of programmers collaborating on them.
But that's advice for folks starting new systems today. What do you do if you already, and prematurely, went with a microservices architecture? How do you recover? Here are a few tips:
#1. Stop Digging
You can't clean up a mess before you stop making more of it. That means not introducing new microservices.
#2. Consolidate Critical, Dependent Paths First
The worst form of microservice madness is when you splinter a single, coherent flow across multiple systems.
#3. Leave Isolated Performance Hotspots for Last
When microservices are done right, they often target a narrow, isolated, and usually performance-critical segment of the system, which can benefit from a rewrite in a clunkier but faster programming language.
#4. Prioritize Dropping the Most Esoteric Implementations
One of the terrible side effects of microservice madness is the tendency to embrace a million different programming languages, frameworks, and ecosystems. The vast majority of systems should have no more than two backend languages in play at any one time.
#5. Learn to Partition Large Systems With Modules Rather than Networks
So much of the motivation for microservices has been driven by the fallacy that if you can't figure out how to properly architect a large system using programming tools like modules and namespaces, then you can solve this problem by partitioning it with network boundaries.
Heed the timeless advice of John Gall: "A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work."
Yes, microservices, like any pattern of programming, are a tool. Yes, "it depends" is technically correct. But we offer no guidance to those looking to design better systems by simply saying that; we need to be willing to say WHAT IT DEPENDS ON. Just saying "it depends" helps nobody, anywhere make better decisions.
Conclusion
Focus should be on solving business problems by sticking to simpler solutions and build the muscle of continuous refactoring and improvements and practice Clean Coding principles.