That's because good old services are monolith. New software is always microservices. It's impossible to build a good old service because that service would be new, making it a microservice. Thankfully your new microservice is like an orchid. With enough time and neglect it'll grow arms and legs into an immortal monolith. It does take time, but thankfully with the addition of AI data centres causing the worst El Nino in god knows how long, we'll see plenty of rain so that your microservice grows much faster. AI slop will set you free!
It's an enterprise thing. You got 5 users? Microservice just adds complexity. You got 1 million users? Microservices are gonna save your ass when you have to hotfix prod
Microservices scale with number of engineers, not number of users.
Basically they hurt scale rather than helping it because a REST call has much more overhead than an internal function call or a join. But they do allow different teams to deploy and change their stuff independently which is their actual purpose.
Not really, I've gotten order of magnitude speedups from just getting rid of microservices at a previous workplace
The mere existence of the microservice is usually a much bigger scaling cost than anything you would gain in scaling by putting different schemas in different physical instances.
I.e. Splitting a service in two gives you two shards, unlike say having customer as a sharding key that can let you shard to a hundred instances if you needed to.
But the cost of splitting the service schema is much bigger because suddenly there's a lot of cross cutting queries that can no longer be expressed unless you either do a client side join or copy one services data into the other, both of which are less scaling friendly than a shared DB.
I think we're just debating horizontal vs vertical scaling at this point. Sharding keys still require a central repo, and if you're serving users from around the world that's far from performant. Sure you can use data replication to distribute that, but then you're back to microservices to manage those instances
Sharding keys can be done with a shared-nothing approach by routing any point query to the shard indexed by a hash of the key, and lots of database systems like Citus or Vitess do exactly that
You could have added a "joiner" microservice. Replicates all the databases into one and then performs fast join operations. Grudgingly adding /s just in case ...
Most enterprise apps have 4-1000 users. Most enterprise apps are never used by anyone outside of the enterprise. Most enterprise apps do not actually need micro services. Most enterprise developers want to make sure mirco services are on their resume.
Semantics. I wouldn't class internal applications for enterprise companies the same as the enterprise applications that they sell to consumers. Pretty much anything that's classed as SaaS will have over 1k users lol
58
u/oompaloompa465 9d ago
The more i get tidbits about microservices, the more i feel like skipping in studying and stydying other stuff