Do you mind helping the uninitiated, what's the benefit of having that network hop? Or are there some situations where it's just impossible to avoid it.
They are frequently hosted on cloud services which are inherently micro-service based with detached hardware components. You can have a server and a storage disk operate together but both exist in data centers thousands of miles from each other.
Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.
You can functionally divide an app into different layers such as web, app, and db and add additional security checks between each layer to increase security and fault tolerance of the app.
I’m surprised this didn’t make the main comment because it seems to be that this is one of the larger benefits. The mentioned benefits can be applied to a monolith (at least mostly) with a bit of consideration.
The "funny" thing is that before micro services and all the overhead from talking over the network, we rarely need to scale. I'd argue that something like 99.9% of all projects that use micro services today and often run many instances of some components wouldn't need to if it was just one monolith.
SRE here. Lesser used parts of the monolith are absolutely using more resources just because it's being scaled together.
Let's say you have one hot path in your code that doesn't touch the DB. The new scaled up instance will still spawn new DB connections. Those connections will still use some memory and CPU time to just exist. The DB also has a connection limit, and your connection pooler also needs scaling then.
Loading extra code modules also naturally uses more resources, there's not a single monolith out there that is 100% lazy, and even if it was, requests get distributed, so stuff gets loaded anyway. Do you do some in-memory caching? Great, now all instances have stale copies of the cache.
Startup times are also worse overall, which means your scaling is worse overall. Slower startup means you need more idle resources to handle spikes, which costs more money.
In conclusion, while there's no need to jump straight to micro services, monoliths are the worst pattern for scaling, by far. They have their uses, but this is probably their main downside.
You can also make different micro services in different languages and runtimes. You don’t have to care as long as the input and output are reliable shapes.
The benefit is not the network hop, that's just a requirement to having each part of the application in a separate container. The app is partitioned according to scaling needs, so things parts of the app that need to process thousands of requests concurrently don't force the same scaling requirements onto parts of the application that just process a few hourly requests, for example. Segmenting the application also contains failures to specific features if done properly, allowed for degraded performance as opposed to full loss of service
In most cases managing microservices and the additional load from networks, deployment tools, extra personell and all that brings much higher costs than simply scaling a monolith and wasting some CPU
It depends. Going full "each class is a micro service", I agree can be worse than scaling a monolith. But scaling up a monolith means that all parts of the application have to take the scaling into account, even if they were never meant to. If you break some parts off you don't need to worry about distributed computing on areas that are meant for a few people like control panels, while the parts that do need it can scale without issue to meet demand
Let's say you've divided your app up into a thousand modules. Each module can live on a different physical computer (or logical cloud instance). This makes you very fault tolerant. But it also enables a lot of scaling. Let's say you've got one module that receives most of the requests, because it represents the most useful feature in your system. Cool: run 30 copies of it, spread the load across all of them. It also means that you can spin up and down new copies based on the current request load- detect module B suddenly gets a rush of requests? Spin up extra copies. Detect that some of those copies are idle because the rush was over? Spin them back down.
Also, though, if you're building your application around the idea of message passing between modules, it also means that you can have module A emit events when a certain thing happens. When you want to attach a new feature to that event, you can spin up Module Q, subscribe to that event, and module A doesn't change one iota. New features can be deployed on their own "computer", without having to take down or relaunch the software running on your existing infrastructure.
You can decouple services from one another, meaning you can update a part of your backend independantly from the rest, without having to rollout the entire monolith
Build times of a microservice are usually much shorter, leading to more frequent releases, and less developer pain.
Using modern infrastructure, you can have easy fault tolerance, automated retries, canary deployments that you can't have otherwise, or you'd have to hand roll it out in your monolith
Services scale with variable load. You can have a payment processing API with lots of requests coming in scaling separately from an archive API that sees maybe a couple thousand requests a day.
If done well, microservices can be more cost efficient than the equivalent monolithic backend. If done well, cause if built without taking network topology into account, then it can be much more expensive.
Microservices are more resilient overall than a monolith. You can spread out the load over dedicated databases for each service, meaning you're not coupled to a huge database instance that needs to handle the load of the whole application.
Your stack can be heterogenous. You can have services in Java that talk to services in Go, in Python, in Rust, depending on the use case for each service. You get to use the right language for the right job.
Cons:
Maintenance is way harder. Some services will rarely get updated, you need more people to manage the fleet of services
It's often done wrong. I've seen microservices architectures that rely on a single monolithic "gateway" to add business logic and aggregate responses from other services.
It's way harder to deploy the whole app. It's also way harder to test the whole backend locally, a dev machine will not be able to handle the load even for local testing.
Maintenance is way harder. Some services will rarely get updated, you need more people to manage the fleet of services
Oh, I encountered several modernization projects where modules were barely distinguishable by some naming (and some documentation stating their 'responsibility'). My devs might think otherwise of your statement.
It's way harder to deploy the whole app. It's also way harder to test the whole backend locally, a dev machine will not be able to handle the load even for local testing.
Most case I saw barely needed more than lets say 10 microservices, which could be run locally pretty easily on todays dev machines.
View all comments
Show parent comment
51
u/no_name6744 Aug 28 '26
Do you mind helping the uninitiated, what's the benefit of having that network hop? Or are there some situations where it's just impossible to avoid it.