Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

DevOps and the Death & Rebirth of Childhood Innocence

121 vues

Publié le

My closing keynote presentation from the 2018 DevOpsPro Moscow event.

Publié dans : Technologie
  • Soyez le premier à commenter

DevOps and the Death & Rebirth of Childhood Innocence

  1. 1. Platform.sh, Moscow, November 15, 2018 DevOps & the Death and Rebirth of Childhood Innocence Robert Douglass, Chief DevRel Officer, Platform.sh @robertDouglass
  2. 2. Rob’s First Law of Coder Dynamics
  3. 3. Problem
  4. 4. Solution?
  5. 5. Solution? Logic path
  6. 6. Solution?
  7. 7. Safe zone Danger zone
  8. 8. DOWNLOAD ALL THE THINGS!
  9. 9. Part I: Developers
  10. 10. In the beginning…
  11. 11. In the beginning… computers were toys.
  12. 12. We played with them.
  13. 13. https://www.behance.net/gallery/3923327/Internet-History-Infographic
  14. 14. In the beginning…
  15. 15. In the beginning… deploying code was fun.
  16. 16. All of the keywords in C64 BASIC
  17. 17. Problem
  18. 18. Solution?
  19. 19. Goal
  20. 20. Part II: SysAdmins
  21. 21. Source: Carlos León, yesterday’s talk
  22. 22. Source: Carlos León, yesterday’s talk
  23. 23. "Why should you (a DevOps person) be the one who fixes someone else's code running in production?" Carlos León, Adopting DevOps: Are You Still on Time?
  24. 24. Jenkins Ansible Docker Kubernetes
  25. 25. Part III: The Death of Childhood Innocence
  26. 26. Equifax is disaster of such epic proportions that their brand now looks like this:
  27. 27. Equifax is a clusterfuck of such epic propotions it is not an easy subject
  28. 28. We will look at just two of the epic moments of this saga. 1. The infamous CVE-2017-5638
  29. 29. At $4,000,000,000 this person is worth way more than Steve Austin who is currently worth $29,791,399* *adjusted for inflation since 1974.
  30. 30. What was the salary of the person who has the manual/menial job of “update this package” ?
  31. 31. “Equifax CEO Richard Smith Who Oversaw Breach to Collect $90 Million” http://fortune.com/2017/09/26/equifax-ceo-richard-smith-net-worth/
  32. 32. Who done it? Was this a fault of Gary, the developer who didn’t apply the patch? Was this the fault of his manager Diane? I posit this was the fault of faulty thinking about software.
  33. 33. Software is a function of time.
  34. 34. ● Over time two things happen to software: ○ Creating new stuff ○ Repairing broken stuff Software is a function of time.
  35. 35. Creating new stuff is voluntary. You do it on your own rhythm. The better automation you have the faster and more productive you will be. The better your tests are … the less you will suffer from quality degradation and rot. Software is a function of time.
  36. 36. Repairing broken stuff is not on your own rhythm. The fix for CVE-2017-5638 should have been deployed an hour after it was out. Software is a function of time.
  37. 37. We will look at just two of the epic moments of this saga. 1. The infamous CVE-2017-5638 2. The brilliant, flawless response on the part of Equifax
  38. 38. No. It wasn’t this. That would be semi-competent.
  39. 39. Is it Diane or Gary’s fault again? No. It is about snowflakes. When infrastructure is done by hand you need a “change request form”.
  40. 40. There is no way in hell a “mature enterprise” will have procedures that are lightweight enough to roll- out a full new project in a day. If you need to go through IT and Security. If you need to fill a form.
  41. 41. In an emergency someone will “power through”. And when that happens, you can get Equifaxed.
  42. 42. And when you get Equifaxed….
  43. 43. Part IV: The Rebirth of Childhood Innocence
  44. 44. 2018-11-14 “Adopt a Dev-Centric Position” Gil Zellner, From Ops to Dev and Back Again
  45. 45. ✤deploy by git push or git merge. This triggers the entire process. Note that this is NOT “ssh into the server and git pull”
  46. 46. “Make release management a functional practice instead of a technical one” Rene van Osnabrugge, Continuous Delivery 3.0 – the Next Step
  47. 47. ✤Your system (code / applications / services) has a build process. Embrace that fact and standardize it for every member of the team.
  48. 48. ✤ Alway test against real data. Use copy-on-write technologies (eg. CEPH) to make production data available for every test environment.
  49. 49. ✤Every build should have a testable URL that you can send to stakeholders.
  50. 50. “Create feedback loops to improve communication, Involve stakeholders and management” Mieke Deenen, Get Started with DevOps for Government
  51. 51. ✤ Built code should be put onto a read-only file system. Your operating system should be put onto a read-only file system. The only writable volumes should be protected from program execution. Many applications violate this but there are workarounds.
  52. 52. ✤ Read-only file systems lead to disposable containers. Containers should be built, used, then thrown away. Don’t update containers. Don’t maintain containers. Rebuild them and replace them.
  53. 53. “Think immutable - build your infrastructures from code” Rene van Osnabrugge, Continuous Delivery 3.0 – the Next Step
  54. 54. ✤ Developers should have some (but not total) control over the services and environment. For example: runtime versions configuration of services that affect the application nginx redirects / rewrites extensions, libraries, and dependencies
  55. 55. ✤Variables that change per-environment should be injected into the running application.
  56. 56. “If you're running your application in a Docker container, you want to configure that from the outside.” Patrick Baumgartner, Demystifying Spring Boot Magic
  57. 57. ✤Sensitive data (keys, tokens) should also be injected into the running application.
  58. 58. "You don't want sensitive information in your configuration files" Benny Michielsen, Secure Multi-tenant Apps with Azure and VSTS
  59. 59. ✤Deploy and test every git branch in isolation.
  60. 60. ✤ Deploy all applications and services in the same way. Your Node.js app shouldn’t have a fundamentally different deployment process than your Python app.
  61. 61. ✤ Make it easy - automatic! - to practice database migrations. Test them on every deploy.
  62. 62. ✤ Deployments should be optimized for protecting data consistency, but this may come at a price: downtime.
  63. 63. ✤Feature toggles are a hack. Don’t do them. Unless there’s no other way.
  64. 64. ✤ If you have to do database migrations that take a longer time or will lead to downtime, you should have seen Michiel Rook’s session yesterday. Michiel Rook Database Schema Migrations with Zero Downtime
  65. 65. ✤ If you have to do your own container orchestration, use Kubernetes.
  66. 66. ✤ We are betting on Kubernetes for everything. Kubernetes is the defacto standard now. Carlos Sanchez (Cloudbees) Using Kubernetes for Continuous Integration and Continuous Delivery
  67. 67. Jenkins Ansible Docker Kubernetes Your Goal
  68. 68. @platformsh CONTINUOUS DEPLOYMENT CLOUD HOSTING
  69. 69. Moscow, November 15, 2018 DevOps & the Death and Rebirth of Childhood Innocence Robert Douglass, Chief DevRel Officer, Platform.sh @robertDouglass

×