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

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