DevOpsDays Cuba 2016: How the practices of DevOps are evolving from servers to services.

DevOpsDays Cuba 2016: How the practices of DevOps are evolving from servers to services.

Author: Patrick Debois
Summary:

D5db2dc3cc883df3479797edb63b581b?s=128

DevOpsDays Cuba

October 20, 2016
Tweet

Transcript

  1. HOW THE PRACTICES OF DEVOPS ARE EVOLVING from servers to

    services @patrickdebois - Small Town Heroes
  2. Things I did (I’m proud of)

  3. OPS DEV http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 4 areas of improvement

  4. OPS DEV Area 1: Extend delivery to production http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

  5. OPS DEV Area 2: Extend operations feedback to project Area

    1: Extend delivery to production http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  6. OPS DEV Area 2: Extend operations feedback to project Area

    1: Extend delivery to production Area 3: Embed Project knowledge into Operations http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  7. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  8. OPS DEV http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ Technical Loop Business Loop Business Loop

  9. LIVE RESULTS INTERACTION MODERATION STUDIO CONTROL PART OF THE SHOW

  10. Focus on the Business

  11. “Backend” services “IT support” services Our “Office” services “Community” services

    “Frontend” services
  12. “Mobile” services SNS/Push Cognito

  13. (almost) NO SERVERS

  14. A bit further down the rabbit hole …

  15. Github service not available

  16. undocumented changes

  17. inconsistent behaviour

  18. different behaviour under load

  19. (almost) NO MAINTENANCE Less Maintenance

  20. increased risk when not available More speed

  21. With increased risk

  22. Functions As a Service (FAAS) aka “serverless”

  23. Case1 Generate “personalised” image Browser -> Pre-signed S3 -> Lambda

    -> SQS -> Redis
  24. Case2 Animated gif/movie/meme editor API GW -> Lambda -> Img

    magic movie -> s3
  25. None
  26. None
  27. You are an Agent

  28. You make promises to others in the system

  29. Your promises should be verifiable

  30. A promise does not guarantee an outcome

  31. Conditions should be part of your promise

  32. It needs to be clearly documented otherwise it’s not a

    promise
  33. It needs to be mutually agreed (not obligation) otherwise it’s

    not a promise
  34. You might depend on other agents to keep your promises

  35. Other agents make promises to you

  36. Their promises need to be verifiable clearly documented & mutually

    agreed (not obligation)
  37. But you can not make promises on behalf of other

    agents (bottom up vs top down)
  38. Promises can be conflicting in a system

  39. but the conflict can only be from internal promises (as

    we can not be responsible for others promises)
  40. To keep a promise you should have a choice Push

    vs Pull
  41. Single Leaves = SPOF To create choice you need to

    eliminate the single leaves (SPOF)
  42. All problems in computer science can be solved by another

    level of abstraction
  43. … except for the problem of too many layers of

    indirection … David Wheeler (inventor of subroutine)
  44. None
  45. Every promise binding is the basis for relationship (Dunbar)

  46. Agents with a similar goal can be grouped into a

    Super Agent
  47. Single Leaves = SPOF You need multiple Super Agents to

    have a choice again
  48. Forks v1 v2 v3 v1 v2 v3 To keep promises

    agent can introduce different world views (versions)
  49. Slows down A super agent might get slow internal communication

    speed is key Opportunity for personalised service providers
  50. Scaling Promises keeping your promise while changing your size (is

    hard)
  51. container re-use non-deterministic

  52. limits not clear under stress

  53. services devops

  54. Holy Cow!

  55. “I introduced devops and all I got was a remote

    API”
  56. It’s devops Jim but not as we know it

  57. emerging practices

  58. communicate the status of your promise and monitor others

  59. monitor your services and expose your own metrics (API)

  60. expose insights to other agents (API)

  61. show that you care about other agents

  62. expose your logs

  63. be clear on what happens when it fails

  64. backup external data (give an API please)

  65. provide & seek fast feedback on your promise change status

  66. be clear on your dependencies and expect the same of

    other services
  67. be proactive to make others keep their promises

  68. give insights on changing promises

  69. blog to communicate your service skill level

  70. talk at conferences to indicate your willingness to share

  71. make it convenient for other agents to use

  72. provide feedback to other agents

  73. show that you listen to those that depend on you

  74. show that your participation by improving the field

  75. show that your engineers are not afraid of talking to

    people
  76. let other agents influence your changing promises

  77. “The collaboration between dev & ops is now extended to

    external 3rd parties”
  78. “make clear promises to other agents”

  79. “And verify the status of other agents promises”

  80. “To keep your promise to the business”

  81. External Services are the next silo think “Supply Chain”

  82. https://vimeo.com/101735252 DevOpsDays Minneapolis 2014 Jeff Sussna, Promising Digital Service Quality

  83. None
  84. Questions?

  85. patrick@smalltownheroes.be www.smalltownheroes.be @patrickdebois