[LRUG] Idempotency vs the cloud

[Simon Coffey]

Oops, a bit late to this thread. Thanks all for coming to the talk,
those who did - I enjoyed speaking a lot.

First, a belated correction. Andrew France tactfully pointed out to me
that I was talking complete cobblers about the bootstrapping problem
on OSX - Opscode provide omnibus installers
(http://www.opscode.com/chef/install/), about which they inexcusably
failed to inform me.

I still don't think it's worth Cheffing your laptop, but at least the
chicken/egg question appears to have been resolved in favour of the
egg.

Back on topic:

> tl;dr: If you don't care about running your recipes/manifests/whatever repeatedly, do Chef and Puppet still add enough value to justify their complexity?

Yes (in the sense that I've had a net benefit), and for me most of
that value has come from the composability of recipes and roles, and
the flexibility it gives you when it comes to building new
environments. I found it really exciting that creating a development
system-in-a-box was just a matter of creating a new node definition
with every role, and bunging it into Vagrant. Whether Chef's
complexity is *necessary* to this end is another question, though - I
suspect not, given how long I had to spend working out which bits
could be safely ignored.

On idempotency, I agree with Paul and others that having entirely
ephemeral servers is not (yet?) a realistic goal. Trying to make as
much of my infrastructure as possible disposable has improved my
thinking in terms of data redundancy, even where I do end up with
long-lived server instances. But sometimes it's just not possible, and
in those cases I do put the effort in to make my recipes idempotent.

Cheers,
Simon

On 17 July 2013 12:13, Tom Stuart <tom at codon.com> wrote:
> Hi LRUG,
>
> I enjoyed Simon's talk about Chef on Monday. I'm an occasional user of both Puppet and Chef, and I like the idea of configuration management in principle, but I've never achieved full proficiency with either and I'm interested in why I find it such a struggle to properly integrate them into my life.
>
> One recurring thought I've had, which the talk reinforced, is that some of the complexity (and concomitant notional benefit) of these tools is their ability to convert a declarative description of a desirable state into an idempotent series of imperative actions. And okay, that's great, but is it a bit of a historical accident?
>
> The assumption is that we have persistent servers whose state needs to be carefully massaged over the course of geological time, and that's usually true, but would we have even bothered evolving these tools if some constraint or trend had made us more accustomed to deploying updates by spinning up a fresh EC2 instance instead of frobbing an existing one? If things begin to move more in that direction, can we stop caring about idempotent configuration management, and can it therefore become drastically simpler?
>
> This question appeals to me because of its connection with the imperative vs functional programming situation. Imperative programming is easier (in the Hickey[0] sense) because it more closely matches our intuitive stateful view of the world, but as any fule kno we eventually get into trouble because of the complexity which emerges from over-reliance on state. Functional programming offers an appealing remedy: stop worrying about state, treat everything as a mapping instead of a mutation, and concentrate on how to turn inputs into outputs. Running a one-shot shell script to provision a fresh instance feels simpler than getting Chef or Puppet to massage an existing one; it's not quite functional programming, but it's a gesture in that direction, if only because it doesn't concern itself with how to keep the plates spinning.
>
> tl;dr: If you don't care about running your recipes/manifests/whatever repeatedly, do Chef and Puppet still add enough value to justify their complexity?
>
> Cheers,
> -Tom
>
> [0] http://www.infoq.com/presentations/Simple-Made-Easy
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org