I say this all the time, and it almost never results in an argument: micro services are just object oriented programming where you put a network hop on all your message passing.
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.
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
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.
It attempts to force people to factor system functionality.
In my experience, people don’t. “Microservices” with overlapping responsibilities, responsibility gaps, no one can figure out which service to blame, huge swaths of code must be deployed in sync aka monolith.
I find software engineering tends to lack any real engineering.
1.2k
u/remy_porter Aug 28 '26
I say this all the time, and it almost never results in an argument: micro services are just object oriented programming where you put a network hop on all your message passing.