For more than 5 years, we are in the age of microservices. Monoliths sound like 90’s tech and a thing we should be embarrassed about having. We’ve seen countless discussions about microservices vs monoliths. We all remember the epic talks of engineers and CTOs from Netflix, Spotify, and other big players. Loads of buzzwords thrown every five minutes: scalability, ownership, devops, redundancy, and more.
So what happened in the last five years? Microservices became the one-size-fits-all solution for every technical problem. But it wasn’t only a trend for startups and a catchy phrase for TED talking gurus. Even traditional corporations like Coca Cola and BestBuy are moving all their infrastructure to microservices.
So… there must be a catch right? It is time we have a serious bias-free discussion about this. More than enough time passed and this topic is somewhat mature. We can find lots of failures and successes, and even detailed post-mortem about them from the people who did it.
Pros and cons
As we stated earlier this topic was analyzed over and over, so we’ll just do a quick recap with no further explanation for the sake of simplicity. You could easily skip this part if you are already familiar with them.
- Horizontal Scalability
- Code reusability
- No single-point-of-failure / Fault-tolerant (If done correctly)
- Elastic (if done correctly and placed on an elastic infrastructure)
- Can greatly reduce hosting cost
- Versatile – Any microservice can be written on any language if the correct guidelines are implemented.
- Infrastructure can be distributed “easily” between servers, cloud zones, etc.
- Low coupling between components
- Steeper learning curve
- Need more experienced developers
- The cost/time to migrate to a microservice architecture could be huge.
- Testing could become hell if not handled properly.
- Needs lots of requirements to be implemented correctly( ci/cd, monitoring, etc)
- Cognitive load. Microservices can become a complicated mesh and introduce a lot of new problems inherent to them (concurrency, service discovery, data consistency, load balancing etc)
- Need less boilerplate code to start a new project
- No special knowledge is required. Every developer is used to work with monoliths. Makes hiring easier.
- Business requirements are usually easier to implement.
- Straightforward to test since the beginning.
- Faster time to market if the requirements are concrete and well known.
- Expensive to scale.
- High coupling between components
- Scalability has software and hardware limitations on monoliths.
- Develop environments could become huge over time.
- Could be hard/expensive to migrate into a cloud environment
- Could be impossible to scale if there’s too much technical debt on the codebase.
To be honest, you probably don’t need microservices if you’re not google-scale or you’re not expecting to grow insanely fast like Netflix, and surely you don’t need to migrate your whole infrastructure to microservices right now.
It could sound a little cliché but you need the right tool for the job. Most of the companies and even crazy startups won’t see the full benefit of implementing them but will need to deal with all the difficulties they could create.
There’s also some kind of “conflict of interest” between developers and management in this topic (like in many others). Developers always want to try the new flashy things (and we got to admit that we all like to brag about using the latest trendy framework/tech) and also want to add to their resume all that beautiful buzz-words.
On the other hand, management mostly sees risks in changing the whole architecture ( with some common-sense) and almost no tangible benefits; and management mostly wants new fancy features they can sell to the clients (or the upper management). All this is a recipe for a perfect disaster.
Moving into microservices must be done almost perfectly to make it worth it. Even experienced developers could lead a decent monolith into a microservice hell. Almost all failed attempts get the worst of both worlds, an anti-pattern called Distributed Monolith (you can read more here)
If we analyze most of the successful migrations into microservices, they were driven almost exclusively from necessity rather than preference. Most of the big early adopters (like Netflix) couldn’t find a way to achieve their business goals with a monolithic architecture.
This also isn’t a recipe for guaranteed success. If you can’t design and implement a modular and robust monolith what makes you think you could do it better with microservices?
Like almost everything in life, the sweet spot is somewhat in the middle. The ideal scenario would be designing a modular enough monolith that could be eventually divided into smaller pieces.
Following that approach, you can start to migrate big modules into stand-alone services (not microservices), and begin turning your monolith into a Service Oriented Architecture (SOA) as needed. After some time, services will be split into smaller services and it will be a time when you’ll have to unavoidably start to deal with all the microservices problems (service discovery, load balancing, consistency, concurrency, latency, etc).
But after all, this approach is much more humane. All the teams can transition seamlessly into the microservice ecosystem without the hassle of hiring 200 new specialists and the priorities can be managed more accordingly to the business requirements.
As some final words, this is just one approach and nothing here is written on stone. Many authors claim that is impossible to seamlessly transition a monolith into successful microservices, and that you’ll need to eventually re-write everything from scratch.
This is debatable but the main topic is that reality usually doesn’t go well with absolutes. Every problem will need a different degree of granularity. So maybe there’s no point in keep discussing microservices vs monoliths