Errors happen in every application. In serverless, additional failures exist - timeouts, out of memory, and more. In many cases, errors are handled by the cloud vendor using a retry mechanism. Since the code is stateless, how can you be sure that the application actually works?
3. What is serverless? How is it different?
What is stateless? Why is it relevant today?
How to handle errors in such environments?
How will it help my job?
3
Things to discuss
5. 5
Why serverless?
Pay-per-use: reduces cloud compute cost by 90%
Out-of-the-box auto-scaling
DevOps à LowOps
++Developer velocity
Focus on business logic – iterate faster
Server Utilization
6. 6
The limitations of FaaS
Limited memory Limited running time
Cold startsStateless
+ concurrency limit
+ some others…
7. 7
The properties of serverless applications
Serverless is micro-services
Serverless applications are
- Highly distributed
- Highly event-driven
Utilizing managed services via APIs is key
14. 14
Retries behavior
Synchronous events
• The invoking application is in charge of the error
Asynchronous events
• A retry mechanism is triggered for a certain period of time
Stream-based events
• A retry mechanism is triggered until the data is expired
15. 15
Retry behavior consequences
Retry might change the logical flow of the application
In order for retries to succeed, the code must be idempotent:
“Idempotence is the property of certain operations in
mathematics and computer science that they can be
applied multiple times without changing the result
beyond the initial application” (Wikipedia).
16. 16
Practical methods for retries
Write idempotent code
Tough!
Use a proper service
Example: AWS Step Functions
30. 30
Distributed tracing
…a trace tells the story of a transaction or
workflow as it propagates through a
(potentially distributed) system. Distributed
tracing is a method used to profile and
monitor applications.