Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cloud is about elasticity. At ${work} we spin up a ton of EC2 instances in anticipation of huge traffic spikes that happen predictably several times a day, in different regions, and spin them down afterwards.

It's also about simplicity. Many services come pre-configured on.AWS, with clustering, failover, backups, etc already present.

When you are small, you can sysadmin your server fine, and you don't yet need the cloud.

When you are colossal, you want everything custom, and the cloud would cost you a huge amount, so you go for your own servers (and possibly datacenters).

But for the midrange, the expense of hiring several more SREs to handle dedicated servers is usually higher than the entire AWS bill, and the cloud looks very reasonable.



I can’t help but think that a 10x user spike causing a 10x CPU spike is mostly caused by poorly performing web apps written in dynamic scripting languages and the ethos “Just add more servers, servers are cheaper than developers.”

Turns out, developers are cheaper than DevOps engineers and AWS budgets. So if a linear spike in servers necessitates a superlinear cost in operational complexity, maybe working highly performant web app backends is actually cheaper?


The cost is also never just the scaling of servers. Scaling introduces are different class of bugs / issues:

- database connection limits

- caches

- state changes

- handling graceful shutdown

- speed of provisioning new instances

... the list goes on ...


Counterpoint: for some years we had clients who happily lived on cheap as fuck plans but requested more at the anticipated calendar events (NY and the like).

Most of the time we just removed GHz limits, sometimes adding vCPUs in advance, they fared well.

NB: IaaS provider with a guarenteered resources


Yes, if your elasticity requirements are not within hours but within weeks or months, adding and removing capacity can be done by traditional means, even by renting physical servers and putting them into your on-premises racks.


You missed the point - for some the 'elasticity' is just being able to consume 12-20GHz instead of ~1-2GHz 350 days of the year. Sure, you can deploy some advanced hyper-scaling arch to do so... or just move to a fatter instance.


How much would it cost to handle your peak load with dedicated servers and no scaling?


With the peak load being about 10x the still load, the dedicated servers should cost 10% of the cloud version.

We'd likely have to have some reserve just in case our marketing and product do so well that the next peak of the load rises higher in absolute terms.


Hybrid approaches are also really good, but I'm gonna be honest: If capital is not an issue and the growth is to be expected, I wouldn't steer into dedicated server region. It's just such an headache if it's not the core business


Dedicated servers are way less of a headache than cloud in my experience. Unless you are talking about buying and building your own hardware, which is a completely separate thing and not generally recommended. You can lease dedicated servers these days as easily as launching a cloud compute instance but way less than half the price. I pay around $265/mo for 32 cores and 128gb of ram with local, dual, mirrored 1tb SSD drives. Looks like a reserved instance with similar performance on AWS would be somewhere around $700/mo.


Last time I ran the math, it made sense for us to provision bare metal for 70% of our baseload, but our regions skew EU/US




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: