Version 2 of the IaC Maturity Model Presentation What helps leading technology companies like Facebook, Amazon, Netflix, and Etsy increase their speed to market while lowering overall IT costs and increasing customer satisfaction? Examine how to apply the principles from Humble and Farley’s Continuous Delivery Maturity Model to the concepts found in Morris’ Infrastructure as Code, using the new Infrastructure as Code Maturity Model. Link to v2.1 of the IaC Maturity Model: https://github.com/garystafford/cd-maturity-model/raw/requirejs/images/IaC_Maturity_Model%20v2_1.pdf

1. How Mature is Your
Infrastructure?

2. ●
●
●
●
●

3. References

6. Infrastructure as Code

9. Amazon AMI Example
{
builders: [{
type: "amazon-ebs",
access_key: "ACCESS KEY",
secret_key: "SECRET KEY",
region: "us-east-1",
source_ami: "ami-d0f89fb9",
instance_type: "t1.micro",
ssh_username: "ubuntu",
ami_name: "packer-{{.CreateTime}}"
}],
provisioners: [{
type: "shell",
script: "configure.sh",
execute_command: "echo 'vagrant' |
sudo -S sh '{{ .Path }}'"
}]
}
Amazon Internal ELB Example
- local_action:
module: ec2_elb_lb
name: "test-vpc"
scheme: internal
state: present
instance_ids:
- i-abcd1234
purge_instance_ids: true
subnets:
- subnet-abcd1234
- subnet-1a2b3c4d
listeners:
- protocol: http
load_balancer_port: 80
instance_port: 80

12. ●
●
●
●
●
●
●

13. AWS
Azure

14. Continuous Delivery
Maturity Model

17. ●
●
●
●
●
●

18. ●
●
●
●
●

19. Infrastructure as Code
Maturity Model

20. ●
●
●
●
●
●

21. Definition
Practices around
developing IaC
Integration and testing of
infrastructure code
Using IaC to provision and
configure infrastructure
Managing running
infrastructure
Monitor and measure
infrastructure
Area of Practice Development
Continuous
Integration
Provisioning and
Configuration
Management Observability
Level 3 - Optimizing
Focus on process
improvement
Level 2 - Managed
Processes measured
and controlled
Level 1 - Consistent
Processes characterized
and proactive
Level 0 - Repeatable
Processes characterized
but often reactive
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
* Assumes all practices follow security requirements and best practices

22. Definition Practices around developing IaC
Area of Practice Development
Level 3 - Optimizing
Focus on process
improvement
• Continual improvement and optimization of IaC based on evolving industry standards
Level 2 - Managed
Processes measured
and controlled
• All changes are tracked in an Application Lifecycle Management (ALM) tool
• All defects and bugs are tracked in the ALM
Level 1 - Consistent
Processes characterized
and proactive
• All infrastructure is defined as code
• All IaC under version control
• Industry-standard tooling is used to write code declaratively
Level 0 - Repeatable
Processes characterized
but often reactive
• Infrastructure partially automated using scripts
• Not all code is checked into VCS
• Automation doesn't rely on industry-standard tooling
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• Nothing is stored in Version Control System (VCS)
• Scripts are stored on infrastructure, local workstations, or as notes
* Assumes all practices follow security requirements and best practices

23. Definition Integration and testing of infrastructure code
Area of Practice Continuous Integration
Level 3 - Optimizing
Focus on process
improvement
• Continuous improvement of tests at various levels
Level 2 - Managed
Processes measured
and controlled
• Builds are not left broken
• Changes are always promoted through a consistent path to production
Level 1 - Consistent
Processes characterized
and proactive
• CI Server to pull, build, test, and publish IaC artifacts
• Automated tests are run for every check-in
• Test are run in a production-like environment
Level 0 - Repeatable
Processes characterized
but often reactive
• There are some IaC tests
• IaC tests are only run locally
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• No Continuous Integration (CI) Server
• No written IaC tests (functional, performance, compliance)
• No way to test infrastructure before provisioning
* Assumes all practices follow security requirements and best practices

24. Definition Using the IaC to provision and configure infrastructure
Area of Practice Provisioning and Configuration
Level 3 - Optimizing
Focus on process
improvement
• Ability to automatically roll back changes
• Zero-downtime provisioning of infrastructure
• Self-service provisioning
Level 2 - Managed
Processes measured
and controlled
• Ability to manually roll back changes quickly and safely
Level 1 - Consistent
Processes characterized
and proactive
• Provisioned infrastructure is a result of an automated delivery pipeline
• Provisioning is idempotent
Level 0 - Repeatable
Processes characterized
but often reactive
• Provisioning is scripted but executed ad-hoc
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• Infrastructure is built manually from command line or from a GUI
• Existing infrastructure cannot be easily rebuilt
• Provisioning new infrastructure is painful and inconsistent
* Assumes all practices follow security requirements and best practices

25. * Assumes all practices follow security requirements and best practices
Definition Managing running infrastructure
Area of Practice Management
Level 3 - Optimizing
Focus on process
improvement
• Infrastructure is self-healing, self-configurable, and self-optimizing
Level 2 - Managed
Processes measured
and controlled
• Infrastructure is highly available and fault tolerant
Level 1 - Consistent
Processes characterized
and proactive
• Immutable infrastructure (no SSHing into boxes)
• Infrastructure is reliable and performs predictably
Level 0 - Repeatable
Processes characterized
but often reactive
• Patching and upgrades are done through provisioning processes
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• Existing infrastructure is brittle and unreliable
• Patching and upgrades are done directly on running infrastructure
• Troubleshooting is done directly on running infrastructure

26. Definition Monitor and measure infrastructure
Area of Practice Observability
Level 3 - Optimizing
Focus on process
improvement
• Metrics are regularly reviewed
• Metrics are available in real-time
• Production incidents related to infrastructure are rare and always reviewed
Level 2 - Managed
Processes measured
and controlled
• Automated alerting based on active monitoring
• IaC processes and practices are documented and available
Level 1 - Consistent
Processes characterized
and proactive
• Metrics are calculated automatically but not regularly reviewed
• Centralized infrastructure monitoring and logging
Level 0 - Repeatable
Processes characterized
but often reactive
• Metrics are defined, but no way to collect or consistently measure
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• No defined infrastructure metrics: SLAs, KPIs, CSFs
• Monitoring and logging done directly on running infrastructure
• No automated alerting
* Assumes all practices follow security requirements and best practices

27. Definition
Practices around
developing IaC
Integration and testing of
infrastructure code
Using IaC to provision and
configure infrastructure
Managing running
infrastructure
Monitor and measure
infrastructure
Area of Practice Development
Continuous
Integration
Provisioning and
Configuration
Management Observability
Level 3 - Optimizing
Focus on process
improvement
• Continual improvement and
optimization of IaC based on
evolving industry standards
• Continuous improvement of tests at
various levels
• Zero-downtime provisioning of
infrastructure
• Ability to automatically roll back
changes
• Self-service provisioning
• Infrastructure is self-healing,
self-configurable, and self-optimizing
• Metrics are regularly reviewed
• Metrics are available in real-time
• Production incidents related to
infrastructure are rare and always
reviewed
Level 2 - Managed
Processes measured
and controlled
• All changes are tracked in an
Application Lifecycle Management
(ALM) tool
• All defects and bugs are tracked in
the ALM
• Builds are not left broken
• Changes are always promoted
through a consistent path to
production
• Ability to manually roll back
changes quickly and safely
• Infrastructure is highly available
and fault tolerant
• Automated alerting based on active
monitoring
• IaC processes and practices are
documented and available
Level 1 - Consistent
Processes characterized
and proactive
• All infrastructure is defined as code
• All IaC under version control
• Industry-standard tooling is used to
write code declaratively
• CI Server to pull, build, test, and
publish IaC artifacts
• Automated tests are run for every
check-in
• Test are run in a production-like
environment
• Provisioned infrastructure is a
result of an automated delivery
pipeline
• Provisioning is idempotent
• Immutable infrastructure (no
SSHing into boxes)
• Infrastructure is reliable and
performs predictably
• Metrics are calculated
automatically but not regularly
reviewed
• Centralized infrastructure
monitoring and logging
Level 0 - Repeatable
Processes characterized
but often reactive
• Infrastructure partially automated
using scripts
• Not all code is checked into VCS
• Automation doesn't rely on
industry-standard tooling
• There are some IaC tests
• IaC tests are only run locally
• Provisioning is scripted but
executed ad-hoc
• Patching and upgrades are done
through provisioning processes
• Metrics are defined, but no way to
collect or consistently measure
Level -1 - Regressive
Processes unrepeatable,
poorly controlled, and
reactive
• Nothing is stored in Version Control
System (VCS)
• Scripts are stored on infrastructure,
local workstations, or as notes
• No Continuous Integration Server
• No written IaC tests (functional,
performance, compliance)
• No way to test infrastructure before
provisioning
• Infrastructure is built manually from
command line or from a GUI
• Existing infrastructure cannot be
easily rebuilt
• Provisioning new infrastructure is
painful and inconsistent
• Existing infrastructure is brittle and
unreliable
• Patching and upgrades are done
directly on running infrastructure
• Troubleshooting is done directly on
running infrastructure
• No defined infrastructure metrics:
SLAs, KPIs, CSFs
• Monitoring and logging done
directly on running infrastructure
• No automated alerting
* Assumes all practices follow security requirements and best practices

28. Using the IaC Maturity Model

29. ●
●
●
●

30. ●
●
●
●
●

31. https://github.com/garystafford/cd-maturity-model

32. Lead Consultant
DevOps and Software Development
ThoughtWorks, NYC
Consulting on the implementation of DevOps
best practices, continuous delivery, infrastructure
automation, and monitoring of complex,
web-scale, cloud-native application platforms.
Areas of current focus, include: enterprise
software development and delivery, cloud-native
applications, release automation, Terraform,
Docker, Spring Cloud, AWS and JavaScript.
Email

33. Email
Senior Consultant
DevOps and Software Development
ThoughtWorks, NYC
Her personal quest is avoiding and/or removing
as much accidental complexity in her team's' way
as possible, with a current focus on infrastructure
as code. Other skills she’s sharpening / looking
to add to her toolkit in this quest include
distributed systems architecture and functional
programming.