The State of Statelessness

Exploring the use of application observability and telemetry for improving the quality and reliability of applications.

Transcript

1. The State of Statelessness CTO & Co-founder, IOpipe Erica Windisch
8. Lambda is a pipeline
 of code to production.
9. Stop worrying about containers, servers, and Kubernetes.
11. Maybe all you need are some circles Serverless
 Culture Don’t build, when you can buy. Build as little as necessary. Build with the minimum operational complexity.
12. The 12 Factor App I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes
13. The 12 Factor App VI. Processes Execute the app as one or more stateless processes VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams
14. 12 factor provides guidelines Serverless enforces those guidelines
15. Amazon’s “Serverless (functions) Manifesto” ✤ Function are the unit of deployment and scaling. ✤ No machines, VMs, or containers visible in the programming model. ✤ Permanent storage lives elsewhere. ✤ Scales per request; Users cannot over- or under-provision capacity. ✤ Never pay for idle (no cold servers/containers or their costs). ✤ Implicitly fault-tolerant because functions can run anywhere. ✤ BYOC - Bring Your Own Code. ✤ Metrics and logging are a universal right.
16. Stateless applications aren’t new, the enforcement model is.
17. Serverful Application Design Running on Elasticbeanstalk
18. SERVERLESS is STATELESS ARCHITECTURE for STATELESS APPLICATIONS
19. You can’t cheat on statelessness
 when the platform enforces it.
20. Build APIs without code… RESTful service that puts data into a Kinesis Stream
21. Accept you always have state.
22. Profiling Lambda
23. Serverless has servers. Statelessness has state.
24. event-driven distributed scalable Serverless Stateless = = { }
25. Pay only when processing an event. You only pay while your application maintains state.
 
 (i.e. while it’s loaded into memory and executing code)
26. Recognize where state is important, and where it is not.
27. Stateless design matters for serverless apps
28. Your stateless app has stateful artifacts.
29. Input events are state!
30. A function’s output is state!
31. Errors are state.
32. Stateless “doesn’t exist”
 There’s always state.
33. serverless eliminates the need to know about the state of servers.
34. What about the state of your application?
35. Is your application working?
36. Are you sure?
37. Define “working”.
38. UP != “online”
39. UP == useful
40. Uptime?
41. What if your app is always “up”?
42. The traditional story is centered on deployment & uptime.
43. Your code always does what you write it to do. Does it do what you
 WANT it to do?
44. If it “works” matters.
45. What your app is doing matters.
46. Key Performance Metrics (KPIs)
 are critical.
47. Infrastructure monitoring has one KPI: availability
49. Infrastructure monitoring is boring.
50. You don’t know what your application is doing by looking from the outside-in.
52. What your application is
 doing is interesting.
56. What your users are doing matters.
58. Knowing if your app works is… ops?
59. Your users… do they have sessions?
60. What percentage of database writes for this customer took over 5ms? 10ms? 100ms?
62. Which HTTP request stored this file on S3? … this database record?
63. How do you track this state? How do you observe it?
64. Which user encountered this error?
65. What was the chain of API calls made by this user?
67. How many users of your Alexa skill thanked you?
 
 How many cursed you?
68. Application metrics > Infrastructure metrics
69. Infrastructure performance? Boring.
70. Business performance? Interesting.
71. There’s always state… There’s always servers… There’s always a user… The user experience is what matters.
72. Are you pleasing your users?
73. How do you enable
 other users, like data scientists?
74. How much does your app
 make for your business?
75. Observe infrastucture.
76. Observe your apps.
77. Observe user experience.
78. Correlate!
79. www.iopipe.com © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! Erica Windisch <erica@iopipe.com> @ewindisch