I've been using Puppet for more than 2 years now, and written almost 50 custom modules, for about 4K lines of code. The more I work with it, the easier is to find a 3rd party module to solve a problem for me, and I can just focus on very specific needs.
I rarely wrote any Ruby snippets, and basically relied on Puppet's DSL. A couple of times I submitted a pull request for a 3rd party module, and got my changes merged in.
I started using Puppet for a very specific reason: there was already expertise in the company, and most part of the infrastructure pre-requirements were deployed using it (even if in a Master-Slave mode, while I favour the Standalone approach).
All this said, I can't ignore what's going on in the Devops world; many other tools are being developed to solve automation of configuration management, and with the aim of being 1. Extremely easy to use 2. Reliable 3. Scalable.
In my hunt for comparisons I've stumbled upon this article from Ryan Lane.
In my opinion, this is the way comparisons should be made: the hard way, with a 360 degrees approach. Ryan explains how his team moved away from Puppet and chose between Ansible and Salt.
I strongly recommend you take the time to go through it, as it has precious insights that are typically shared only within a team or organization.
And if you have other examples of such thorough analysis, I'd be grateful if you could comment here or drop me a note.
Disclaimer: the opinions here are my own, and I'm not affiliated with either Puppet, Ansible or Salt.
Monday, 20 October 2014
I'm a passionate runner, and always considered cycling as something fun, e.g. mountain-biking, but difficult to practice regularly. The...
Verto is a newly designed signalling protocol for WebRTC clients interacting with FreeSWITCH . It has an intuitive, JSON-based RPC whic...
SILK is a codec defined by Skype, but can be found in many VoIP clients, like CSipSimple . It comes in different flavours (sample rates ...
From time to time I need to verify that the audio inside a trace is as expected. Not much in terms of quality, but more often content and du...