Successfully reported this slideshow.
Your SlideShare is downloading. ×

Infrastructure as Code Maturity Model v1

Infrastructure as Code Maturity Model v1

Systematically Evolving an Organization’s Infrastructure
. The original version of the IaC Maturity Model. See the latest version here: https://www.slideshare.net/garystafford/how-mature-is-your-infrastructure.

Systematically Evolving an Organization’s Infrastructure
. The original version of the IaC Maturity Model. See the latest version here: https://www.slideshare.net/garystafford/how-mature-is-your-infrastructure.

More Related Content

Infrastructure as Code Maturity Model v1

  1. 1. Systematically Evolving an Organization’s Infrastructure Gary A. Stafford, 2016 Infrastructure as Code Maturity Model
  2. 2. References
  3. 3. Infrastructure as Code Managing Servers in the Cloud Kief Morris, ThoughtWorks O’Reilly, 2016 infrastructure-as-code.com
  4. 4. Continuous Delivery Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble, ThoughtWorks and David Farley Addison-Wesley Signature Series (Fowler), 2011 continuousdelivery.com
  5. 5. What is Infrastructure-as-Code?
  6. 6. 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)
  7. 7. 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)
  8. 8. HashiCorp Packer { "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 FROM ubuntu:16.04 MAINTAINER Docker RUN 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.list RUN apt-get update && apt-get install -y mongodb-org RUN mkdir -p /data/db EXPOSE 27017 ENTRYPOINT ["/usr/bin/mongod"] https://github.com/hashicorp/terraform/blob/master/examples/aws-two-tier/main.tf
  9. 9. AWS CloudFormation 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 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", ] } }
  10. 10. What Infrastructure as Code?
  11. 11. What Infrastructure, as Code? ● Compute ● Databases, Caching, and Messaging ● Storage, Backup, and Content Delivery ● Networking ● Security and Identity ● Monitoring, Logging, and Analytics ● Management Tooling
  12. 12. CD Maturity Model
  13. 13. Areas of Practice ● Build Management and Continuous Integration ● Environments and Deployment ● Release Management and Compliance ● Testing ● Data Management ● Configuration Management
  14. 14. Levels of Maturity ● 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
  15. 15. Maturity Model
  16. 16. Maturity Model Analysis https://github.com/garystafford/cd-maturity-model
  17. 17. Business Value ● Reduced cycle time, to deliver value to your organization faster and increase profitability ● Reduced defects, so that you can improve your efficiency and spend less on support ● Increased predictability of your software delivery lifecycle to make planning more effective ● The ability to adopt and maintain compliance to any regulatory req that you are subject to ● The ability to determine and manage the risks associated with software delivery effectively ● Reduced costs due to better risk management and fewer issues delivering software
  18. 18. Infrastructure-as-Code Maturity Levels
  19. 19. 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
  20. 20. Level 0: Repeatable Processes documented and partly automated ✓ All infrastructure code and configuration are stored in a centralized VCS ✓ Testing, provisioning, and mngt. 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
  21. 21. 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
  22. 22. 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 KMS ✓ Infrastructure code uses declarative versus imperative programming model, maybe…
  23. 23. 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
  24. 24. Using the Maturity Model
  25. 25. Using the Maturity Model ● Classify your infrastructure’s maturity. Different parts of your infrastructure achieve different levels in each of the different categories. ● Choose an area to focus on where your immaturity is especially painful. Value stream mapping will help you identify areas that need improvement. ● Decide which improvements make sense for your organization, estimate their costs and benefits, and prioritize. ● Define acceptance criteria to specify the results that you expect and how they will be measured.
  26. 26. Using the Maturity Model ● Create an implementation plan before implementing any change. ● Use your acceptance criteria to measure if the changes had the desired effect. ● Adjust implementation plan and acceptance criteria if necessary. ● Hold a retrospective meeting of all stakeholders and participants to find out how well the changes were executed and where the potential areas for improvement are. ● Repeat these steps, building upon your knowledge. Roll-out improvements incrementally, and roll them out across your whole organization.
  27. 27. Gary Stafford 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 gary.stafford@thoughtworks.com Twitter twitter.com/GaryStafford Blog ProgrammaticPonderings.com GitHub github.com/garystafford LinkedIn www.linkedin.com/in/garystafford
  28. 28. Questions? Thank you.

×