Your SlideShare is downloading. ×
Introduction to DevOps
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction to DevOps

1,209
views

Published on

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 ?

Published in: Technology

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,209
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. ~# devops -? 2
  • 3. What the management asks 3
  • 4. 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
  • 5. Why is it difficult ? 5
  • 6. 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
  • 7. 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
  • 8. How the web giants perform in this? 8
  • 9. ! ! ! 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
  • 10. Why and how they do this ? 10
  • 11. DevOps   1.  Infrastructure  as  Code   2.  ConBnuous  Delivery   3.  CollaboraBon   11
  • 12. { infrastructure, as, code } 12
  • 13. ! 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. 14
  • 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 … 15
  • 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 … 16
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. continuous.delivery() 20
  • 21. ! ! ! 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
  • 22. Why ? 22
  • 23. Why deploy continuously ? ! ! Improve Time To Market Learn Faster IDEAS (and it needs metrics !) LEARN FAST DATA CODE FAST CODE MEASURE FAST 23
  • 24. Why deploy continuously ? ! ! Improve Time To Market Learn Faster (and it needs metrics !) ! Deploy frequently = automation = reliability 24
  • 25. 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
  • 26. OK, let’s do that ! …oh, wait… 26
  • 27. 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
  • 28. You may also need ! Feature flipping / Feature toggles Feature flipping allows to enable / disable a feature while software is running 28
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. [ collab oration ] 34
  • 35. 35
  • 36. Development process Business   Tester   End-­‐user     funcBonal  tests   (automated)   FuncBonal  requirements   PriorizaBon   Development   So;ware   36
  • 37. Ops are the others users of the system Business   Tester   End-­‐user     funcBonal  tests   (automated)   FuncBonal  requirements   PriorizaBon   Development   So;ware   Ops   37
  • 38. 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
  • 39. 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
  • 40. Des outils partagés, qui facilitent les interactions Get  devs  interested  in   «  prod  things  »       3.   COLLABORATIO N   (culture,  organisaBon…)   40
  • 41. 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
  • 42. wrap_up 42
  • 43. 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
  • 44. 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
  • 45. web giants devops 45
  • 46. How to implement DevOps ? And how OCTO can help you 46
  • 47. 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
  • 48. Diagnostic : Where are you ? Example of an evaluation matrix we use : tooling, processes, architecture, organization, overall performance… 48
  • 49. 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
  • 50. © OCTO 2013 Rua Funchal 411/5°Andar Vila Olímpia - São Paulo - Brasil Tel : (011) 3468.0103 www.octo.com 50

×