Presented at ServerlessConf NYC 2016. It's great that we don't need to manage servers anymore and can just use a service. Let them worry about the availability. Endless capacity ftw. Reality is that we are just entering another abstraction layer and the same problems need to be solved: - what if the server goes down vs what if the service goes down - how many servers do I need vs how many req/sec do I need ask Amazon to provision - how do monitor my servers vs how do I monitor my service vs how do I monitor my functions - how to control who gets access to my servers vs who can access my services - how do I keep track of my server versions/dependencies vs how do I keep track of my functions versions/dependencies A lot of the *-ilities revolve around trust. Trust in the system. And not just the technical side, also including the people side. The promise of an API is not enough, it's the promise of a ecosystem of services. It's only a small step from running a function on AWS Lambda vs using an external service. Why run the function at all if someone is better at it? Because we have more 'control'? In the presentation I will provide examples of real projects we did at Small Town Heroes (http://www.smalltownheroes.be) where we are leveraging the power of serverless. And how we try to expand our internal devops collaboration beyond the api boundaries to focus on the full stack service and not merely the components. Winter is coming

1. FROM SERVERLESS
TO SERVICEFULL
HOW THE MINDSET OF
DEVOPS IS EVOLVING
@patrickdebois - Small Town Heroes

2. Things I did (I’m proud of)

3. LIVE RESULTSINTERACTION
MODERATION
STUDIO CONTROLPART OF THE SHOW

4. (almost)
SERVERLESS

5. “Backend” services
ELB

6. “IT support” services

7. Our “Office” services

8. “Community” services

9. “Frontend” services

10. “Mobile” services
SNS/Push Cognito

11. (almost)
SERVICEFULL

12. A bit further down the rabbit hole …

13. Github

14. undocumented
changes
to service

15. limits and unavailable

16. autoscaling is too slow
for peak traffic

17. service got
disabled because
of too many bounces

18. inconsistent behaviour

19. (almost)
NO MAINTENANCE

20. increased risk
when not available

22. Case1
Generate “personalised” image
Browser -> Pre-signed S3 -> Lambda -> SQS -> Redis

23. Case2
Peak load testing like a real browser
SQS -> Lambda -> S3 results

24. Case3
Generate “personalised” text animated gif
API GW -> Lambda -> S3 image

25. Case4
Animated gif/movie/meme editor
API GW -> Lambda -> Img magic movie -> s3

29. You are an Agent

30. You make promises to others in the system

31. Your promises should be verifiable

32. A promise does not guarantee an outcome

33. Conditions should be part of your promise

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

36. the language of a promise must be shared

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

38. You might depend on other agents to keep your promises

39. Other agents make promises to you

40. Their promises need to be verifiable
clearly documented & mutually agreed (not obligation)

41. But you can not make promises on behalf of other agents
(bottom up vs top down)

42. Promises can be conflicting in a system

43. but the conflict can only be from internal promises
(as we can not be responsible for others promises)

44. To keep a promise you should have a choice
Push vs Pull

45. Single Leaves
= SPOF
To create choice you need to eliminate the single leaves (SPOF)

47. “Abstraction is selective
ignorance”
http://en.wikipedia.org/wiki/Andrew_Koenig_(programmer)

48. All problems in computer science
can be solved by
another level of abstraction

49. … except for the problem of
too many layers of indirection …
David Wheeler (inventor of subroutine)

52. Every promise binding is the basis for relationship
(Dunbar)

53. Agents with a similar goal can be grouped
into a Super Agent

54. Services

55. Single Leaves
= SPOF
You need multiple Super Agents to have a choice again

56. Forksv1
v2
v3
v1
v2
v3
To keep promises agent can introduce
different world views (versions)

57. Slows down
A super agent might get slow
internal communication speed is key

58. Scaling Promises
keeping your promise while changing your size (is hard)

59. container re-use
non-deterministic

60. limits not clear
under stress

61. scale is not
always infinite

62. services
devops

63. Holy Cow!

64. “I introduced devops
and all I got was a remote API”

65. It’s devops Jim but not as we know it

66. emerging practices

67. communicate
the status
of your promise
and monitor others

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

69. expose insights to
other agents
(API)

70. show that you care
about
other agents

71. expose your logs

72. be clear on what
happens when it fails

73. backup external data
(give an API please)

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

75. be clear on your
dependencies and expect the same
of other services

76. be proactive
to make others keep their
promises

77. give insights on
changing promises

78. blog to
communicate
your service
skill level

79. talk at conferences to
indicate
your willingness
to share

80. make it convenient
for other agents to use

81. provide feedback to
other agents

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

83. show that your
participation by improving
the field

84. show that your
engineers
are not afraid of talking to
people

85. be responsive to requests

86. let other agents
influence your changing
promises

87. External Services are the next silo

88. “The collaboration
between dev & ops is now
extended to external 3rd parties”

89. “make clear promises
to other agents”

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

91. “To keep your promise
to the business”

93. Questions?

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