Embed Size (px)
Citation preview
©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
Accelerate Application Delivery with DevOps and Microservices
Shaun Norris – Head of Solu2ons Architecture -‐ ASEAN
Accelerate Applica2on Delivery with DevOps and Microservices
Shaun Norris – Head of Solu2ons Architecture -‐ ASEAN @shaunnorris
© 2015 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
DevOps buzzword or brainwave?
MicroServices What are they?
The old way
“Waterfalls are wonderful tourist a1rac3ons. They are spectacularly bad strategies for organizing so<ware development projects.” – Sco@ Ambler
But we use agile!
Dev Test Prod
typical code pipeline
Dev Test Prod
agile in dev
Dev Test Prod
agile in test
Even with agile dev test Configuration drift common
Expensive to replicate environments Manual deployments error prone
dev test prod
infrastructure
Desktops Server Room
Datacenter
dev days test weeks prod
cycle time
dev Semi-‐auto test manual prod
deployments
dev test prod
org
Development
QA Opera2ons
dev test prod
goals
New Features
Up2me
Manual Code deploys
Inevitable Human error
Change Control
slows future deployments
New Feature backlog increases
Large risky deployments
produc2on opera2ons as bo@leneck
Typical scaling challenges Am I deploying this code correctly? Worked fine in dev / my laptop / test
What do these logs mean? Who’s on call?
DevOps How is it different?
© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
“The tradi+onal model is that you take your so4ware to the wall that separates development and opera+ons, and throw it over and then forget about it. Not at Amazon. You build it, you run it.” – Dr. Werner Vogels -‐ 2006
dev test prod
You build it, you run it
DevOps
Feedback
Inputs to DevOps Org and culture
Microservices
Relentless automation Feedback loops
Infrastructure as code
Conway’s Law Org and culture matter
"Any organiza3on that designs a system will inevitably produce a design whose structure is a copy of the organiza3on's communica3on structure.” -‐-‐Melvin Conway in 1968
Networking team
OS team
Database team
Development Team
Serviceteam
Service team
Service team
Service team
Scaling your org Start with customers, work backwards
Adopt ‘You build it, you run it’ Hire full stack developers
Use two pizza teams Hire for attitude, teach skills
Automate everything Unit, functional, load and security testing
Infrastructure deployments and scaling
Continuous build and integration
Log analysis and production feedback
Automation Ideas
Chef, Puppet, CloudForma2on, Opsworks
Jenkins, Electric Cloud, Scriptrock
splunk, SumoLogic, Loggly, DataDog, elas2csearch + kibana
Automation tips Test Earlier
Use containers Adopt CI/CD
Infrastructure as code no ssh in production!
© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc. Feedback Loops
Log Everything Storage has never cost less
Analyze later
Analyze now
Data > intuition
Assumptions Sometimes wrong
Learn More
Sign up Now
Learn More
Sign up Now
+18%
speech video
still photo
speech video
still photo
-‐30%
$75m In additional fund-raising
Infrastructure as code
API driven infrastructure
Design for failure
Required for full automa2on
Requires coding skills
Immutable infrastructure
Monolith Microservices
h@p://mar2nfowler.com/ar2cles/microservices.html
Are monoliths that bad? Code all in one place Exis2ng tools all work
Easy tes2ng – everything in one place Package/deploy in a single archive
Shared libs promte DRY and sharing across teams
Monolith #fail As team grows, Big ball of Mud likely! Every change requires full deploy
CI/CD 2me to build grows as project grows Whole team must share/agree on same tech stack
App features tend to be 2ghtly coupled
What are Microservices? Code that does ONE thing well
Includes all levels of stack incl. infra Published interface vs. private implementa2on Lightweight comms to ROW – usually HTTP/REST
Loose coupling to other services
h@p://mar2nfowler.com/ar2cles/microservices.html
Loose Coupling Services should be independently deployable
Don’t share databases across services Interservice comms via API only
PUB/SUB models and queues help Scale each service independently
Smaller blast radius = higher availability
Why Microservices? Smaller, easier codebase(s)
Faster startup, faster builds – helps with CI/CD Each service can scale independently – cost savings!
Limit blast radius on failure Faster, parallel innova2on
Dev teams choose their own tools
Why not? Trade app for ops complexity
Distributed systems are hard (CAP theorem) Choosing service boundaries can be tough May break DRY (duplica2on of effort)
Tes2ng becomes more complex Learning curve for Dev + Ops
Inputs to DevOps Org and culture
Microservices
Relentless automa2on Feedback loops
Infrastructure as code
Expected Outputs? Shorter cycle 2mes
Faster pace of innova2on Security + Reliability + Availability + Performance
2014 DevOps Survey Strong IT performance is a compe22ve advantage
DevOps prac2ces improve IT performance Organiza2onal culture ma@ers
Job sa2sfac2on is the No. 1 predictor of organiza2onal performance
h@ps://puppetlabs.com/sites/default/files/2014-‐state-‐of-‐devops-‐report.pdf
Could you release every
11.6 seconds?
(2011)
h@ps://youtu.be/dxk8b9rSKOo
Reminder DevOps is not a job title
DevOps is not a tool or toolset
Thank You!
Shaun Norris – Head of Solu2ons Architecture -‐ ASEAN @shaunnorris
