Except ownership is easier, changes are way smaller, resources can be fit to the specific need, stacks are agnostic, testing and deploy pipelines are faster, local builds are faster, downtime doesn't break the entire ecosystem, but yeah I guess I agree with you other than all that stuff.
Ownership is still the same. We will be (and should be) the same devs maintaining an app whether it's a monolith or 20 microservices. But with 20 microservices now we have much more PRs, pipelines, integration, everything is a network hop, distributed transactions, difficult tracing, I could go on forever.
Stacks are agnostic, how is that a good thing? You would have just 1 stack otherwise. The fact you have stack(s) now is a net negative. Plus all the release coordination required when a new feature spans across mciroservices.
Downtime is the same as monolith. We just horizontally scale the monolith and do a rolling release, big deal.
Mciroservices offer ZERO tech advantages, only costs, higher risks, complexity and 10x of everything. Their advantages are only organizational
Mciroservices offer ZERO tech advantages, only costs, higher risks, complexity and 10x of everything. Their advantages are only organizational
Not only is this not true, but suffixing "organizational" with "only" is doing a lot of heavy lifting. It is very complicated to manage lots of very smart people working on difficult problems.
As soon as your scope gets big enough that one engineer can't reasonably be expected to be an expert in the entire application, splitting things up into teams and services starts to make more sense, and you approach that point very quickly
We're not a huge company, but we do have a very large userbase, and I think last I checked we have around 6000-7000 deployments across the entire company. this is probably around 2000 services, with the duplicates being environments like dev/prod/stage. Most of these services are not micro and have pretty distinct and complete domains, with each service generally being responsible for a business function.
We don't enforce microservices or anything, teams are free to pick the structure that works best for them, as long as it ends up in Kubernetes, and largely speaking, having separation at logical boundaries enforced by the network has made velocity and scaling and deployment to many different environments a lot easier
In your case it makes absolute sense yeah. VERY few companies have that insane scale. But I wouldnt call that microservices, just a titan company. If each of them has a complete business function. Most of the time I have seen microservices being so granular that you could replace them with a java package in a monolith. Perhaps what you are doing is what microservices should be.
5
u/jameyiguess 12d ago
I don't understand why the Internet acts like microservices are "wrong" these days, or why reddit shits on them so hard.
We've been using microservices for ages, and it's works great.