© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Chris Munns, Business Development Manager – AWS DevOps
DevOps on AWS:Accelerating Software Delivery with the
AWS Developer Tools
November 30, 2016
DEV201
Software moves faster today
Software creation and distribution is
easier and faster than ever:
• Startups can now take on giants with little to
no funding ahead of time
• Getting your software into the hands of
millions is a download away
• Your ability to move fast is paramount to your
ability to fight off disruption
Old software delivery model
The software delivery model has drastically changed
New software delivery model
What tools do you need to move fast?
Releasing software in this new software-driven world
requires a number of tools:
• Tools to manage the flow of your software development
release process
• Tools to properly test and inspect your code for defects
and potential issues
• Tools to deploy your applications
First, we need to
understand a little bit
about software release
processes
https://www.flickr.com/photos/jurvetson/5201796697/
• Integration
tests with
other systems
• Load testing
• UI tests
• Penetration
testing
Release processes have four major phases
Source Build Test Production
• Check-in
source code
such as .java
files.
• Peer review
new code
• Compile code
• Unit tests
• Style checkers
• Code metrics
• Create
container
images
• Deployment
to production
environments
Release processes levels
Source Build Test Production
Continuous integration
Continuous delivery
Continuous deployment
We move pretty fast at Amazon:
In 2014:
• Thousands of service teams across Amazon
• + Building microservices
• + Practicing continuous delivery
• + Many environments (staging, beta, production,
multiple regions)
=50 million deploys
DevOps: Culture + Practices + Tools
Each 2-pizza team “owns” their
product:
• Creates product (software
typically)
• Handles Q/A of that product
• Responds to issues, is on-call
• “you build it, you run it”
• Supports service & tracks/goals
against business and technical
metrics
https://secure.flickr.com/photos/lox/9408028555
DevOps: Culture + Practices + Tools
Each 2-pizza team’s practices
largely open so far as standards are
met:
• Agile? Scrum? Daily standups?
Weekly? None? Whatever you
works for your team!
• No centralized change
management
board/team/approval, but tools
that require a degree of sign-
off/process review
https://secure.flickr.com/photos/lox/9408028555
DevOps: Culture + Practices + Tools
Each 2-pizza team developers given
a “box of tools”:
• Use these or operationalize your
own:• Time spent on operations is less
time to spend on development
• Less time spent on development
is increased risk of missing goals
• Tools provide “guard rails” that
enforce best/better practices
• Tools maintained by other 2-pizza
teamshttps://secure.flickr.com/photos/lox/9408028555
2-pizza team responsibility Venn diagram
Responsible for
THEIR
PRODUCT
Deployment tools
CI/CD tools
Monitoring tools
Metrics tool
Logging tools
APM tools
Infrastructure provisioning
tools
Security tools
Database management
tools
Testing tools
….
Not responsible for
*
*Unless their product belongs in the blue
We built tools to
automate our software
release process
https://secure.flickr.com/photos/lindseygee/5894617854/
Automated actions and transitions—from check-in to production
Development benefits:
• Faster
• Safer
• Consistent & standardized
• Visualization of the process
Pipelines
Every year we survey our
software developers and in 2014
results found only one
development tool/service could
be correlated statistically with
happier developers:
Our pipelines service!
AWS Code* services
Commit Build Test Production
Third-Party
Tooling
Third-Party
Tooling
Software Release Steps:
AWS Code* services
Commit Build Test Production
AWS CodeDeploy
Software Release Steps:
Amazon EC2 On-Premises
AWS Code* services
Commit Build Test Production
AWS CodeCommit
AWS CodePipeline
AWS CodeDeployThird Party
Tooling
Third Party
Tooling
Software release steps:
Continuous delivery service for fast and
reliable application updates
Model and visualize your software release
process
Builds, tests, and deploys your code every time
there is a code change
Integrates with third-party tools and AWS
AWS CodePipeline
Source
Source
GitHub
Build
JenkinsOnEC2
Jenkins
Deploy
JavaApp
Elastic Beanstalk
PipelineStage
Action
Transition
CodePipeline
MyApplication
Source
Source
GitHub
Build
JenkinsOnEC2
Jenkins
Deploy
JavaApp
Elastic Beanstalk
NotifyDevelopers
Lambda
CodePipeline
MyApplication
Parallel actions
Source
Source
GitHub
Build
JenkinsOnEC2
Jenkins
Deploy
JavaApp
Elastic Beanstalk
NotifyDevelopers
Lambda
TestAPI
Runscope
CodePipeline
MyApplication
Sequential actions
Build
JenkinsOnEC2
Jenkins
Staging-Deploy
JavaApp
Elastic Beanstalk
Prod-Deploy
JavaApp
Elastic Beanstalk
QATeamReview
Manual Approval
CodePipeline
MyApplication
Manual approvalsReview
8. Retrieve build artifact
EC2 instance
CodePipeline
Source
Source
GitHub
Build
JenkinsOnEC2
Jenkins
Deploy
JavaApp
Elastic Beanstalk
Source Artifact
S3
Build Artifact
S3
5. Get source artifact
1. Get changes
6. Store build artifact
3. Poll for job
4. Acknowledge job
7. Put success
9. Deploy build artifact
Elastic Beanstalk
Web container
Java App
MyApplication
AWS service integrations
Source Invoke Logic Deploy
AWS Elastic Beanstalk
Amazon S3 AWS CodeDeployAWS Lambda
AWS CodeCommit
AWS OpsWorks
AWS CloudFormation
Extend AWS CodePipeline using custom actions
Update tickets Provision resources
Update dashboards
Mobile testing
Send notifications Security scan
Building your code
“Building” code typically refers to languages that
require compiled binaries:
• .NET languages: C#, F#, VB.net, etc.
• Java and JVM languages: Java, Scala,
JRuby
• Go
• iOS languages: Swift, Objective-C
We also refer to the process of creating Docker
container images as “building” the image.EC2
No building required!
Many languages don’t require building. These
are considered interpreted languages:
• PHP
• Ruby
• Python
• Node.js
You can just deploy your code!
EC2
Testing your code
Testing is both a science and an art form!
Goals for testing your code:
• Want to confirm desired functionality
• Catch programming syntax errors
• Standardize code patterns and format
• Reduce bugs due to non-desired application
usage and logic failures
• Make applications more secure
Automates code deployments to any instance
Handles the complexity of updating your
applications
Avoid downtime during application deployment
Rollback automatically if failure detected
Deploy to Amazon EC2 or on-premises
servers, in any language and on any operating
system
Integrates with third-party tools and AWS
AWS CodeDeploy
appspec.yml Exampleversion: 0.0os: linuxfiles:
- source: /destination: /var/www/html
permissions:- object: /var/www/html
pattern: “*.html”owner: rootgroup: rootmode: 755
hooks:ApplicationStop:
- location: scripts/deregister_from_elb.shBeforeInstall:
- location: scripts/install_dependencies.shApplicationStart:
- location: scripts/start_httpd.shValidateService:
- location: scripts/test_site.sh- location: scripts/register_with_elb.sh
appspec.yml Exampleversion: 0.0os: linuxfiles:
- source: /destination: /var/www/html
permissions:- object: /var/www/html
pattern: “*.html”owner: rootgroup: rootmode: 755
hooks:ApplicationStop:
- location: scripts/deregister_from_elb.shBeforeInstall:
- location: scripts/install_dependencies.shApplicationStart:
- location: scripts/start_httpd.shValidateService:
- location: scripts/test_site.sh- location: scripts/register_with_elb.sh
• Remove/add instance to ELB
• Install dependency packages
• Start Apache
• Confirm successful deploy
• More!
• Send application files to one
directory and configuration
files to another
• Set specific permissions on
specific directories & files
v2 v2 v2 v2 v2 v2
one at a time
half at a time
all at once
v2 v2 v2 v1 v1 v1
v2 v1 v1 v1 v1 v1 Agent Agent
Dev Deployment group
ORProd Deployment group
Agent
AgentAgent
Agent Agent
Agent
Choose deployment speed and group
Building your application
development release
pipeline
https://www.flickr.com/photos/seattlemunicipalarchives/12504672623/
General best practices used by Amazon developers
• CI/CD is a MUST!
• Commit frequently
• Builds on every commit
• Build once in a given execution flow
• Deploy to a running environment for further testing
General best practices used by Amazon developers
• CI/CD is a MUST!
• Commit frequently
• Builds on every commit
• Build once in a given execution flow
• Deploy to a running environment for further testing
• Everything that is code (application, infrastructure, documentation)
goes into a repository
• If it’s not in a repository, it doesn’t go into production environments!
General best practices used by Amazon developers
• CI/CD is a MUST!
• Commit frequently
• Builds on every commit
• Build once in a given execution flow
• Deploy to a running environment for further testing
• Everything that is code (application, infrastructure, documentation)
goes into a repository
• If it’s not in a repository, it doesn’t go into production environments!
• Start with continuous delivery (“gated” promotion) and build up to
continuous deployment once evidence of a high-level of excellence in
testing is clear
General best practices used by Amazon developers
• CI/CD is a MUST!
• Commit frequently
• Builds on every commit
• Build once in a given execution flow
• Deploy to a running environment for further testing
• Everything that is code (application, infrastructure, documentation)
goes into a repository
• If it’s not in a repository, it doesn’t go into production environments!
• Start with continuous delivery (“gated” promotion) and build up to
continuous deployment once evidence of a high-level of excellence in
testing is clear
• Deploy to canaries, test, deploy to an AZ, test, deploy to a Region,
test
General best practices used by Amazon developers (cont.)
• Code reviews are one of the best mechanisms for “good” code:• Does this code look clean and can someone else understand it?
• Is the design of it meeting the expectations of its needs?
• Are there better/easier ways to do this same thing?
General best practices used by Amazon developers (cont.)
• Code Reviews are one of the best mechanisms for “good” code:• Does this code look clean and can someone else understand it?
• Is the design of it meeting the expectations of its needs?
• Are there better/easier ways to do this same thing?
• Style checkers
• Will someone else in the company be able to update/fix/maintain this code?
General best practices used by Amazon developers (cont.)
• Code Reviews are one of the best mechanisms for “good” code:• Does this code look clean and can someone else understand it?
• Is the design of it meeting the expectations of its needs?
• Are there better/easier ways to do this same thing?
• Style checkers
• Will someone else in the company be able to update/fix/maintain this code?
• Auto-rollbacks can be the quickest recovery mechanism after failure
• Rollback first, then debug what went wrong with logs/graphs/etc.
General best practices used by Amazon developers (cont.)
• Code Reviews are one of the best mechanisms for “good” code:• Does this code look clean and can someone else understand it?
• Is the design of it meeting the expectations of its needs?
• Are there better/easier ways to do this same thing?
• Style checkers
• Will someone else in the company be able to update/fix/maintain this code?
• Auto-rollbacks can be the quickest recovery mechanism after failure
• Rollback first, then debug what went wrong with logs/graphs/etc.
• Thorough dashboards
• What is happening now?
• What does ”normal” look like over some period of time?
• What do I do if this graph looks wrong/an alarm has been triggered?
• What events can I correlate with a move in a graph?
Code* tips and tricks
• All Code* products can (and should) be provisioned and managed
with AWS CloudFormation!
• You could literally store the CloudFormation templates that provision
your Code* resources in CodeCommit and update them via
CodePipeline (It’s like Code* inception!)
• Deep integration with IAM. You can assign permissions on who can
commit code, approve manual approvals, deploy to certain
deployment groups, and more!
• Integrate with AWS Lambda to do almost anything:
• CodeCommit has Repository Triggers
• CodeDeploy has Event Notifications
• CodePipeline has native Lambda invokeAWS CodePipeline AWS CodeDeploy AWS CodeCommit
FIN, ACK
We’ve quickly run through the AWS Code* services today
at a high level and have talked a bit about how we do
things here at Amazon:
• Automate CI & CD to reduce errors from manual testing
and deployment, increase release velocity, and minimize
errors that make it out in front of your users
• Store everything as code
• > 20 talks here at re:Invent about DevOps, so check
them out!
Some of the other DevOps talks this week!
o DEV303 - Deploying and Managing .NET Pipelines and Microsoft Workloads
o DEV310 - DevOps on AWS: Choosing the Right Software Deployment Technique
o DEV313 - Infrastructure Continuous Deployment Using AWS CloudFormation
o DEV403 - DevOps on AWS: Advanced Continuous Delivery Techniques
o SVR307 - Application Lifecycle Management in a Serverless World