The scale part of the cloud is often not as exciting as it seems on paper. Yes a cloud can auto-scale 100x. But can everything else support that? Like is your DB setup to handle 100x increase in load? (Sure, use dynamo DB, but that has other restrictions).

If the cloud to bare metal price difference is 10x.. you could easily just buy bare metal = 2x your peak load, and still come out ahead..

What you state makes sense. For me, I haven't worked in an environment (yet) that would need to handle fluctuating loads at scale—so my comment is my own speculation based on my experience working for smaller businesses with MUCH less data and bandwidth usage compared to those mentioned here.

And that's why I come to HN, lobsters, etc :) so that I can read and learn from others' experiences...

Honestly, a lot of people overengineer the scaling thing.

Google really does need a service that can scale to 100M users.

I doubt someone starting a SaaS to make garbage truck software needs to. Or at a minimum, at the time they need that kind of scale, they will have plenty of money to throw at hardware. It's amazing how many users a single maxed DB can handle.

I've worked with dozens of different companies, and it's pretty rare to truly have such crazy variance in load.

also, the moment it does happen you usually have non technical systems which are even harder to scale. (customer support for instance, or your sales/billing pipeline).

If you go for horizontal scaling like that, indeed everything needs to be adjusted. If you're asking "is your DB setup to handle 100x increase in load" then likely the answer is no. "How do you shard your writes" is likely a better question then... Aggressive autoscaling requires different thinking.

Depends on how many times you've scaled 100x already. 1 user to 100 users is 100x, 100 users to 10k users is 100x, 10k users to 1 million users is 100x. Aurora serverless autoscaling can handle a LOT, depending on the architecture and use case.

Yes, different situations require different solutions. I think most people learn this by the time they reach puberty.

If you're trying to reduce costs on a complicated usage pattern, then you'll probably want to have someone on staff or consultant who knows how to deal with those things.

I don't know your experience, but bare metal has at least an order of magnitude greater efficiency at one or two magnitudes lower cost. If you want to pay $1MM/mo for something that could also be done for (generously) $20K/mo (plus a couplefew salaries that add up to much less than $1MM/mo), that's your business, but I don't see how the use-case you describe requires cloud/AWS.

The thing that people don't get (or have forgotten, or...) is that you don't have to spin up hundreds of instances in the way you do on AWS, you just handle them on a machine or three that already has enough headroom to handle them.

(all hypothetical blather shaped to support my perspective and disprove the utility of yours, of course ;)

> Yes, different situations require different solutions. I think most people learn this by the time they reach puberty.

Not so sure about most people learning this...though, I will say I'm probably a late bloomer compared to most on HN :)

What you state makes sense. I think my tone was dismissive of the idea that running your own machines is worthwhile. To add to that, I haven't (yet) worked on large-scale systems so my comment is purely speculation.

The promise of cloud scalability never really materialized in the way that people talk about. The value in cloud today is really in hosted services. Why have loads of exports for different supporting infra if you can just lease them from AWS through a hosted service.

If you look at what it would cost to run bare metal with top shelf companies, it's often as cheap or cheaper than spot/preemptible instances at the cloud shops.

This... modern architectures for mid sized companies are a combination of hosted services. I still have bad dreams when I look back a on prem Swift stack object store project took years to stand up & integrate all to have a much higher TCO and self manage a bunch of out of date s3 translation libraries.

It was a system that had fixed scale, high licencing costs and did not bridge well into software that increasingly leveraging the AWS environment. Egress was least of our worries relative to integration complexity in services ecosystem.

You have to be a very very large scale before self managed services make sense; as you suffer at integration layers for every developer that is even an inch off the well beaten path.

We always ran most load in our own data centers with the ability to transparently shed load into AWS for large peaks. It saved a lot of money.