<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 19 July 2013 16:47, Simon Coffey <span dir="ltr"><<a href="mailto:simon@tribesports.com" target="_blank">simon@tribesports.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 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>
</div>Yes (in the sense that I've had a net benefit), and for me most of<br>
that value has come from the composability of recipes and roles, and<br>
the flexibility it gives you when it comes to building new<br>
environments.</blockquote></div><br></div><div class="gmail_extra">What he said.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Plus, for me at least, it's incredibly useful to have a reasonably sanely-structured description of what different servers are supposed to be doing, and the bits and pieces they need in order to do it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Quite often, servers will need something that's not obviously part of their job. e.g. my database servers need ruby and gems that let them talk to Amazon S3, because that's where they put their backups. If I'm working on a bit of my infrastructure that hasn't been touched in a while, it's *really* helpful to have an accurate description of the state.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">OK, a simpler DSL could potentially do that too, but Puppet/Chef are a solution I can implement right now.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
David</div><div class="gmail_extra"><br></div></div>