Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code will come , servers will go but config Management will stay forever

2,653 views

Published on

Talk given about how config management needs to expand beyond servers or server/services. The future is outward facing.
No matter how many abstractions, there will be always something to configure.

Published in: Engineering
  • Hello! High Quality And Affordable Essays For You. Starting at $4.99 per page - Check our website! https://vk.cc/82gJD2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Code will come , servers will go but config Management will stay forever

  1. 1. CODE will COME SERVERS will GO but CONFIG will stay FOREVER @patrickdebois - Small Town Heroes
  2. 2. Things I did (I’m proud of) veewee mccloud
  3. 3. MODERATION
  4. 4. Team of 7 people How do we do it ?
  5. 5. “Backend” services ELB
  6. 6. “Community” services
  7. 7. “IT support” services
  8. 8. Our “Office” services
  9. 9. “Frontend” services
  10. 10. “Mobile” services SNS/Push Cognito
  11. 11. Services #servicefull
  12. 12. servers #serverless
  13. 13. A bit further down the rabbit hole …
  14. 14. Github
  15. 15. undocumented changes to service
  16. 16. limits and unavailable
  17. 17. autoscaling is too slow for peak traffic
  18. 18. service got disabled because of too many bounces
  19. 19. inconsistent behaviour
  20. 20. (almost) NO MAINTENANCE
  21. 21. increased risk when not available
  22. 22. You are an Agent
  23. 23. You make promises to others in the system
  24. 24. Your promises should be verifiable
  25. 25. A promise does not guarantee an outcome
  26. 26. Conditions should be part of your promise
  27. 27. It needs to be clearly documented otherwise it’s not a promise
  28. 28. the language of a promise must be shared
  29. 29. It needs to be mutually agreed (not obligation) otherwise it’s not a promise
  30. 30. You might depend on other agents to keep your promises
  31. 31. Other agents make promises to you
  32. 32. Their promises need to be verifiable clearly documented & mutually agreed (not obligation)
  33. 33. But you can not make promises on behalf of other agents (bottom up vs top down)
  34. 34. Promises can be conflicting in a system
  35. 35. but the conflict can only be from internal promises (as we can not be responsible for others promises)
  36. 36. To keep a promise you should have a choice Push vs Pull
  37. 37. Single Leaves = SPOF To create choice you need to eliminate the single leaves (SPOF)
  38. 38. “Abstraction is selective ignorance” http://en.wikipedia.org/wiki/Andrew_Koenig_(programmer)
  39. 39. All problems in computer science can be solved by another level of abstraction
  40. 40. … except for the problem of too many layers of indirection … David Wheeler (inventor of subroutine)
  41. 41. Every promise binding is the basis for relationship (Dunbar)
  42. 42. Agents with a similar goal can be grouped into a Super Agent
  43. 43. Services
  44. 44. Single Leaves = SPOF You need multiple Super Agents to have a choice again
  45. 45. Forksv1 v2 v3 v1 v2 v3 To keep promises agent can introduce different world views (versions)
  46. 46. Slows down A super agent might get slow internal communication speed is key
  47. 47. Scaling Promises keeping your promise while changing your size (is hard)
  48. 48. container re-use non-deterministic
  49. 49. limits not clear under stress
  50. 50. scale is not always infinite
  51. 51. services devops
  52. 52. Holy Cow!
  53. 53. “I introduced devops and all I got was a remote API”
  54. 54. It’s devops Jim but not as we know it
  55. 55. emerging practices
  56. 56. communicate the status of your promise and monitor others
  57. 57. monitor your services and expose your own metrics (API)
  58. 58. expose insights to other agents (API)
  59. 59. show that you care about other agents
  60. 60. expose your logs
  61. 61. be clear on what happens when it fails
  62. 62. backup external data (give an API please)
  63. 63. provide & seek fast feedback on your promise change status
  64. 64. be clear on your dependencies and expect the same of other services
  65. 65. be proactive to make others keep their promises
  66. 66. give insights on changing promises
  67. 67. blog to communicate your service skill level
  68. 68. talk at conferences to indicate your willingness to share
  69. 69. make it convenient for other agents to use
  70. 70. provide feedback to other agents
  71. 71. show that you listen to those that depend on you
  72. 72. show that your participation by improving the field
  73. 73. show that your engineers are not afraid of talking to people
  74. 74. be responsive to requests
  75. 75. let other agents influence your changing promises
  76. 76. External Services are the next silo
  77. 77. “The collaboration between dev & ops is now extended to external 3rd parties”
  78. 78. “make clear promises to other agents”
  79. 79. “And verify the status of other agents promises”
  80. 80. “To keep your promise to the business”
  81. 81. How I think most config management tools/people see the world
  82. 82. The future is outward facing
  83. 83. Questions?
  84. 84. https://vimeo.com/101735252 DevOpsDays Minneapolis 2014 Jeff Sussna, Promising Digital Service Quality

×