2 ms·

And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right?

And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales director has left, the product has pivoted, and you’re ‘over engineered’.

jacquesm 4y ago
> And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. No, I'd stop and see if I can help.
- jameshart 4y ago
  For the purposes of my analogy, please assume the police are on the scene already and directing you to continue driving past.
JAlexoid 4y ago
This ties into the fallacy that microservice architecture is inherently infinitely scalable. Microservice advocates championed this fallacy, implemented it... but now, when it's time for critical retrospective - it's not their failure.
candybar 4y ago
Being able to scale to any specific amount of usage is never a reason to use microservices. Plenty of planet-scale services and apps are powered by monoliths. And you never run into any kind of ridiculous overengineering when you refactor things into services for scaling reasons and that's not a microservices architecture in the first place. The problem has always been about people deciding that different parts of the app that differ mostly in terms of business logic somehow need to be independently deployable. It's like deciding that instead of having a single database cluster and having multiple databases and tables, you need a separate, independently scalable cluster for each database table, because of some bogus reasons like some tables are queries more than others and different teams work on different tables and we can't let people join tables because it breaks boundaries or something.

jacquesm 4y ago

> And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. No, I'd stop and see if I can help.

jameshart 4y ago
For the purposes of my analogy, please assume the police are on the scene already and directing you to continue driving past.

JAlexoid 4y ago

This ties into the fallacy that microservice architecture is inherently infinitely scalable. Microservice advocates championed this fallacy, implemented it... but now, when it's time for critical retrospective - it's not their failure.

candybar 4y ago

Being able to scale to any specific amount of usage is never a reason to use microservices. Plenty of planet-scale services and apps are powered by monoliths. And you never run into any kind of ridiculous overengineering when you refactor things into services for scaling reasons and that's not a microservices architecture in the first place. The problem has always been about people deciding that different parts of the app that differ mostly in terms of business logic somehow need to be independently deployable. It's like deciding that instead of having a single database cluster and having multiple databases and tables, you need a separate, independently scalable cluster for each database table, because of some bogus reasons like some tables are queries more than others and different teams work on different tables and we can't let people join tables because it breaks boundaries or something.