Advanced design patterns in action
- 1. Advanced design patterns in action
- 2. Me – Chris Anderson @crandycodes Senior Program Manager on Azure Functions @crandcodes Day job: Senior Program Manager Azure Functions
- 3. What is the right way to design a serverless application?
- 4. 42
- 5. Don’t Panic
- 6. What makes serverless applications different than “serverful” applications? Inherently event oriented State must be externalized Platform specific APIs for hosting logic Don’t have to manage infrastructure
- 7. Really, though? “Serverful” applications are: Inherently Probably event oriented State must should be externalized from business logic Platform/framework specific APIs for hosting logic Don’t have to manage infrastructure
- 8. So what’s really different? Don’t have to manage infrastructure In exchange, we took away all your existing frameworks for solving problems
- 9. If I don’t have any existing frameworks, what do I do now?
- 10. Taking inventory: what does serverless leave us with? Events Logic
- 11. Events are messages What kinds of messages are there? Actions – user clicked/navigated, order has been shipped Data – status heartbeat, temperature readings, logs Actions represent that something happened and usually gets an individual response Data usually gets aggregated, can create actions https://aka.ms/messaging-services @clemensv
- 12. Scenario 1. Manufacturing device sends us temperature data periodically 2. When a threshold is crossed, we emit an event that says the threshold has been crossed 3. When we see the event for threshold being crossed, we emit an event which says we should notify someone on the production line
- 13. Scenario 1. Manufacturing device sends us temperature data periodically 2. When a threshold is crossed, we emit an event that says the threshold has been crossed 3. When we see the event for threshold being crossed, we emit an event which says we should notify someone on the production line
- 14. Intents When we intend something should happen, we can think of that message has having intent. Something that should happen, should eventually have happened Whether it has happened or not is state
- 16. State
- 17. State? I thought serverless was supposed to be stateless?
- 18. Stateless is for your logic, not your application Most applications, arguably, have state. Serverless applications, largely, need to externalize their state Complexity of managing state is where the relative dearth of frameworks for serverless applications can be painful
- 19. Scenario: trading app Jack Jill Trader app status update accept cancel
- 20. Scenario: trading app Jack Jill Trader app status update accept unaccept Store Jack accepts Jill accepts Wait for both to accept Someone unaccepts
- 21. Yes, we’ve waited for 1 event, but what about 2? Approaches: 1. Each event publishes its status, and when it does, it also checks its fellow event’s status and if both trades are in, it closes the deal. 2. Each event publishes its status, and then sends an event out that says it has finished. When the finished event is received, it checks whether Jack and Jill have agreed on a trade, and then closes the deal. 1 is probably good enough, but 2 has the advantage of splitting up the logic for accepting trades and closing trades.
- 22. Add a timer and notificationss Jack Jill Trader app status update accept unaccept Store Jack accepts Jill accepts Wait for both to accept Someone unaccepts Cancel
- 23. Now there were 3 If it weren’t for notifications, we could just add checks so everytime we check the status or try to update/accept the trade, we just enforce the timeout and stick with option 1 from before Luckily, if we went with option 2, we could add a queue message scheduled in the future which would attempt to cancel the trade if it is not done.
- 24. More actions, more complexity We eventually have lots of actions, lots of different rules for state Many implementations move towards Event Sourcing as the pattern for success
- 25. So I have to manage all this manually? There’s no frameworks to help me?
- 27. Introducing Durable Functions Announcing “beta” release of Durable Functions - https://aka.ms/durable-functions Framework for managing more complex, stateful orchestrations • Expression of tasks in code • Automatic persistence and check-pointing of program state • Versioning of orchestrations and activities • Async timers, orchestration composition Complements and extends “code-less” orchestration in Logic Apps via async HTTP friendly API
- 28. Introducing Binding Extensibility Now in preview: binding extensibility Durable Functions is just an extension to Azure Functions You can now create your own! Author the extension in C# and use from any language Learn more at https://aka.ms/BYOB
- 29. Workflow
- 30. Fan in & fan out – (MapReduce)
- 31. Long Callbacks (Human interaction)