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

Author: Patrick Debois
Summary:

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
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)
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
84. Questions?
85. patrick@smalltownheroes.be www.smalltownheroes.be @patrickdebois