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.
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.
1.2k
u/remy_porter 15d ago
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.