Download to read offline
Uploaded bySurjeet Singh
Infrastructure as Code
The document discusses Infrastructure as Code (IaC) as a core principle of DevOps, highlighting its role in automation, consistency, and efficiency in managing infrastructure. It presents challenges of manual infrastructure management, such as lack of reproducibility and increased operational overhead, while contrasting high-performing organizations that leverage IaC with those that do not. Various practices and strategies for implementing IaC, including modular infrastructure and automated testing, are also outlined along with examples and design patterns.
More Related Content
![Perforce webinar clear-case_jb[2]](https://cdn.slidesharecdn.com/ss_thumbnails/perforce-webinarclearcasejb2-171107142005-thumbnail.jpg?width=640&height=640&fit=bounds)
Infrastructure as Code
- 1.
- 2. ABOUT US Surjeet Singh DevOpsConsultant @ThoughtWorks Twitter: @_singhsurjeet Github: https://github.com/singhsurjeet Harmeet Singh Quality Consultant @ThoughtWorks Twitter: @ErHarmeet Github: https://github.com/hrmeetsingh
- 3. AGENDA • Getting theaudience understanding about IaC • State of DevOps Report • Problems/Challenges • Principals and Practices • Examples • Demo
- 4. What is Infrastructureas Code? • Infrastructure as Code is one of the cornerstones of DevOps. It is the “A” in “CAMS”: culture, automation, measurement, and sharing. • Infrastructure as code is an approach to infrastructure automation based on practices from software development. • It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration
- 5. How do youmake changes to our infrastructure?
- 6. Pitfalls of ManualInfrastructure Management • No Reproducibility • No Versioning • No Seamless Audits • Manual verification test • Operational Overhead (time/cost)
- 7. HOW LONG? Provision anew server? Rebuild and environment? Change a configuration setting? Update package across all servers?
- 8. HOW EFFECTIVE? Failed changes? Failure detection? Inconsistentversions? Effort for changes?
- 10. HIGH PERFORMING ORGANIZATIONS •Deploys 46 times more frequently • 440 times faster lead times • 96 times faster mean time • 5 times lower change failure rate THEY SPEND • Spent 21 percent less time on unplanned work and rework • 44 percent more time on new work • 50 percent less time remediating security issues than low performers
- 11. FASTER IS SAFER 2017State of DevOps Report High Performing Organizations vs medium/low performing organizations
- 12.
- 13.
- 14.
- 15.
- 16. • DON’T TOUCHTHAT SERVER. DON’T POINT AT IT. DON’T EVEN LOOK AT IT.
- 17.
- 19. The idea ofenabling Infrastructure as Code is that the systems and devices used to run software can be treated as if they, themselves, are software. IaC by Kief Morris
- 20.
- 21. ALL YOUR STUFFCAN BE REBUILT
- 22. ALL YOUR THINGSARE DISPOSABLE (treat your servers like cattle, not pets)
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. PIPELINES TO MANAGECHANGES DEV QA PROD
- 31.
- 32. ALTERNATIVE CHANGE STRATEGIES Immutableservers Make changes by rebuilding servers Phoenix servers Burning down servers at regular intervals to avoid configuration drift Containerized services Make changes by building and deploying new containers
- 33. AUTOMATED INFRASTRUCTURE TESTING •Syntax validation/Linting • Provider specific tests for verifying resources setup testing ex. AWSpec tests for AWS infrastructure • Integration and compliance tests for the infrastructure. ex. InSpec tests along with CIS profiles for compliance
- 34.
- 35. EXAMPLE 1 Single Application/ environment
- 36.
- 37.
- 38. EXAMPLE 2 Server imagesas a service
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46. DESIGN PATTERNS Avoid monolithicinfrastructure
- 47.
- 48.
- 49.
- 50.
- 51. AWS region Availability zone2Availabilityzone1 Availability zone3 Public subnet-1a Private subnet-1cPrivate subnet-1b Private subnet-1a Public subnet-1b Public subnet-1c EC2 instances EC2 instances EC2 instances VPC NAT gateway Auto Scaling Auto Scaling Auto Scaling Auto Scaling Bastion (Jumpbox) IGW router
- 52.
Editor's Notes
- #12 Between 2016 to 2017, the gap for frequency of code deployments narrowed: High performers are still shipping code as the business demands, while low performers went from shipping between once per month and once every six months in 2016, to shipping between once per week and once per month in 2017. Low performers in 2017 have also reduced their lead time for changes: from between one month and six months in 2016 to between one week and one month. This change does not mean that high performers are no longer performing as well. It simply means that low performers are doing better with throughput than they were, on average, and we applaud them for this improvement. In contrast, high performers have gained an even greater advantage over the past year when it comes to recovering from production and infrastructure outages, and preventing failures in the first place. This is likely giving them an advantage in delighting their customers, because they have many more chances to deliver new value, and what they release is of higher quality. The result is faster time to market, better customer experience, and higher responsiveness to market changes.