[kayoone]

I am not "foisting responsibility". There are fallbacks and fail safes in place to mitigate such issues but that's not my point. My point is that they sell us a dream of infinite scaling, all managed and no more problems, which just isn't the case. I know, it's naive to believe that in the first place but the marketing certainly goes into that direction and some proponents spin this story all the time. Would the alternative be better? Most certainly not, but it's still a question worth asking from time to time considering the extra money spent.

[cinquemb]

> Most certainly not, but it's still a question worth asking from time to time considering the extra money spent.

Esp if you are not vc backed and infra costs are already near the same order of magnitude as most of the dev team and are running into scaling issues…

[kelnos]

I think you're maybe mixing up different things? "Infinite scaling" doesn't mean your app is failure-free and constantly available. In my experience AWS's scaling features work pretty well, as does their on-demand provisioning. But they have very little to do with tolerating infrastructure failures. That's up to you, regardless of whether you're developing on AWS or on hardware you own.

[kayoone]

Let me provide an example. When we recreated a big Elasticsearch cluster, AWS ran out of available instance types in that AZ resulting in the cluster never going into a green state because a node was missing. This is not something you typically worry about when you choose a cloud provider. Your tone is a bit condescending tbh, you don't need to lecture me about the importance of a fault tolerant distributed system.

[xchaotic]

yeah, kayoone response was to the argument “AWS is more expensive but it scales”. In fact it’s not magic and you still have to manage it so worth looking at alternatives such as bare metal, especially at scale.