Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

State of Infrastructure as Code - AutomaCon 2016

3 815 vues

Publié le

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.

Publié dans : Logiciels
  • Identifiez-vous pour voir les commentaires

State of Infrastructure as Code - AutomaCon 2016

  1. 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. 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. 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. 4. https://secure.flickr.com/photos/mgifford/4525333972
  5. 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. 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. 7. What “infrastructure”? AWS Resources Operating System and Host Configuration Application Configuration
  8. 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. 9. allOfThis == $Code https://secure.flickr.com/photos/wscullin/3770015991
  10. 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. 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. 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. 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. 14. Release processes levels Source Build Test Production Continuous integration Continuous delivery Continuous deployment
  15. 15. Release processes levels Source Build Test Production Continuous deployment Continuous integration Continuous delivery
  16. 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. 17. Infrastructure as Code “tiers” AWS Resources Operating System and Host Configuration Application Configuration
  18. 18. Infrastructure as Code “tiers” AWS Resources Operating System and Host Configuration Application Configuration AWS CloudFormation Hashicorp Terraform
  19. 19. Infrastructure as Code “tiers” AWS Resources Operating System and Host Configuration Application Configuration Ansible Chef Puppet Salt
  20. 20. AWS Resources Operating System and Host Configuration Application Configuration AWS CodeDeploy Container frameworks #serverless frameworks Infrastructure as Code “tiers” Swagger
  21. 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. 22. Sounds easy! https://secure.flickr.com/photos/macwagen/94975613
  23. 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. 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. 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. 26. The “red line” AWS Resources Operating System and Host Configuration Application Configuration Dev Ops What Operations really wants.
  27. 27. The “red line” AWS Resources Operating System and Host Configuration Application Configuration Dev What Development really wants. Ops
  28. 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. 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. 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. 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. 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. 33. aws.amazon.com/devops
  34. 34. AWS DevOps Blog
  35. 35. Chris Munns munns@amazon.com @chrismunnshttps://www.flickr.com/photos/theredproject/3302110152/
  36. 36. ? https://secure.flickr.com/photos/dullhunk/202872717/

×