←back to thread

1087 points smartmic | 1 comments | | HN request time: 0.209s | source
Show context
anthomtb ◴[] No.44303941[source]
So many gems in here but this one about microservices is my favorite:

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

replies(8): >>44304390 #>>44304916 #>>44305299 #>>44305300 #>>44306811 #>>44306862 #>>44306886 #>>44309515 #
api ◴[] No.44305299[source]
I have a conspiracy theory that it’s a pattern pushed by cloud to get people to build applications that:

- Cannot be run without an orchestrator like K8S, which is a bear to install and maintain, which helps sell managed cloud.

- Uses more network bandwidth, which they bill for, and CPU, which they bill for.

- Makes it hard to share and maintain complex or large state within the application, encouraging the use of more managed database and event queue services as a substitute, which they bill for. (Example: a monolith can use a queue or a channel, while for microservices you’re going to want Kafka or some other beast.)

- Can’t be run locally easily, meaning you need dev environments in cloud, which means more cloud costs. You might even need multiple dev and test environments. That’s even more cloud cost.

- Tends to become dependent on the peculiarities of a given cloud host, such as how they do networking, increasing cloud lock in.

Anyone else remember how cloud was pitched as saving money on IT? That was hilarious. Knew it was BS way back in the 2000s and that it would eventually end up making everything cost more.

replies(2): >>44305339 #>>44305662 #
1. pphysch ◴[] No.44305339[source]
Those are all good points, but missing the most important one, the "Gospel of Scalability". Every other startup wants to be the next Google and therefore thinks they need to design service boundaries that can scale infinitely...