[LRUG] Idempotency vs the cloud

[Matthew Ford]

Hi Tom,

The complexity of puppet or chef vs our older shell scripts was something
that for a long time bugged me. We made the switch to Chef after the reuse
of these scripts became an issue. With Chef we have our base cookbooks
which we then include into project specific cookbooks with
http://berkshelf.com/ so the project just defines the nodes, e.g two
frontend servers, and a mongo repl set for example. We also use chef solo
for deployments, which is a bit simpler.

With the integration of Chef and Vagrant, it also makes testing and
developing locally in a VM possible to, so I think the benefits will outway
the complexity in the long run.

Cheers,

--
Matthew Ford

Director of Bit Zesty

T: +44 (0)2071250160

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify Bit Zesty
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. Bit Zesty does not accept liability
for any errors or omissions in the contents of this message, which arise as
a result of e-mail transmission. Opinions expressed in this email are those
of Matthew Ford, and do not necessarily reflect those of Bit Zesty.

Bit Zesty Ltd, a company incorporated in England with registered company
number 06883289.


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