• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction to DevOps
 

Introduction to DevOps

on

  • 945 views

What is DevOps ?

What is DevOps ?
What it can bring ?
Why and How the web giants put these concepts into practice ?
How to implement DevOps in your IT dept ?

Statistics

Views

Total Views
945
Views on SlideShare
927
Embed Views
18

Actions

Likes
8
Downloads
0
Comments
0

2 Embeds 18

http://www.prod.pilotsystems.net 17
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

Introduction to DevOps Introduction to DevOps Presentation Transcript

  • INTRODUCTION TO DEVOPS Mathieu DESPRIEE! mde@octo.com! © OCTO 2013 Rua Funchal 411/5°Andar Vila Olímpia - São Paulo - Brasil Tel : (011) 3468.0103 www.octo.com 1
  • ~# devops -? 2
  • What the management asks 3
  • A better TTM (Time To Market) ! Faster from business idea to production ! Faster to evolve the systems, the technology ! … while keeping a HIGH level of quality, stability, availability, operability 4
  • Why is it difficult ? 5
  • Local goals are divergent DevOps   «  wall  of  confusion  »   Local  goals   Local  culture   Deliver  new  features   (of  good  quality)   Guarantee  the  run  of  so;ware   (stability)   Product  oriented   Service  oriented   (supervision,  backups,   provisioning…)   Try  to  innovate   Try  to  raBonalize   6
  • Activities, on Ops side §  47%  of  total  Bme  is  dedicated  to   deployment   §  Doing  the  deployment   §  Fixing  problems  related  to  deployments   §  InteresBng  KPI  to  follow…   7
  • How the web giants perform in this? 8
  • ! ! ! 800 dev, 400 ops, 180’000 servers (= 450 servers / ops) 1 deployment each day Concept of deployment rings ! ! A deployment somewhere in datacenters every 11 seconds At any moment, an average of 10’000 servers are being updated ! ! Everything is in the cloud (AWS) « Design For Failure » : !   the software is designed to tolerate ! they test it all the time, in production. !   65’000 failure tests, in production, by killing random virtual machine !!! … and measuring that everything is alright ! ! 10 deployments / day 9
  • Why and how they do this ? 10
  • DevOps   1.  Infrastructure  as  Code   2.  ConBnuous  Delivery   3.  CollaboraBon   11
  • { infrastructure, as, code } 12
  • ! Because humans make mistakes ! Because human brain is terribly bad at repetitive tasks ! Because human is slow compared to a bash script ! … and because we are humans 13
  • 14
  • Command and Control Configuration Application Orchestration •  deploy applicative code •  … and rollback ! •  deploy database scripts and data •  start application •  join clusters… System Configuration •  jvm, application servers… •  middlewares… •  service configuration (logs, ports, user and group permissions) •  registration to supervision Capistrano Custom shell scripts ... Chef Puppet CFEngine … OpenStack Bootstrapping •  •  VM Instantiation OS setup & configuration Vmware vCloud Oracle exaLogic or physical machine config … 15
  • Command and Control Configuration Application Orchestration •  deploy applicative code •  … and rollback ! •  deploy database scripts and data •  start application •  join clusters… System Configuration •  jvm, application servers… •  middlewares… •  service configuration (logs, ports, user and group permissions) •  registration to supervision Capistrano Custom shell scripts ... Chef Puppet CFEngine … OpenStack Bootstrapping •  •  VM Instantiation OS setup & configuration Vmware vCloud Oracle exaLogic or physical machine config … 16
  • Command and Control Configuration Application Orchestration •  deploy applicative code •  … and rollback ! •  deploy database scripts and data •  start application •  join clusters… System Configuration •  jvm, application servers… •  middlewares… •  service configuration (logs, ports, user and group permissions) •  registration to supervision Capistrano Custom shell scripts ... Chef Puppet CFEngine … OpenStack Bootstrapping •  •  VM Instantiation OS setup & configuration Vmware vCloud Oracle exaLogic or physical machine config … 17
  • Capistrano ! Consider all of this like code Custom shell scripts ... ! This can be stored and versioned in a code repository (like git) Chef ! ! Like software code, you can test it. And make sure your script won’t fail when you need it at 2:00 am Can scale to any number of server in parallel… Puppet CFEngine … OpenStack Vmware vCloud Oracle exaLogic or physical machine config … 18
  • Infrastructure as Code ! Benefits of « Infrastructure as Code » !   REPETABILITY and RELIABILITY ! Guarantee that infrastructure is homogeneous ! Make sure that standards are respected ! Any new environment is configured quicker ! Allow developers to do lots of tasks by themselves ! eg. in qualification environment 19
  • continuous.delivery() 20
  • ! ! ! 800 dev, 400 ops, 180’000 servers (= 450 servers / ops) 1 deployment each day Concept of deployment rings ! ! A deployment somewhere in datacenters every 11 seconds At any moment, an average of 10’000 servers are being updated ! ! Everything is in the cloud (AWS) « Design For Failure » : !   the software is designed to tolerate ! they test it all the time, in production. !   65’000 failure tests, in production, by killing random virtual machine !!! … and measuring that everything is alright ! ! 10 deployments / day 21
  • Why ? 22
  • Why deploy continuously ? ! ! Improve Time To Market Learn Faster IDEAS (and it needs metrics !) LEARN FAST DATA CODE FAST CODE MEASURE FAST 23
  • Why deploy continuously ? ! ! Improve Time To Market Learn Faster (and it needs metrics !) ! Deploy frequently = automation = reliability 24
  • Why deploy continuously ? ! ! Improve Time To Market Learn Faster (and it needs metrics !) ! Deploy frequently = automation = reliability ! Deploy more frequently = smaller code change = incidents are smaller = lower TTR (Time To Repair) 25
  • OK, let’s do that ! …oh, wait… 26
  • What you need : ! Continuous integration ! TDD - Test Driven Development (automated unit testing) ! Code reviews ! Continuous code auditing (sonar…) ! Functional test automation ! Strong non-functional tests (performance, availability…) ! Automated packaging and deployment, independent of target environment 27
  • You may also need ! Feature flipping / Feature toggles Feature flipping allows to enable / disable a feature while software is running 28
  • You may also need Dark Launch @ Facebook : ! Feature flipping / Feature toggles Dark launching is releasing a new feature, with no UI changes, but using all the parts of your infrastructure involved in serving that feature. ! Dark Launch A good strategy to apply when you're dealing with massive, large-scale deployments, and when you want to see how your infrastructure behaves in conditions that are as close to production as possible 29
  • Canary Release You may also need ! Feature flipping / Feature toggles Users   ! Dark Launch Router ! Canary Release Most of users Version N Subset of users Version N+1 30
  • Blue/Green deployment You may also need ! Feature flipping / Feature toggles ! Dark Launch Web server App server DB server ! Canary Release ! Blue/Green deployment Router Users   31
  • You may also need Datamodel evolution strategy example ! Feature flipping / Feature toggles ! Dark Launch Deploy application compatible with N and N+1 ! Canary Release ! Blue/Green deployment ! Datamodel evolution strategies DB Prepare hybrid datamodel : version N with N+1 things CREATE TABLE ADD COLUMN DB Remove old things Datamodel = version N+1 DROP TABLE DROP COLUMN 32
  • Datamodel evolution strategy example Datamodel Version N Datamodel Version N V.1 Datamodel Version N+1 Hybrid V.1 + V.2 Datamodel Version N+1 V.2 33
  • [ collab oration ] 34
  • 35
  • Development process Business   Tester   End-­‐user     funcBonal  tests   (automated)   FuncBonal  requirements   PriorizaBon   Development   So;ware   36
  • Ops are the others users of the system Business   Tester   End-­‐user     funcBonal  tests   (automated)   FuncBonal  requirements   PriorizaBon   Development   So;ware   Ops   37
  • Ops must be involved in all the phases of a project Business   Tester   End-­‐user     funcBonal  tests   (automated)   -­‐  FuncBonal  requirements   -­‐  Non  funcBonal  requirements   (useful  logs,  degraded  modes,  redo   operaBons,  integraBon  to   supervision,  performance,  easiness   of  deployment)   So;ware   PriorizaBon   Development   non-­‐funcBonal   tests   (automated)   Ops   Manager   Ops   Ops   38
  • Share the tools Ops   Dev   -­‐  Binary  repositories   -­‐  ConBnuous  integraBon   -­‐  Facilitate  /  Automate  deployment   -­‐  Help  dev  teams  to  become  autonomous  (in   parBcular  for  deployment  before  producBon)   -­‐  Facilitate  diagnosBcs   -­‐  Get  devs  interested  in  «  prod  things  »   -­‐  Give  access  to  logs   -­‐  Give  access  to  supervision   and  monitoring   39
  • Des outils partagés, qui facilitent les interactions Get  devs  interested  in   «  prod  things  »       3.   COLLABORATIO N   (culture,  organisaBon…)   40
  • Work together Architecture  reviews   align  people  on  objecBves   Post  Mortem   idenBfy  root  causes,  without   blaming  people   improve  the  way  you  work   Day-­‐to-­‐day     share  informaBon   ReporBng     Go  /  NoGo   communicate  about  how  the   system  works   anBcipate  problems   decision  to  go  in  producBon   should  be  a  shared  decision   (markeBng,  dev,  ops,…)   41
  • wrap_up 42
  • tools   for  collaboraBon,   measurement,  quality   management,  automaBon   architectures   adapted  to  funcBonal  AND   non-­‐funcBonal  requirements   a  set  of  pracBces  that  aim  at  improving   collaboraBon  between  dev  and  ops   culture  and  organizaBon   to  ease  collaboraBon   methodology   for  collaboraBon,  trust,  and   conBnuous  improvement   43
  • Infrastructure as Code Continuous Delivery Collaboration •  Automate everything •  Focus on Reliability and Repetability •  Deploy more often •  Reduce Time To Repair •  Need strong investment in software quality •  Organise work together •  Share tools •  Build trust, avoid blaming 44
  • web giants devops 45
  • How to implement DevOps ? And how OCTO can help you 46
  • Progressive implementation Improve Quality of Service Continuous Improvement Culture of collaboration Speed-up the provisioning Infrastructure as Code Improve deployment reliability We  advocate  for  a   progressive  and  iteraBve   implementaBon,  adopBng   the  principles  of  conBnuous   improvement  from  the  lean   management   Continuous Delivery Improve Time-To-Market Improve Mean Time To Recover (MTTR) 47
  • Diagnostic : Where are you ? Example of an evaluation matrix we use : tooling, processes, architecture, organization, overall performance… 48
  • OCTO Services Offers Directors   Talks & Seminars •  “Evangelisation” Diagnostics & Evaluation •  DevOps Maturity •  Organizational Audit •  Practices Audit Managers   Architects     (so;  &  infra)   Devs   Ops   Architecture studies •  DevOps patterns (Dark Launch...) •  Software Delivery pipeline •  Deployment architecture Coaching •  State of the art practices (XP, TDD, test for ops) •  Agile/Kanban for ops •  Animation/Facilitation Expertise : Technical Assistance & Training •  Continuous Delivery platform setup •  Infrastructure as Code (vagrant, chef, cap...) 49
  • © OCTO 2013 Rua Funchal 411/5°Andar Vila Olímpia - São Paulo - Brasil Tel : (011) 3468.0103 www.octo.com 50