In this article, I will give my opinion about the monolith vs microservices debate and it will get spicy, There will be disagreement all I ask at the end of the article that you can decouple your ego from what is best for your team.
I have worked with various teams, companies, and industries, and I have met some crazy characters and some brilliant professionals who I look up to till this day. Often I found the debate within these teams where there is a developer who is against anything new that is not their monolith application from 10 years ago vs a developer who is waiving hands above head to get the team to move to microservices.
Right out of the gates, no architecture can fix your organization's bad planning, poor communication or toxic leadership.
So Your Team Is Considering Microservices?
Microservices won't fix your culture, or your bad coding habits, or overnight solve your scaling problems, just worsen them. Get clear on your organization's communication structure and your product value to the customer. Clearly define your domain and the bounded contexts.
Your team, the executive, and the stakeholders all have to be on the same page. Failure to do so will lead to misalignment, constant change in priorities and your team will neither get the budget nor time. If there is a team member not on board they will become a hazard to your project and will lead to sabotage or poor performance on the project. Should the business not care about anything technical and just wants new features, i.e. the company is a feature factory then you are in for a crazy time like changing the engine and tires while the vehicle is traveling at high speeds.
All is not lost and there are patterns and practices to deal with these challenges.
Finally, whether you are new dev or an old-grey beard dev getting comfortable with failure and learning to fail fast. The team can't afford to code for months and only have one release day or week every other month. The cost of finding out the value you thought you are delivering is not aligned with what the customer wanted might sink your company. Close the feedback loop with your customer and get that feedback to your dev and product team asap.
The Spice Must Flow
If you explain your system like this and want to go the microservices route:
You are in for a rough time friend. My recommendation is either to start anew, but it's expensive and will take time. Or go clean up your data, get crystal clear on your domain, bounded contexts, and value offer then come back to relook microservices.
Before you grab your favourite Reddit keyboard and come after me let's put ego aside and cut the BS:
Code split into separate projects while everything still points to the same DB is not microservices, it's a distributed monolith.
"I have rolled my own pub-sub using a shared DB". Don't do this, please use a message or event bus that is decoupled from your services.
Naming your services after Marvel or DC characters is not showing off your intellectual capacity but rather your lack thereof and it's annoying AF. Be clear and concise with your naming on why this service exists and what it does.
Don't be the guy: "but Netflix and Spotify do...". No, chances are your company is nowhere near this scale and will not have the dev capacity to build & maintain 500 services in a given quarter.
If you are starting in a new unknown domain where there is lots of experimentation and high code churn then a small monolith might be a better call as you can move faster however aim to refactor it into MS architecture once the domain has revealed itself and you are looking to scale your code, dev team, and product at scale. Note: Getting it wrong would result in years of balancing refactoring and product deliverables while struggling to scale your team and platform.
Important to check again will a microservices based architecture enable your team to work faster and deliver quality features. Don't pick the architecture then try to solve the problem.
No microservices or any cloud service will not solve your scaling and performance issues when your code is unoptimized and the whole system is a big ball of yarn.
Dear stakeholders, going from monolith to microservices is a process that does not happen overnight and comes with a refactoring cost.
Refactoring and breaking apart code is easier than doing it with a single massive database where it has no source control, and relies heavily on domain-stored procs which in turn are interconnected with each other and other DBs.
"Making a change in module A leads to an unrelated break-in Module Z", then you have a classic monolith issue with tight coupling and your DDD has unintended side effects. This will be a thorn in your side when refactoring to microservices later, fix it if you can.
"It's one architectural style vs the other". No, it's about time, cost, and quality. Each has its own trade-offs and needs to be clearly understood before going to business with an architecture plan.
"You hold on for 1 minute there sir", my monolith architecture is perfect and adheres to all the software architecture acronyms you can throw at it. I am proud of your unicorn but I have yet to see something of this kind in the wild.
To be clear, I prefer to work in a microservice architecture and have seen the increased rate of delivery, stability, and redundancy contribute to successful products that were critical for business growth. In my career I have yet to come across a perfect monolith many developers rant and rave about. But I have also seen some bad microservice implementations where the architecture does not fit the problem and a hybrid between the two or monolith should have been the first choice.
Most of these failures were due to broken down communication between the business, developers, and customers.
Comments