Automated config never existed before?
So automated config has never existed before or is there some special spin here I'm missing?
HP Technology Services has announced a partnership with Chef to include infrastructure automation as part of its Datacenter Care offering, at the HP Discover event today in Barcelona. Chef is open source software (under the Apache 2.0 license) for script-driven configuration of servers. The Seattle-based company of the same …
Of course it has existed before.
As a friend of mine if very fond of saying,
The more that you re-invent the wheel, the more square it gets
I'd really like to know what makes Chef so attractive and why it is better than anything else in cluding sliced bread.
For automated configuration, I think cfengine predated both chef and puppet. A copy of cfengine even comes with HP-UX.
cfengine uses a mathematical basis called promise theory, so you can see why it is so popular!
The authors of both chef and pupped apparently knew about cfengine. I always wondered what their objections were that prompted them to create a new entry in that same space.
Totally agree with you. Specially when you know:
1. both chef and puppet run on top of ruby and are way slower than cfengine (this is not an opinion, it has been tested);
2. both chef and puppet are plagued by ruby security vulnerabilities (just this week another patch, I lost count of how many this year.
If anything, I just hope that this competion will make Cfengine release a community version of their software for Windows, that would be awesome.
We're a big puppet shop at the moment, but our code base has been badly managed for years, is bloated, old and in need of a complete overhaul. Before we embark on this and an upgrade to newer versions we decided to have a look at the competition: Chef, Ansible and Salt. Chef is no longer in the running, it doesn't offer any clear advantage over Puppet. Also feedback we've had from contacts in the know say that it encourages messy unreadable code, exactly what we want to avoid. We'll be trying out Ansible and Salt in the coming weeks to see how they stack up.
If you think you're at risk from producing unstructured code, and apparently have a history of producing it, surely the approach is to change how you write the code, not the language you write it in? Any language can be used to produce an unreadable hair-ball, and any language can be used to produce structured, documented and maintainable code.
If a developer was producing C++ code that made extensive use of goto and setjmp, I wouldn't be thinking that the solution was to change to Java.
Present circumstances are different to the past. That risk is well understood and has been tackled by the current team. We could re-write in puppet but why not look at what else is on offer? Alternative designs might suit us better. If the world followed your philosophy we'd all still be learning COBOL.
As always, significant things are done by teams of people. So it is with PowerShell DSC. That said, the bulk of PowerShell DSC was architected by Bruce Payette who has been with the team from the very beginning and is most well known for being the co-designer of the language (along with Jim Truher) and his awesome book PowerShell In Action.
Jeffrey Snover [MSFT]
Distinguished Engineer