Embed Size (px)
Citation preview
How Mature is Your Infrastructure?
●
●
●
●
●
References
Infrastructure as Code
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
●
●
●
●
●
●
●
AWS
Azure
Continuous Delivery Maturity Model
●
●
●
●
●
●
●
●
●
●
●
Infrastructure as Code Maturity Model
●
●
●
●
●
●
DefinitionPractices arounddeveloping 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 - OptimizingFocus on process improvement
Level 2 - ManagedProcesses measured and controlled
Level 1 - ConsistentProcesses characterized and proactive
Level 0 - RepeatableProcesses characterized but often reactive
Level -1 - RegressiveProcesses unrepeatable, poorly controlled, and reactive
* Assumes all practices follow security requirements and best practices
Definition Practices around developing IaC
Area of Practice DevelopmentLevel 3 - OptimizingFocus on process improvement
• Continual improvement and optimization of IaC based on evolving industry standards
Level 2 - ManagedProcesses 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 - ConsistentProcesses 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 - RepeatableProcesses 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 - RegressiveProcesses 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
Definition Integration and testing of infrastructure code
Area of Practice Continuous IntegrationLevel 3 - OptimizingFocus on process improvement
• Continuous improvement of tests at various levels
Level 2 - ManagedProcesses measured and controlled
• Builds are not left broken
• Changes are always promoted through a consistent path to production
Level 1 - ConsistentProcesses 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 - RepeatableProcesses characterized but often reactive
• There are some IaC tests
• IaC tests are only run locally
Level -1 - RegressiveProcesses 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
Definition Using the IaC to provision and configure infrastructure
Area of Practice Provisioning and Configuration
Level 3 - OptimizingFocus on process improvement
• Ability to automatically roll back changes
• Zero-downtime provisioning of infrastructure
• Self-service provisioning
Level 2 - ManagedProcesses measured and controlled
• Ability to manually roll back changes quickly and safely
Level 1 - ConsistentProcesses characterized and proactive
• Provisioned infrastructure is a result of an automated delivery pipeline
• Provisioning is idempotent
Level 0 - RepeatableProcesses characterized but often reactive
• Provisioning is scripted but executed ad-hoc
Level -1 - RegressiveProcesses 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
* Assumes all practices follow security requirements and best practices
Definition Managing running infrastructure
Area of Practice ManagementLevel 3 - OptimizingFocus on process improvement
• Infrastructure is self-healing, self-configurable, and self-optimizing
Level 2 - ManagedProcesses measured and controlled
• Infrastructure is highly available and fault tolerant
Level 1 - ConsistentProcesses characterized and proactive
• Immutable infrastructure (no SSHing into boxes)
• Infrastructure is reliable and performs predictably
Level 0 - RepeatableProcesses characterized but often reactive
• Patching and upgrades are done through provisioning processes
Level -1 - RegressiveProcesses 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
Definition Monitor and measure infrastructure
Area of Practice ObservabilityLevel 3 - OptimizingFocus 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 - ManagedProcesses measured and controlled
• Automated alerting based on active monitoring
• IaC processes and practices are documented and available
Level 1 - ConsistentProcesses characterized and proactive
• Metrics are calculated automatically but not regularly reviewed
• Centralized infrastructure monitoring and logging
Level 0 - RepeatableProcesses characterized but often reactive
• Metrics are defined, but no way to collect or consistently measure
Level -1 - RegressiveProcesses 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
DefinitionPractices arounddeveloping 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 - OptimizingFocus 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 - ManagedProcesses 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 - ConsistentProcesses 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 - RepeatableProcesses 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 - RegressiveProcesses 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
Using the IaC Maturity Model
●
●
●
●
●
●
●
●
●
https://github.com/garystafford/cd-maturity-model
Lead Consultant DevOps and Software DevelopmentThoughtWorks, 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.
EmailSenior Consultant DevOps and Software DevelopmentThoughtWorks, 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.
