Accelerate your Application Delivery with DevOps and Microservices

©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