<div dir="ltr">I found this a really interesting idea.<div><br></div><div>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).</div>
<div><br></div><div>Puppet runs every 10 minutes on every server, which mainly serves two functions;</div><div><br></div><div>1. Automatically apply security updates to installed software</div><div><br></div><div>2. Change configuration files in response to infrastructure changes</div>
<div><br></div><div>(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)</div>
<div><br></div><div>Both of those require *something* to be done to a pre-existing server. </div><div><br></div><div>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.</div>
<div><br></div><div>Case 2 is more problematic, because replacing my DB servers, rather than just tweaking the firewall configs, seems to be massive overkill. </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>David</div><div><br></div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 July 2013 12:22, Ben Griffiths <span dir="ltr"><<a href="mailto:bengriffiths@gmail.com" target="_blank">bengriffiths@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I see that Fowler has given this a name[1].<div><br></div><div>[1] <a href="http://martinfowler.com/bliki/ImmutableServer.html" target="_blank">http://martinfowler.com/bliki/ImmutableServer.html</a></div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 12:13 PM, Tom Stuart <span dir="ltr"><<a href="mailto:tom@codon.com" target="_blank">tom@codon.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi LRUG,<br>
<br>
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.<br>


<br>
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?<br>


<br>
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?<br>


<br>
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.<br>


<br>
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?<br>
<br>
Cheers,<br>
-Tom<br>
<br>
[0] <a href="http://www.infoq.com/presentations/Simple-Made-Easy" target="_blank">http://www.infoq.com/presentations/Simple-Made-Easy</a><br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>