Monoliths are bad and so are microservices!
They’re not! They’re just different ways to solve a problem. Yes, you fell for the clickbait title! But you’re already here, so why not read on?
Here’s an important question:
Are microservices better than monoliths?
Consultant answer:
— It depends.
The answer depends mostly on who you ask. If you ask someone solving problems with microservices, they’ll probably answer “YES”. If you ask someone working with monoliths, well, it depends whether they know about microservices or not. If they don’t they’ll probably answer “NO”. If they do, probably the hype got to them too, and they would probably answer “YES” to any question that sounds like “Is X better than a monolith?”
It is very unfortunate that people take this binary approach. It’s the same with all products that are good. They polarise people. They create split opinions, make people take sides. The interesting thing is that most of the time, both sides are right.
Take the example of a presidential election.
If 51% of a population vote for a candidate and the other 49% vote for the other, would you say that the 49% are stupid? Lower human beings? No. They are actually right. Just as right as the 51%. They’re only fewer in number.
Back to microservices vs. monoliths. The people who advocate a decoupled architecture are not “more right” than the ones who advocate a monolithic architecture.
I recently saw a LinkedIn post of someone sharing an article on why “microservices as we know them are bad”. Here’s the link to that post.
I’m no microservices expert, but I worked with some of them during my career. I understand where he was going with the article and with the LinkedIn post. But there are some sections of the article with which I totally disagree.
For reference purposes, I will post the text of the post and my answer, below:
There, I said it. Microservices as we know them are broken. A good designed Monolith is 10x better than a poor microservice architecture. Do you agree?
Here was my entitled, self-absorbed-prick answer:
A well designed ANYTHING is better than a poorly designed ANYTHING ELSE. It’s not about microservices being bad, or about monoliths, for that matter.
If you set up your newly bought electric oven correctly but try to bake plastic bottles, your house burns down.
The concept of an electrical oven is sound, proven and safe. But if you use it the wrong way, I mean, the TOTALLY WRONG way, then your house burns down.
It’s the same with microservices and monoliths. Microservices based architectures are not better than monoliths, they are just different. You trade system reliance (monoliths) for network reliance (microservices). Depending on what you want to optimize, your budgets, capacity, team skill level, product scale, you will use one or the other. The only point you can seriously make in such situations is that the solution you left out was not solving YOUR problem
I think microservices aren’t broken. I think that our understanding of microservices is broken. Our understanding about the viability of a microservices based architecture compared to a monolithic one, for a specific problem is broken. This happens with any hype-driven trends, in software development. Microservices has become some sort of a trend, it has some hype around it, so I can include it in the hype-driven trends category.
Let’s take two hypothetical situations.
At a conference, someone said microservices are the way. But keep in mind that they should respect SRP (Single Responsibility Principle). A software architect heard it and took it to heart. While frustrated with his monolithic Rails application, he went on and converted every class in the application to its own service. Distributed, scaleable, everything you could want. Then, one night, all hell broke loose … because network reliance. Now he can write an article about how crappy microservices are.
At a different conference, across the ocean, someone else said microservices are broken, and monoliths, if well designed, are the way to go. Then, a startup founder made the technical team work on a monolith for the MVP. Got it done quick, added features and got funded after 6 months.
Now, investors wanted to add more features, scale faster, get more MAU and CAC and UVP and whatever three-lettered-words the startup world invented by the time you read this. Now, the founder realises they need 6 more months to “refactor” the application. Just so it can scale and support more users. That’s 6 months spent not going after the “hockey stick”. Good luck explaining that to the investors (runs to create PowerPoint presentation).
The bottom line is that both monoliths and microservices are good at solving different categories of problems.
Do you have a simple project, like a service that enables Snapchat-like tweets? Go with a monolith!
Are you building a Source Control Management statistics application, that performs in-depth analytics on the source code, calculates scores, percentages, notifies members, and is both web-based and has a mobile app? Go with microservices!
Choosing between monolith and microservices is not easy. You have to stop and think about what you’re trying to build. The problem is we all want to jump to building.
— “If we only had a more experienced Node.js developer.”
— “If we only had budget to run this on AWS.”
— “If we only had more developers to work on this.”
— “We need to talk about AI and Machine Learning in our pitches. Investors love that. AI is the future!” 😈
These are all quotes from IT managers and startup founders I personally met and talked to. They just want the right people and the right budget and move on with building.
The problem is that although they are aware of “Failing to plan is planning to fail!”, they somehow assume planning only happens from the business end. That there’s no planning from the software / execution end.
Well, guess what? Software architecture and software design are exactly that: planning, from the execution point of view. Eliminate those, or treat them as non-value and you’ll end up having to “refactor” quite a lot.
Then there’s continuous integration. If you don’t have some form to obtain code-related feedback, on your project, you’re screwed. You’re screwed even if you have it and it is not set up correctly — you have to wait for the end-to-end, UI tests to finish, so that the unit tests would run. I wrote an article in the past about How to set up your CI/CD pipeline for faster feedback
I really hope this article reaches a lot of people and stirs the pot. I want people to speak up, and take sides. Get those collaboration / debate juices flowing and let’s learn something useful!
Cheers!