4 ms·
> If you wait until the spike hits before you spin up your VM you're still too late. precisely. this is the other elephant in the AWS room. the only way to sur
by LoSboccacc 11y ago
> If you wait until the spike hits before you spin up your VM you're still too late.
precisely. this is the other elephant in the AWS room. the only way to survive a spike without service degradation while vm spin up on that platform is through lambdas/s3 served pages/api gateway - but even lambdas lag behind traffic.
but then you need to build your whole architecture for it
anyway I'm running on AWS right now, but for other advantages and services, not for its scalability/price performance.
- ownagefool 11y agoBaking your images and set your scaling thresholds lower should be able to largely deal with that. The thing is though, the scaling is nice but most folks just want the auto-recovery. You stick your app over 3 zones, you have autoscaling and you can run with a couple of Ops savy devs and largely forget about it. You no longer need to pay for that dedicated sysadmin who knows how to manage a datacentre when have a small number of technical staff. The extra hosting bills are less than hiring that other person.
- LoSboccacc 11y agoprecisely. recoverable multi zone postgres without paying a sysadmin. we can manage basic maintenance on our own, but setting up something like that require a skilled consultant in short burst at each upgrade/maintenance check, and for a small operation like ours it's too expensive if we want to match what amazon gives. we do have a custom AMI that just fetch and build the latest snapshot release when we need auto-scaling or auto-recovery, but our real problem is that we currently depend on sticky session, so users accumulated on the initial instances get sucky performances. (and yes we are currently working on fixing it, we cannot outright serialize sessions on dynamo because, reasons)