At Amazon Web Services, we think about Infrastructure as Code being able to impact not just your low level infrastructure or operating systems but everything from the virtual cement floor of your Amazon Virtual Private Cloud up through the applications your customers interface with. Come take a tour of the space as we see it. Learn what layers there are to managing your infrastructure as code and what services and tools AWS and its Partners exist across these.

1. ©2016, Amazon Web Services, Inc. or its affiliates. All rights reserved
State of Infrastructure as Code
Chris Munns
Amazon Web Services
Business Development Manager - DevOps

2. About me:
Chris Munns - munns@amazon.com, @chrismunns
– Business Development Manager – DevOps
– New Yorker
– Previously:
• AWS Solutions Architect 2011-2014
• Lead of Infrastructure/DevOps @hingeapp
• Formerly on operations teams @Etsy and @Meetup
• Little time at a hedge fund, Xerox and others
– Rochester Institute of Technology: Applied Networking and
Systems Administration ’05
– Internet infrastructure geek

3. Infrastructure as Code is a practice
in which infrastructure is provisioned
and managed using code and
software development techniques,
such as version control and
continuous integration and delivery.

4. https://secure.flickr.com/photos/mgifford/4525333972

5. Why Infrastructure as Code (IaC)?
• We’re managing larger and more sophisticated infrastructures
• With cloud based infrastructure we can easily create, destroy,
modify things that we’d in a physical datacenter infrastructure
touch as infrequently as possible
• Our applications are moving faster, so our infrastructure
needs to move faster
• We’ve realized as a industry that hand-crafted servers belong
best on Etsy and Amazon Handmade, not in our
infrastructures

6. Infrastructure as Code is a practice
in which infrastructure is provisioned
and managed using code and
software development techniques,
such as version control and
continuous integration and delivery.

7. What “infrastructure”?
AWS Resources
Operating System and Host Configuration
Application Configuration

8. AWS Resources
Operating System and
Host Configuration
Application
Configuration
Amazon Virtual Private
Cloud (VPC)
Amazon Elastic Compute
Cloud (EC2)
AWS Identity and Access
Management (IAM)
Amazon Relational
Database Service (RDS)
Amazon Simple Storage
Service (S3)
AWS CodePipeline
Amazon Elastic Load
Balancers (ELB)
…
Windows Registry
Linux Networking
OpenSSH
LDAP
AD Domain Registration
Centralized logging
System Metrics
Deployment agents
Host monitoring
OS based firewalls
Host level security
Container daemons
…
Application dependencies
Application configuration
Service registration
Management scripts
Database credentials
Container task/service
definitions
API specifications
(ie Swagger)
…
What “infrastructure”?

9. allOfThis == $Code
https://secure.flickr.com/photos/wscullin/3770015991

10. Infrastructure as Code is a practice
in which infrastructure is provisioned
and managed using code and
software development techniques,
such as version control and
continuous integration and delivery.

11. Warning: Best Practice Ahead
We version control our application code so we can track
changes, we should be doing the same with our infrastructure
code:
– Improved visibility to changes over time(who, what, when, hopefully
why)
– Who was it that made a change(in so far as the repository is
concerned)
– Can often tie this back to ticketing and project management
systems
– Easier to then have multiple environments and have a true lifecycle
of infrastructure changes
Today this is a surprising gap for many!

12. “Cause if you liked it,
then you shoulda put it
in a repo
Oh, oh, oh, oh, oh, oh”
- Queen Bey (DevOps remix)
https://www.flickr.com/photos/evarinaldiphotography/8513571047/

13. Infrastructure as Code is a practice
in which infrastructure is provisioned
and managed using code and
software development techniques,
such as version control and
continuous integration and
delivery.

14. Release processes levels
Source Build Test Production
Continuous integration
Continuous delivery
Continuous deployment

15. Release processes levels
Source Build Test Production
Continuous deployment
Continuous integration
Continuous delivery

16. Warning: Best Practice Ahead
With agile development practices we are running our application
code through continuous integration and delivery tools and
processes. We should be doing the same for IaC:
– Once code is in a repository, that repository should be hooked up to
a continuous delivery/pipelining tool
– Linting/syntax checks done first
– Functionality at component level checks next
– Integration environment with multiple components checks after that
– Tested at stages such as dev, pre-prod, “princess” for my Etsy
friends, production, etc
– Promote changes between environments after tests past
Emerging trend, currently done by few

17. Infrastructure as Code “tiers”
AWS Resources
Operating System and Host Configuration
Application Configuration

18. Infrastructure as Code “tiers”
AWS Resources
Operating System and Host Configuration
Application Configuration
AWS CloudFormation
Hashicorp Terraform

19. Infrastructure as Code “tiers”
AWS Resources
Operating System and Host Configuration
Application Configuration
Ansible
Chef
Puppet
Salt

20. AWS Resources
Operating System and Host Configuration
Application Configuration
AWS CodeDeploy
Container frameworks
#serverless frameworks
Infrastructure as Code “tiers”
Swagger

21. AWS Resources
Operating System and Host Configuration
Application Configuration
Infrastructure as Code “tiers”
Jfrog Artifactory
PackageCloud
Sonatype Nexus
Language specific public
repositories
Container image registries
Somewhere shared across the top two
tiers are package repositories and
container registries for our applications
and system software

22. Sounds easy!
https://secure.flickr.com/photos/macwagen/94975613

23. AWS Resources
Operating System and Host Configuration
Application Configuration
Infrastructure as Code “tiers”
AWS Elastic Beanstalk
Hashicorp Terraform
Ansible
Chef
Hashicorp Packer
Salt
AWS CloudFormation
AWS OpsWorks
Jfrog Artifactory
PackageCloud
Sonatype Nexus
Amazon CodeDeploy
Container frameworks
#serverless frameworks
The reality is that many of these
tools cross tiers in many ways!
Puppet

24. How do I choose my IaC tools?
• Pick at least one tool specialized in
each tier
• Some multipurpose tools aren’t
great in all areas, for example,
CloudFormation isn’t the best tool
for on-going OS changes, but
OpsWorks is great at that. Use
both!
• Favor tools that make testing them
easier (aka fit in a CI/CD process)
• Most OS configuration management
tools have supporting testing tools
these days
• Find tools that support a balance of
operability and developer flexibility
https://secure.flickr.com/photos/lox/9408028555

25. The red line between Dev & Ops
A big part of DevOps is shifting responsibility, ownership and
accountability between Developers and Operations such that:
• Developers are blocked less by Operations due to automation
and self service tools provided by Ops
• Operations is passing some responsibility up to Developers
requiring them to often be responsible for more application
testing and on-call
This balance can be thought of as a red line that cuts across our
Infrastructure as Code model matching up to a role and
responsibility model.*
*This idea comes from dozens of meetings with large enterprises

26. The “red line”
AWS Resources
Operating System and Host Configuration
Application Configuration
Dev
Ops
What Operations really wants.

27. The “red line”
AWS Resources
Operating System and Host Configuration
Application Configuration
Dev
What Development really wants.
Ops

28. The “red line”
AWS Resources
Operating System and Host Configuration
Application Configuration
Dev
Ops
Traditionally in many organizations Developers are interfacing very high in the
stack due to operations owning most of the stack at/below the application,
being responsible for availability and uptime of almost everything.

29. AWS Resources
Operating System and Host Configuration
Application Configuration
Dev
Ops
The “red line”
With Infrastructure as Code many organizations are looking to move this line
down to here. In this state Developers have full ownership over applications
and Operations is typically providing lower level resources, the OS, and
shared services across the infrastructure

30. The “red line”
AWS Resources
Operating System and Host Configuration
Application Configuration
Dev
Ops
Containers and ”serverless” applications take this lower where the emphasis
is more on the application layer and any orchestration requirements. Below
the line typically represents a highly ”platform as a serviced” infrastructure
operating model for an organization.

31. The “red line”
AWS Resources
Operating System and Host Configuration
Application Configuration
Security, application sensitivity, organization history, staff skills + experience,
adopted technologies, business goals, leadership, and many other factors
play in here for where to determine where the red line will be in your business.
?

32. FIN, ACK
Infrastructure as Code is a practice in which infrastructure
is provisioned and managed using code and software
development techniques, such as version control and
continuous integration and delivery.
– Almost everything about your infrastructure can be treated as
code
– Store all of this code in a revision control system
– Put this code through a continuous delivery pipeline that verifies
code quality and functionality
– “Promote” changes through environments via this pipeline
– Understand where your “red line” needs to be

33. aws.amazon.com/devops

34. AWS DevOps Blog

35. Chris Munns
munns@amazon.com
@chrismunnshttps://www.flickr.com/photos/theredproject/3302110152/

36. ?
https://secure.flickr.com/photos/dullhunk/202872717/