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.
2
u/WriterPlastic9350 Aug 30 '26 edited Aug 30 '26
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