- cross-posted to:
- memes@lemmy.cringecollective.io
- cross-posted to:
- memes@lemmy.cringecollective.io
At what point does a collection of microservices become a monolith that uses http instead of a bus 🤔
My favorite is seeing developers directly reach out to a DB of another microservice because “it’s just easier to pull the data from there”. One of the few times I’ve literally said “bruh”
A properly architected and implemented microservice architecture optimizes work throughput while minimizing risk. In practice its architecting in such a way that no part can take down the whole individually - the very opposite of a monolith where everything is inseparably interdependent at some level.
Problem is, most organizations don’t know how to properly architect for and integrate microservice architectures into their environments and work process. Most think that a crew of former sysadmins can just spin up a few saas services, slap some autoscaling on it if they’re feeling spicy, segment along traditional monolith “frontend/backend” lines for “security,” and call it a day. They then spend time and money learning and/or fighting this system, only to see minimal (if any) improvement in work capacity/quality and instead end up with an outsized cloud bill.
The reality is, that hardly any projects actually need or benefit from micro services.
Most applications would scale just fine as a monolith, micro services seem to be rather an organizational tool to separate modules, because you can’t come up with a proper architecture.
Developers tend to think in extremes.
This practice is bad sometimes? Avoid it at all costs!
This practice is good sometimes? Use it all the time without question!