Nit: You have to provision the VPS by peak usage, not dividing monthly usage evenly across the month. So if your peak is 13x the average (very easy, specially if you don't have a worldwide audience) the VPS starts to look bad, and we're not even talking about the risk of unexpected peaks.
back
2 comments
Absorbing peak traffic was the original selling point of the "elastic" cloud. Sure, the cloud was more expensive, but you only had to pay for it for a few hours while traffic peaked. If traffic peaked multiple days in a row, then maybe it was time to rent a new dedicated server.
This is still the most economically sensible infrastructure strategy. Maintain a core group of dedicated servers responsible for a threshold workload. When they can no longer handle all incoming work, they offload the excess to temporarily provisioned cloud workers.
The benefits:
- Guarantee you are only getting price gouged by Amazon for a subset of your traffic
- Force yourself to build software that runs on multiple platforms
- Address scaling requirements up front
Perhaps most importantly, this strategy creates a profit incentive for increasing compute efficiency, regardless of Amazon's pricing structure. Every increase in software efficiency means that the same group of core servers can serve more requests, so you can pay less to Amazon.
Yeah, that's a fair point. Even so, I think there's only a short window in the life of a growing webapp where its baseline traffic is small enough for Lambda to make financial sense.
On the other hand, it looks like Lambda could be pretty great for small personal projects. It would be even better if they added a modest free tier to the request gateway, to match the other services.