http://www.agileweboperations.com/the-implications-of-infrastructure-as-code
I’m seeing a lot of problems emerging in organisations starting to put these kind of ideas into practice.
Here are a few symptoms:
- Sprawling masses of Puppet code, duplication, contradiction and a lack of clear understanding of what it all does.
- A fear of change – a sense that we dare not meddle with the manifests or recipes, because we’re not entirely certain how the system will behave.
- Bespoke software that started off well-engineered, and thoroughly tested, littered with TODOs, and FIXME and quick hacks.
- A sense that, despite the lofty goal of capturing the expertise required to understand an infrastructure in the code itself, if one or two key people were to leave, the organisation or team would be in trouble.
As a corrective, I think we need to start thinking about six key areas of our Infrastructure Code:
- Design
- Collective Ownership
- Review
- Standards
- Testing
- Refactoring
