AWS DevOps Session

aws_devops.md

What is DevOps?

1. Cultural Philosophy

• Tearing down barriers
• Enable the smart people to make smart decisions
• Assigning ownership, accountability, responsibility to people doing the work
• Reducing responsibility to the most directly involved individuals
• Increase visibility to the big picture and the results of work being done

2. Practices

• Continuous Integration
• Continuous Delivery
• Infrastructure as Code
• Self-service environments
• Microservices

3. Tools

• Automated development pipeline tooling
• Consistent and predictable application management & configuration management tools
• Consistent infrastructure measurement tools
• Security analysis and management tools

Tearing down the wall between:

• Developers and Operations
• Devs and Ops and QA
• Devs and Ops and QA and Security
• etc.

DevOps == efficiencies that speed up this lifecycle

Monolith to Microservices

• Single-purpose
• Connect only through APIs
• Connect over HTTPS
• Largely "black boxes" to each other
• "Microservices"

Monolithic vs. SOA vs. Microservices

• Monolithic => Single Unit
• SOA => Coarse-grained
• Microservices => Fine-grained

Microservices vs. SOA

• Many very small components vs. Fewer more sophisticated components
• Business logic lives inside of single service domain vs. Business logic can live across domains
• Simple wire protocols (HTTP with XML/JSON) vs. Enterprise Service Bus like layers between services
• API driven with SDKs/Cilents vs. Middle ware

Two-pizza teams

• Full ownership
• Full accountability
• Aligned incentives
• "DevOps"

How do Two Pizza Teams work?

• We call of "Service teams"
• Own the "primitives" they build:
  • product planning (roadmap)
  • development work
  • Operational/Client support work
• You build it, you run it
• Part of a larger concentrated org (Amazon.com, AWS, Prime, etc.)

Who does QA? The Two Pizza Team

Who Does On Call? The Two Pizza Team

What does Ops do? Not Exist

What about Ops/QA/Etc?

Everyone exists on a "service team" focused on their primitive(s):

• SDE's focused on developing
• PM's focused on product direction
• TPM's help drive development
• SE's focused on infra/tooling
• SDET's focused on test excellence throughout the organization Some folks are shared across the org, some on individual teams

Boy, that sounds like a lot of freedom?

It is! Teams are empowered and also held to high standards:

• Thorough onboarding/training

• Patterns/practices defined at scale (with 20+ years of org knowledge)

• Regular technical and business metric reviews

• Regular sharing of new tools, services, technologies, etc, by internal subject matter experts

• Self-service

• Technology-agnostic

• Encourage best practices

• Single-purpose services

• Deployment service

• No downtime deployments

• Health checking

• Versioned artifacts and rollbacks

• Continuous delivery

• From check-in to production

• Automated actions and transitions

• 90% of teams

Thousands of teams

• Microservice architecture
• Continuous delivery
• Multiple environments
• 50 million deployments a year (2014)

5 Key technology areas to focus on:

• Continuous Integration/Delivery
• Infrastructure as Code
• Monitoring/Metrics/Loging/APM
• APIs/Microservices Management
• Communication & Collaboration

Q&A

Q. Service definition - how is each service defined (e.g. boundaries so that no 2 services overlap) A. bottom up with a special case of creating new teams when 2 teams try to solve the same problem