[LRUG] Idempotency vs the cloud

[David Salgado]

I found this a really interesting idea.

I'm a fairly serious puppet user - about 300 machines under config
management (with the excellent @bitfield doing the heavy lifting of setting
up and tweaking the puppet repo).

Puppet runs every 10 minutes on every server, which mainly serves two
functions;

1. Automatically apply security updates to installed software

2. Change configuration files in response to infrastructure changes

(to clarify number 2, a couple of relevant tasks are; if a new back-end
server is added, then the database servers need to poke new holes in their
firewall configs so the servers can talk to them, and the load-balancers
need to know that the back-end server exists, so that they can start
sending it traffic)

Both of those require *something* to be done to a pre-existing server.

In the case of 1, I could just take the view that the server should simply
be replaced with a new one which, when it is built, will use the latest,
patched versions of whatever is installed.

Case 2 is more problematic, because replacing my DB servers, rather than
just tweaking the firewall configs, seems to be massive overkill.

The system as a whole needs to keep itself coordinated as components
(generally servers) are added/removed. This is an area that only Amazon EC2
seems to really have cracked, and they're not suitable for me, for a couple
of reasons.

I think the whole server orchestration area is where a lot of interesting
devops stuff is going to happen over the next couple of years.

David




On 17 July 2013 12:22, Ben Griffiths <bengriffiths at gmail.com> wrote:

> I see that Fowler has given this a name[1].
>
> [1] http://martinfowler.com/bliki/ImmutableServer.html
>
>
> On Wed, Jul 17, 2013 at 12:13 PM, 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
>>
>
>
> _______________________________________________
> 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/ee29c50b/attachment-0003.html>