Implementing a tool to automate IT infrastructure management has many undeniable benefits. But that doesn't mean there aren't some drawbacks too (usually outweighed by the benefits) that we should be considering, and working to reduce or remove.

Implementing a tool like this in a team usually has a pretty significant impact: new processes, new language(s) to learn, new way of doing pretty much everything on your infrastructure. These tools are complex, so a minority of the team tends to become experts in it, and tries to lead the others. Resistance to change is common and understandable, but unfortunately, this can end up with some of the team members being left behind by the sudden and massive changes to their work. This is clearly not a Good Thing, and certainly not showing very good inclusiveness towards everyone. It is also making some configuration management projects fail, which is definitely a Bad Thing for those of us trying to implement them.

How to improve this situation is a topic dear to me. This has always been the focus of the Rudder and ncf open source projects I work on - making our technologies more accessible, easier to adopt and simpler to understand. Some key points we have focused on include: - Avoiding the necessity to write code (user interfaces of course, but that can be combined with other users writing code) - Separating roles so that experts can implement the how and others can focus on the what - Minimising the amount of effort required (sane and non-surprising default values, auto-configuration where possible, ...)

This talk will explain some of these concepts, and show how we have achieved considerable success using the ""ncf builder"" web interface that can be used to write configuration management policy without writing any code (see http://www.ncf.io).