FROM SERVERLESS TO SERVICEFULL HOW THE MINDSET OF DEVOPS IS EVOLVING @patrickdebois - Small Town Heroes
Things I did (I’m proud of)
LIVE RESULTSINTERACTION MODERATION STUDIO CONTROLPART OF THE SHOW
(almost) SERVERLESS
“Backend” services ELB
“IT support” services
Our “Office” services
“Community” services
“Frontend” services
“Mobile” services SNS/Push Cognito
(almost) SERVICEFULL
A bit further down the rabbit hole …
Github
undocumented changes to service
limits and unavailable
autoscaling is too slow for peak traffic
service got disabled because of too many bounces
inconsistent behaviour
(almost) NO MAINTENANCE
increased risk when not available
Case1 Generate “personalised” image Browser -> Pre-signed S3 -> Lambda -> SQS -> Redis
Case2 Peak load testing like a real browser SQS -> Lambda -> S3 results
Case3 Generate “personalised” text animated gif API GW -> Lambda -> S3 image
Case4 Animated gif/movie/meme editor API GW -> Lambda -> Img magic movie -> s3
You are an Agent
You make promises to others in the system
Your promises should be verifiable
A promise does not guarantee an outcome
Conditions should be part of your promise
It needs to be clearly documented otherwise it’s not a promise
the language of a promise must be shared
It needs to be mutually agreed (not obligation) otherwise it’s not a promise
You might depend on other agents to keep your promises
Other agents make promises to you
Their promises need to be verifiable clearly documented & mutually agreed (not obligation)
But you can not make promises on behalf of other agents (bottom up vs top down)
Promises can be conflicting in a system
but the conflict can only be from internal promises (as we can not be responsible for others promises)
To keep a promise you should have a choice Push vs Pull
Single Leaves = SPOF To create choice you need to eliminate the single leaves (SPOF)
“Abstraction is selective ignorance” http://en.wikipedia.org/wiki/Andrew_Koenig_(programmer)
All problems in computer science can be solved by another level of abstraction
… except for the problem of too many layers of indirection … David Wheeler (inventor of subroutine)
Every promise binding is the basis for relationship (Dunbar)
Agents with a similar goal can be grouped into a Super Agent
Services
Single Leaves = SPOF You need multiple Super Agents to have a choice again
Forksv1 v2 v3 v1 v2 v3 To keep promises agent can introduce different world views (versions)
Slows down A super agent might get slow internal communication speed is key
Scaling Promises keeping your promise while changing your size (is hard)
container re-use non-deterministic
limits not clear under stress
scale is not always infinite
services devops
Holy Cow!
“I introduced devops and all I got was a remote API”
It’s devops Jim but not as we know it
emerging practices
communicate the status of your promise and monitor others
monitor your services and expose your own metrics (API)
expose insights to other agents (API)
show that you care about other agents
expose your logs
be clear on what happens when it fails
backup external data (give an API please)
provide & seek fast feedback on your promise change status
be clear on your dependencies and expect the same of other services
be proactive to make others keep their promises
give insights on changing promises
blog to communicate your service skill level
talk at conferences to indicate your willingness to share
make it convenient for other agents to use
provide feedback to other agents
show that you listen to those that depend on you
show that your participation by improving the field
show that your engineers are not afraid of talking to people
be responsive to requests
let other agents influence your changing promises
External Services are the next silo
“The collaboration between dev & ops is now extended to external 3rd parties”
“make clear promises to other agents”
“And verify the status of other agents promises”
“To keep your promise to the business”
Questions?
https://vimeo.com/101735252 DevOpsDays Minneapolis 2014 Jeff Sussna, Promising Digital Service Quality
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
From serverless to Service Full - How the mindset of devops is evolving
Upcoming SlideShare
Loading in …5
×

From serverless to Service Full - How the mindset of devops is evolving

57 views
 54 views

Published on

We are moving up the abstraction stack - managing services over servers
This talk was presented as ServerlessConf.io

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
57
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

From serverless to Service Full - How the mindset of devops is evolving

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

×