Hacker News new | comments | show | ask | jobs | submit login

From the link:

As a hosted continuous deployment service releasing changes and scaling automatically is a necessity.

I think the key here is that this blog is talking about a hosted service which responds on demand to their client's needs on an hourly basis. EC2 has a lot of infrastructure which does this for them (as long as they can automate it) and is specifically built for this, whereas they'd have to write it themselves by interfacing with a VPS API otherwise. So EC2 might be worth the money to them. VPS providers are mostly more focussed on giving you 1 or 2 boxes to use, and then you leave your site running with occasional adjustments in capacity etc, not on spinning up and down servers on demand, which is a bit more specialised, and might require tens or even hundreds of servers.

For a normal site that's not going to be relevant, and a VPS is cheaper, for this site, it seems EC2 is a better fit...

I think you're making a lot of assumptions about how a service like their could work and does work. You don't need to write a lot of code to leverage VPS's or scale them, and you don't always need to scale up or down on an hourly basis.

I'll bet you that if they took the historical metrics of their services and their load use and averaged it, buying one or two boxes would easily break even and at the same time not be dependent on a specialized provider or functionality like an auto-scaling VPS.

But that's just a guess.

We actually went that route with historical data and it wasn't any good to be honest. Work patterns change daily, so we really need the auto scaling.

Working with Historical data means you either totally oversubscribe certain days, or totally underdo it. It has to be automated due to the latest load.

Exactly. Price itself is not the main issue, but flexibility is.

For example on Weekends we typically see 20%-30% the traffic that we see during the week, simply because people are not at work. Scaling up and down is an absolute necessity there.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact