[LRUG] Idempotency vs the cloud

[Frederick Cheung]

On 17 Jul 2013, at 15:14, Jon Wood <jon at ninjagiraffes.co.uk> wrote:

> How do you find the performance and reliability from EBS? I avoided it whilst building out our EC2 deployment because I'd heard a lot about how it can become a bottleneck, and can be vulnerable to failures.
> 
> However, the ability to snapshot volumes would seem to outweigh those drawbacks if they're not a problem in practice. Who knows, maybe I should just spin up another instance running on EBS and see how it performs.
> 

The few region wide problems amazon have had were down to EBS, although (so far) the only problem we've had was the time they messed up the clever incremental nature of snapshots and Amazon had to delete a large number of RDS/EBS snapshots. For our app servers disk performance isn't really a factor, (all the assets are served via cloudfront) they barely do any disk IO.

We run some mongo instances on EBS and they don't get massive amounts of load but they seem happy enough (although they don't really like it if you saturate your provisioned IOPS). If you had a very IO intensive workload you'd be better off with one of those instances that has a bunch of local SSDs, but for our needs the convenience wins so far.

Fred

> 
> On 17 July 2013 15:05, Frederick Cheung <frederick.cheung at gmail.com> wrote:
> 
> On 17 Jul 2013, at 14:55, David Nolan <dave at textgoeshere.org.uk> wrote:
> >
> > I'd love my servers to be truly ephemeral. Sadly our Chef recipes are still littered with only_if/not_if conditions to ensure idempotence. The main reasons being
> >
> > - Data gets harder to shift about the more of it you have
> > - If you do several deploys a day to a cloud you pay for in blocks of 1 full hour, it gets expensive to be merciless
> > - It's slow to boot a fresh node/server relative to converging an existing one
> 
> I do a halfway house for app servers for the last 2 reasons, so a deploy of the app is just a 'normal' deploy. However the app is deployed to a separate volume than the boot volume which we then snapshot. On EC2 this means we can then bring up new instances quickly and simply: bake a new instance from an AMI and create a new app volume from the latest snapshot (and this works with autoscaling groups and all that sort of stuff). We use this so that autoscaling can replace dead instances/respond to traffic increases recently and we also do a lot of our overnight processing on temporary instances.
> 
> Fred
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>