[LRUG] Idempotency vs the cloud

[Jon Wood]

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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130717/024ed1b4/attachment-0003.html>