Organizations around the globe are leveraging the cloud to accomplish world-changing missions. This session will address how AWS can help organizations put more money toward their mission and scale outreach and operations to achieve more with less. Hear some of the most advanced AWS customers on how their organizations handle DevOps, continuous integration, and deployment. Learn how these practices allow them to rapidly develop, iterate, test, and deploy highly scalable web applications and core operational systems on AWS. The discussion will focus on best practices, lessons learned, and the specific technologies and services these customers use.
4. What is DevOps?
• « DevOps is the practice of operations
and development engineers participating
together in the entire service lifecycle,
from design through the development
process to production support »
- theagileadmin.com
6. What is Continuous Integration?
• Changes to code automatically deployed
to mainline branch
– After passing unit and mock tests
• Makes changes to code, and deployments
iterative, not monolithic
• Bugs are detected quickly
• Helps automate deployments
• Allows rapid development and deployment
26. 11.6s
Mean time
between
deployments
(weekday)
1,079
Max number of
deployments in a
single hour
10,000
Mean number of
hosts
simultaneously
receiving a
deployment
30,000
Max number of
hosts
simultaneously
receiving a
deployment
DEPLOYMENTS AT
AMAZON.COM
(in 2011)
37. DevOps@edX
A report from the frontline of an evolving and, hopefully,
continuously improving DevOps organization,
July, 2015
38. *
About edX
‣ Created in May, 2012 by Harvard and MIT
‣ More than 4 million students from every country
‣ More than 12 million course enrollments
‣ 65 prestigious member institutions from around the world
39. *
Our Vision
To democratize and reimagine education by increasing worldwide educational
access and create a culture of continuous, lifelong learning.
Anyone, anywhere with a desire to learn and an Internet connection can take
quality online courses.
41. *
edX on AWS
How we use AWS
‣ Deployed on AWS since the beginning
‣ Use many AWS services, but especially
‣ EC2
‣ RDS
‣ S3
‣ Cloudfront
‣ EMR
‣ Everything in the VPC
‣ Tend to be early adopters
‣ AWS Marketplace image in partnership with Bitnami
42. *
edX on AWS
Why we value AWS
‣ Breadth of offering
‣ Pay-for-what-you-use
‣ “Elastic” everywhere; scales-up and scales-down
‣ A continuum of options from “bare metal” to Elastic Beanstalk
‣ Few tie-ins
‣ Global footprint
43. *
What the hell have you built?
With apologies to @codinghorror
46. **
Why
‣ We need to deploy services quickly and consistently
‣ Relationships between services are complex
‣ Each additional service adds incremental operational complexity
Infrastructure as Code
51. **
Cloud Migrator Design goals:
‣ Ease of adding new services
‣ Minimal additional configuration per service required
‣ Flexible per service configuration supported
‣ Idempotent
‣ D.R.Y.
Infrastructure as Code
52. **
What Cloud Migrator descriptors look like:
‣ yaml
‣ Minimally specify
‣ tags
‣ ports
‣ service CIDR blocks
‣ Anything can be overridden
‣ Easy to extend
Infrastructure as Code
55. **
Immutable Infrastructure
Why
‣ Traceability, everything in SCM
‣ Pull request workflow
‣ Strong consistency guarantees with identical, tested artifacts
‣ Dead simple auto-scaling
‣ Clear path to automation
56. **
Immutable Infrastructure
How
‣ Our deployment artifacts are pre-baked AMIs
‣ Several versions of application software and config converge to produce our
AMIs
‣ Another homegrown tool, Abbey, builds AMIs
‣ Abbey leverages our configuration management tool of choice, Ansible
57. **
An Aside: Why Ansible
‣ We appreciate its simplicity
‣ It’s built on tried and true tools like SSH
‣ Dynamic inventories using cloud-friendly selectors like tags
‣ It is agentless
‣ We are heavily invested in Python