Infrastructure as Code

DevOps is not about the tools

That’s true, in the same way that agile is not about the tools either, it’s a set of ideas, concepts, best practices,…

Nice, but… how can I successfully implement it?

Tools can enable change in behavior and eventually change culture [Patrick Debois]

Printer in 1568

The same way the Guttemberg printer was a tool that enabled a cultural change, or that Agile development wouldn’t be possible without Continuous Integration servers, DevOps relies on some tools to implement its principles.

Unfortunately, the same way everyone thinks of themselves as being intelligent enough, and every tool out there is magically cloud enabled, now every tool claims to be DevOps.

However, there is agreement that tools that allow us to deal with infrastructure as code are key on implementing DevOps concepts.

It’s all been invented already, now it’s standardized with tools like Chef or Puppet. Before, you could write your own scripts to automate server installation, configuration,… but everyone would do it their very own way.

Now there’s some common language used by Puppet or by Chef, that allows to share and reuse configuration as modules or recipes.

Infrastructure as Code, a key concept

The concept that infrastructure should be treated as code is really powerful. Server configuration, packages installed, relationships with other servers,… should be modeled with code to be automated and have a predictable outcome, removing manual steps prone to errors. Doesn’t sound bad, does it?

But new solutions bring new challenges, and when infrastructure is code we face the same problems faced by developers.

  • What version of the infrastructure are we using in production?
  • how can we ensure that when an issue is found it gets fixed and redeployed?
  • how can we test the infrastructure as we develop it?

That’s why when dealing with infrastructure as code we should follow development best practices.

For instance we can (and should!)

  • tag, branch and release the code that define our servers.
  • have a lifecycle that covers different stages through the infrastructure code, ie. dev, QA, production.
  • continuously test our infrastructure as we make changes.

10 thoughts on “Infrastructure as Code

  1. The “now with DevOps!” marketing mantra exhibited by so many who shall go unnamed is less a source of confusion than scorn to me. (Patrick Debois felt much less strongly about it than I thought he would here: https://communities.bmc.com/communities/community/bsm_initiatives/devops/blog/2012/03/07/patrick-debois-on-devops–is-devops-at-risk-with-vendor-and-media-hype )

    but still, I think it’s not correctly a job title or a product name….

    As to the IaC concept being key, definitely — but the tooling not so much, I think IaC identifies the “transient” or “age deprecating IP” nature of code. Good blog you’ve got going here!

  2. I look at #DevOps as a process — and more importantly a cultural change. If you try to implement DevOps without changing the culture, you are doomed to fail.

    The tools help augment DevOps — sure, you COULD do everything manually. However, one of the tenants of DevOps is automation. Batch scripts and shell scripts don’t cut it for many reasons. The tools help drive the process and cultural change. Just don’t try to implement the tools without the change!

  3. Pingback: Getting started with Chef

  4. Pingback: Python Development with Eclipse | Troy Scott

  5. Pingback: Managing Puppet modules with librarian-puppet | Carlos Sanchez's Weblog

  6. Pingback: What is DevOps? … in bullet points, quotes and tweets | Evolvable Me

  7. Pingback: The 5 enablers of ‘DevOps as a practice’ | This and that

Leave a comment