Infrastructure as Code Maturity Model

Systematically Evolving an Organization’s Infrastructure

7 min readNov 25, 2016

Infrastructure and software development teams are increasingly building and managing infrastructure using automated tools that have been described as “infrastructure as code.” – Kief Morris (Infrastructure as Code)
The process of managing and provisioning computing infrastructure and their configuration through machine-processable, declarative, definition files, rather than physical hardware configuration or the use of interactive configuration tools. – Wikipedia (abridged)

Convergence of CD, Cloud, and IaC

In 2011, co-authors Jez Humble, formerly of ThoughtWorks, and David Farley, published their ground-breaking book, Continuous Delivery. Humble and Farley’s book set out, in their words, to automate the ‘painful, risky, and time-consuming process’ of the software ‘build, deployment, and testing process.’

Over the next five years, Humble and Farley’s Continuous Delivery made a significant contribution to the modern phenomena of DevOps. According to Wikipedia, DevOps is the ‘culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.’

In parallel with the growth of DevOps, Cloud Computing continued to grow at an explosive rate. Amazon pioneered modern cloud computing in 2006 with the launch of its Elastic Compute Cloud. Two years later, in 2008, Microsoft launched its cloud platform, Azure. In 2010, Rackspace launched OpenStack.

Today, there is a flock of ‘cloud’ providers. Their services fall into three primary service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Since we will be discussing infrastructure, we will focus on IaaS and PaaS. Leaders in this space include Google Cloud Platform, RedHat, Oracle Cloud, Pivotal Cloud Foundry, CenturyLink Cloud, Apprenda, IBM SmartCloud Enterprise, and Heroku, to mention just a few.

Finally, fast forward to June 2016, O’Reilly releases Infrastructure as Code
Managing Servers in the Cloud, by Kief Morris, ThoughtWorks. This crucial work bridges many of the concepts first introduced in Humble and Farley’s Continuous Delivery, with the evolving processes and practices to support cloud computing.

This post examines how to apply the principles found in the Continuous Delivery Maturity Model, an analysis tool detailed in Humble and Farley’s Continuous Delivery, and discussed herein, to the best practices found in Morris’ Infrastructure as Code.

Infrastructure as Code

Before we continue, we need a shared understanding of infrastructure as code. Below are four examples of infrastructure as code, as Wikipedia defined them, ‘machine-processable, declarative, definition files.’ The code was written using four popular tools, including HashiCorp Packer, Docker, AWS CloudFormation, and HashiCorp Terraform. Executing the code provisions virtualized cloud infrastructure.

HashiCorp Packer

Packer definition of an AWS EBS-backed AMI, based on Ubuntu.

{
  "variables": {
    "aws_access_key": "",
    "aws_secret_key": ""
  },
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "us-east-1",
    "source_ami": "ami-fce3c696",
    "instance_type": "t2.micro",
    "ssh_username": "ubuntu",
    "ami_name": "packer-example {{timestamp}}"
  }]
}

Docker

Dockerfile, used to create a Docker image, and subsequently a Docker container, running MongoDB.

FROM ubuntu:16.04
MAINTAINER DockerRUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927
RUN echo "deb http://repo.mongodb.org/apt/ubuntu \
$(cat /etc/lsb-release | grep DISTRIB_CODENAME | cut -d= -f2)/mongodb-org/3.2 multiverse" | \
tee /etc/apt/sources.list.d/mongodb-org-3.2.listRUN apt-get update && apt-get install -y mongodb-org
RUN mkdir -p /data/dbEXPOSE 27017
ENTRYPOINT ["/usr/bin/mongod"]

AWS CloudFormation

AWS CloudFormation declaration for three services enabled on a running instance.

services: 
  sysvinit: 
    nginx: 
      enabled: "true"
      ensureRunning: "true"
      files: 
        - "/etc/nginx/nginx.conf"
      sources: 
        - "/var/www/html"
    php-fastcgi: 
      enabled: "true"
      ensureRunning: "true"
      packages: 
        yum: 
          - "php"
          - "spawn-fcgi"
    sendmail: 
      enabled: "false"
      ensureRunning: "false"

HashiCorp Terraform

Terraform definition of an AWS m1.small EC2 instance, running NGINX on Ubuntu.

resource "aws_instance" "web" {
  connection { user = "ubuntu" }
instance_type = "m1.small"
Ami = "${lookup(var.aws_amis, var.aws_region)}"
Key_name = "${aws_key_pair.auth.id}"
vpc_security_group_ids = ["${aws_security_group.default.id}"]
Subnet_id = "${aws_subnet.default.id}"
provisioner "remote-exec" {
  inline = [
    "sudo apt-get -y update",
    "sudo apt-get -y install nginx",
    "sudo service nginx start",
  ]
 }
}

Cloud-based Infrastructure as a Service

The previous examples provide but the narrowest of views into the potential breadth of infrastructure as code. Leading cloud providers, such as Amazon and Microsoft, offer hundreds of unique offerings, most of which may be defined and manipulated through code — infrastructure as code.

What Infrastructure as Code?

The question many ask is, what types of infrastructure can be defined as code. Although vendors and cloud providers have their unique names and descriptions, most infrastructure is divided into a few broad categories:

Compute
Databases, Caching, and Messaging
Storage, Backup, and Content Delivery
Networking
Security and Identity
Monitoring, Logging, and Analytics
Management Tooling

Continuous Delivery Maturity Model

We also need a common understanding of the Continuous Delivery Maturity Model. According to Humble and Farley, the Continuous Delivery Maturity Model was distilled as a model that ‘helps to identify where an organization stands in terms of the maturity of its processes and practices and defines a progression that an organization can work through to improve.’

The Continuous Delivery Maturity Model is a 5x6 matrix, consisting of six areas of practice and five levels of maturity. Each of the matrix’s 30 elements defines a required discipline an organization needs to follow, to be considered at that level of maturity within that practice.

Areas of Practice
The CD Maturity Model examines six broad areas of practice found in most enterprise software organizations:

Build Management and Continuous Integration
Environments and Deployment
Release Management and Compliance
Testing
Data Management
Configuration Management

Levels of Maturity
The CD Maturity Model defines five level of increasing maturity, from a score of -1 to 3, from Regressive to Optimizing:

Level 3: Optimizing — Focus on process improvement
Level 2: Quantitatively Managed — Process measured and controlled
Level 1: Consistent — Automated processes applied across whole application lifecycle
Level 0: Repeatable — Process documented and partly automated
Level -1: Regressive — Processes unrepeatable, poorly controlled, and reactive

Maturity Model Analysis
The CD Maturity Model is an analysis tool. In my experience, organizations use the maturity model in one of two ways. First, an organization completes an impartial evaluation of their existing levels of maturity across all areas of practice. Then, the organization focuses on improving the overall organization’s maturity, attempting to achieve a consistent level of maturity across all areas of practice. Alternately, the organization concentrates on a subset of the practices, which have the greatest business value, or given their relative immaturity, are a detriment to the other practices.

CD Maturity Model Analysis Tool : https://github.com/garystafford/cd-maturity-model

Infrastructure as Code Maturity Levels

Although infrastructure as code is not explicitly called out as a practice in the CD Maturity Model, several infrastructure as code best practices can be found in the maturity model. For example, the model prescribes automated environment provisioning, orchestrated deployments, and the use of metrics for continuous improvement.

Instead of trying to retrofit infrastructure as code into the existing CD Maturity Model, I believe it is more effective to independently apply the model’s five levels of maturity to infrastructure as code. To that end, I have selected many of the best practices from the book, Infrastructure as Code, as well as from my experiences. Those selected practices have been distributed across the CD Maturity Model’s five levels of maturity.

The result is the first pass at an evolving Infrastructure as Code Maturity Model. This model may be applied alongside the broader CD Maturity Model, or independently, to evaluate and further develop an organization’s infrastructure practices.

IaC Level -1: Regressive
Processes unrepeatable, poorly controlled, and reactive

Limited infrastructure is provisioned and managed as code
Infrastructure provisioning still requires many manual processes
Infrastructure code is not written using industry-standard tooling and patterns
Infrastructure code not built, unit-tested, provisioned and managed, as part of a pipeline
Infrastructure code, processes, and procedures are inconsistently documented, and not available to all required parties

IaC Level 0: Repeatable
Processes documented and partly automated

All infrastructure code and configuration are stored in a centralized version control system
Testing, provisioning, and management of infrastructure are done as part of automated pipeline
Infrastructure is deployable as individual components
Leverages programmatic interfaces into physical devices
Automated security inspection of components and dependencies
Self-service CLI or API, where internal customers provision their resources
All code, processes, and procedures documented and available
Immutable infrastructure and processes

IaC Level 1: Consistent
Automated processes applied across whole application lifecycle

Fully automated provisioning and management of infrastructure
Minimal use of unsupported, ‘home-grown’ infrastructure tooling
Unit-tests meet code-coverage requirements
Code is continuously tested upon every check-in to version control system
Continuously available infrastructure using zero-downtime provisioning
Uses configuration registries
Templatized configuration files (no awk/sed magic)
Secrets are securely management
Auto-scaling based on user-defined load characteristics

IaC Level 2: Quantitatively Managed
Processes measured and controlled

Uses infrastructure definition files
Capable of automated rollbacks
Infrastructure and supporting systems are highly available and fault tolerant
Externalized configuration, no black box API to modify configuration
Fully monitored infrastructure with configurable alerting
Aggregated, auditable infrastructure logging
All code, processes, and procedures are well documented in a Knowledge Management System
Infrastructure code uses declarative versus imperative programming model, maybe…

IaC Level 3: Optimizing
Focus on process improvement

Self-healing, self-configurable, self-optimizing, infrastructure
Performance tested and monitored against business KPIs
Maximal infrastructure utilization and workload density
Adheres to Cloud Native and 12-Factor patterns
Cloud-agnostic code that minimizes cloud vendor lock-in