To most people, "mono" refers to
a single codebase, not a single deployed instance. I've worked on many monoliths that run multiple instances in production.
Microservices are no more or less scalable than a monolith. The main benefit of Microservices is allowing multiple teams to work independently from each other without everyone "stepping on each others toes". You can have scalable monoliths and unscalable microservices.
> Microservices are no more or less scalable than a monolith.
This is not fully true. A microservice architecture is more finely scalable than a monolith.
To take a very basic example, if you have a peak of users watching a video you can scale up the microservice dedicated to serving videos, but not scale up the service dedicated to users signups, which isn't having an increased load.
> you can scale up the microservice dedicated to serving videos, but not scale up the service dedicated to users signups, which isn't having an increased load.
No, splitting a codebase does not magically make it more scalable in production. You still have to prove that the authentication component would create significant unnecessary load if it was scaled up together with the video service.
> A microservice architecture is more finely scalable than a monolith.
Apologies, but I strongly disagree and I'm going to go on a bit of a rant here....
This is a myth, and one of the reasons people are making these ridiculous architecture descisions. If you have a monolith that serves videos and enables signups, you can deploy as many instances of that as you like based on the highest need. It doesn't matter if user signups are a fraction of video watches, it just means that your user signup endpoint is not getting called as much. Maybe you're deploying a larger codebase than you need to but that's hardly a downside.
In your example, let's say we have 2 endpoints that are behind a gateway or L7 LB so that we can point them at different codebases if we like:
- videoservice.com/signup
- videoservice.com/watch
If I'm geting 100k rps to /watch, and 100 rps to /signup, I can just deploy loads of instance of my monolith behind the /watch endpoint. Maybe that monolith contains code for /signup, but it's not going to get called. So what.
I've seen this approach used in many places. You don't need to split the code to do this at all. Sure it might feel "cleaner" to you to do this, but it's not needed.
Now, you may get to a point where your deployment is really heavy and time consuming and you don't want to deploy everything just to scale up /watch - but again I'd argue that is not really anything to do with scalability, it's about being able to deploy things independently. Using a microservice doesn't make your service more scalable here, but it might make it easier to deploy.
Microservices are nothing to do with scalability. They are about how you organise code and teams to achieve better development velocity.
> Microservices are nothing to do with scalability. They are about how you organise code and teams to achieve better development velocity.
I don't think this is strictly true; even though microservices are usually used that way.
Scaling up everything even when not needed has it difficulties. You can have lots of unnecessary initialisation tasks, lots of unused caches warmed up, database and socket connections that are not needed, complexities in work sharing algorithms etc.
Thank you for clarifying. It's seems my definition doesn't correspond to others'. Then do we lack a word for a monolithic application that handles everything and that can only have one instance running?
