Develop in ludicrous mode with azure serverless
Download as PPTX, PDF0 likes279 views
The document discusses the development of microservices using Azure Functions, highlighting features such as triggers, bindings, and the benefits of serverless architecture. It explores patterns for durable functions, which enable long-running operations, and illustrates various coding patterns for orchestrations. Additionally, it emphasizes the advantages of serverless solutions, including automatic scaling and reduced infrastructure management, while providing examples and scenarios of practical applications.
![Pattern #2: Fan-out/Fan-in - Easy
public static async Task Run(DurableOrchestrationContext ctx)
{
var parallelTasks = new List<Task<int>>();
// get a list of N work items to process in parallel
object[] workBatch = await ctx.CallFunctionAsync<object[]>("F1");
for (int i = 0; i < workBatch.Length; i++)
{
Task<int> task = ctx.CallFunctionAsync<int>("F2", workBatch[i]);
parallelTasks.Add(task);
}
await Task.WhenAll(parallelTasks);
// aggregate all N outputs and send result to F3
int sum = parallelTasks.Sum(t => t.Result);
await ctx.CallFunctionAsync("F3", sum);
}](https://image.slidesharecdn.com/developinludicrousmodewithazureserverless-190429140025/85/Develop-in-ludicrous-mode-with-azure-serverless-30-320.jpg)
![Pattern #5: Human Interaction w/Timeout
public static async Task Run(DurableOrchestrationContext ctx)
{
await ctx.CallFunctionAsync<object[]>("RequestApproval");
using (var timeoutCts = new CancellationTokenSource())
{
DateTime dueTime = ctx.CurrentUtcDateTime.AddHours(72);
Task durableTimeout = ctx.CreateTimer(dueTime, 0, cts.Token);
Task<bool> approvalEvent = ctx.WaitForExternalEvent<bool>("ApprovalEvent");
if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout))
{
timeoutCts.Cancel();
await ctx.CallFunctionAsync("HandleApproval", approvalEvent.Result);
}
else
{
await ctx.CallFunctionAsync("Escalate");
}
}
}](https://image.slidesharecdn.com/developinludicrousmodewithazureserverless-190429140025/85/Develop-in-ludicrous-mode-with-azure-serverless-36-320.jpg)
Develop in ludicrous mode with azure serverless
- 1. Lalit Kale Develop in Ludicrous mode with Azure Functions
- 2. About Me • 15 years of Programming • Use .NET to earn bread and butter • Worked on very large scale systems in e- Commerce , Banking and Insurance • In spare time • python, Go-Lang, OSS • Loads of TED Talks
- 3. Goal • Serverless • Azure Serverless Offerings • Introduction to Azure Functions • Build Microservice with Azure Functions • Durable Functions • Durable Functions Patterns
- 4. Microservices – architectural approach for cloud native apps Monolithic APP APP APP Microservices Large, all-inclusive app Small, independent services
- 5. Independent modules Isolated points of failure Autonomous scalability Microservices Tech flexibility Faster value delivery
- 6. Serverless – Great fit for Microservices • Problems of traditional microservices • Scaling of compute resources • Operations dependency • Pay per hosting nodes • Services discovery and • managing services integration • Serverless solution • Automatic scaling based on workload • No infrastructure management • Pay per execution (micro-billing) • Event-Driven programming model • (triggers + bindings), instant scale
- 7. Event-driven/ instant scale Micro-billingAbstraction of servers What is Serverless? $
- 8. What is Serverless? clear separation between the code and its hosting environment
- 11. Introducing Azure Functions Code EventsAzure Functions
- 12. Azure Functions Internals Function Code Function Configuration Language Runtime WebJobs Core Azure AppService
- 13. Functions Secret Sauce… • Triggers are ways to start executing Azure function code • Bindings are declarative way of binding data to Azure function • All triggers have input data • Data coming from services become input values for function code • To output data to another service use the return value of the function.
- 14. Functions Secret Sauce… • Triggers • Blob Storage • Cosmos DB • Event Hub • HTTP • Queues • Service Bus • Timer • Webhook • Bindings • File • Table • Excel • OneDrive • Email • Mobile app • Notification • More…
- 15. Scaling happens at the Function App level Usually, each Function App represents a different microservice Each Function App would be an API with grouped endpoints (one function per endpoint) Flexibility choosing the language for each microservice – one per Function App
- 16. Hosting options Gain flexibility and develop your way
- 17. Web application backends Mobile application backends IoT-connected backends Real-time file processing Real-time stream processing Automation of scheduled tasks Extending SaaS Applications Conversational bot processing Sample scenarios for Functions
- 18. Demo Azure Functions Hello World - Portal Experience - Visual Studio - Azure Functions Core Tools
- 19. Migrate from VMs → serverless Thermostat intelligence is a clear differentiator Ready for sudden vertical growth in the consumer market—charged for usage as they scale 20K+ IoT devices simulated Event driven architecture works well for IoT Customer Success Story GLAS®Smart Thermostat by Johnson Controls
- 20. Device to Cloud Cloud to Device IoT Hub for messaging and managing devices Event Hubs for routing and throttling Functions as microservices SignalR for device messaging
- 21. Demo Building a Microservice with Azure Functions
- 22. Stateless Microservices What about Stateful Operations?
- 23. Not everything fits on a few-seconds execution
- 25. What is Durable Functions? • Advanced feature for writing long-running orchestrations as a single C# function. No JSON schemas. No designer. • New orchestrator functions can synchronously or asynchronously call other functions. • Automatic checkpointing, enabling “long running” functions. • Solves a variety of complex, transactional coding problems in serverless apps. • Built on the open source Durable Task Framework.
- 27. Pattern #1: Function chaining - Today Problems: • No visualization to show relationship between functions and queues. • Middle queues are an implementation detail – conceptual overhead. • Error handling adds a lot more complexity. F1 F2 F3 F4
- 28. Pattern #1: Function chaining - Better // calls functions in sequence public static async Task<object> Run(DurableOrchestrationContext ctx) { try { var x = await ctx.CallFunctionAsync("F1"); var y = await ctx.CallFunctionAsync("F2", x); var z = await ctx.CallFunctionAsync("F3", y); return await ctx.CallFunctionAsync("F4", z); } catch (Exception) { // global error handling/compensation goes here } }
- 29. Pattern #2: Fan-out/Fan-in - Today Problems: • Fanning-out is easy, but fanning-in is significantly more complicated • Functions offers no help with this scenario today • All the same problems of the previous pattern F1 F2 F3
- 30. Pattern #2: Fan-out/Fan-in - Easy public static async Task Run(DurableOrchestrationContext ctx) { var parallelTasks = new List<Task<int>>(); // get a list of N work items to process in parallel object[] workBatch = await ctx.CallFunctionAsync<object[]>("F1"); for (int i = 0; i < workBatch.Length; i++) { Task<int> task = ctx.CallFunctionAsync<int>("F2", workBatch[i]); parallelTasks.Add(task); } await Task.WhenAll(parallelTasks); // aggregate all N outputs and send result to F3 int sum = parallelTasks.Sum(t => t.Result); await ctx.CallFunctionAsync("F3", sum); }
- 31. Pattern #3: HTTP Async Response Problems: • Execution state needs to be explicitly stored and managed. • Execution state and trigger state must be kept in sync manually. • Start and GetStatus is often boilerplate code that is not related to the business problem. Start DoWork GetStatus
- 32. Pattern #3: HTTP Async Response – Built in! > curl -X POST https://myfunc.azurewebsites.net/orchestrators/DoWork -H "Content-Length: 0" -i HTTP/1.1 202 Accepted Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec Server: Microsoft-IIS/8.0 > curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i HTTP/1.1 202 Accepted Content-Length: 173 Content-Type: application/json Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec Server: Microsoft-IIS/8.0 {"runtimeStatus":"Running","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:47Z"} > curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i HTTP/1.1 200 OK Content-Length: 175 Content-Type: application/json Server: Microsoft-IIS/8.0 {"runtimeStatus":"Completed","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:57Z"}
- 33. Pattern #4: Actors Problems: • Functions are stateless and short-lived. • Read/write access to external state needs to be carefully synchronized. • Functions do not support the singleton pattern today.
- 34. Pattern #4: Actors (Eternal Orchestrations) public static async Task Run(DurableOrchestrationContext ctx) { int counterState = ctx.GetInput<int>(); string operation = await ctx.WaitForExternalEvent<string>("operation"); if (operation == "incr") { counterState++; } else if (operation == "decr") { counterState--; } ctx.ContinueAsNew(counterState); }
- 35. Pattern #5: Human Interaction w/Timeout RequestApproval Escalate ProcessApproval Problems: • Can’t easily coordinate a timeout with an approval request notification. • Need a mechanism to reliably cancel either the approval handling or the timeout depending on the outcome.
- 36. Pattern #5: Human Interaction w/Timeout public static async Task Run(DurableOrchestrationContext ctx) { await ctx.CallFunctionAsync<object[]>("RequestApproval"); using (var timeoutCts = new CancellationTokenSource()) { DateTime dueTime = ctx.CurrentUtcDateTime.AddHours(72); Task durableTimeout = ctx.CreateTimer(dueTime, 0, cts.Token); Task<bool> approvalEvent = ctx.WaitForExternalEvent<bool>("ApprovalEvent"); if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout)) { timeoutCts.Cancel(); await ctx.CallFunctionAsync("HandleApproval", approvalEvent.Result); } else { await ctx.CallFunctionAsync("Escalate"); } } }
- 37. Important Orchestrator Limitations • Orchestrator code is replayed on every rehydration to restore all local state (local variables, etc). • Function calls are never replayed – the outputs are remembered. • This requires the orchestrator code to be deterministic. • Rule #1: Never write logic that depends on random numbers, DateTime.Now, Guid.NewGuid(), etc. • Rule #2: Never do I/O directly in the orchestrator function. • Rule #3: Do not write infinite loops • Rule #4: Use the built-in workarounds for rules #1, #2, and #3
- 38. Takeaways • Serverless – Glue of Cloud • Sub-Second Billing • Instant Scaling • Focus on your code – Let Azure do the heavy lifting for you.
Editor's Notes
- #20: 19
- #29: CallFunctionAsync uses queues under the covers, thus they can be scaled out to multiple VMs.
- #33: Logic Apps and Microsoft Flow have built-in support for this pattern. Note that specifics URL routes are subject to change (and have already changed since this deck was originally written).
- #35: Note that orchestrators are single-threaded, so there is no need to worry about concurrency. Orchestration instances are also implicitly singletons, so they only run on one VM at a time.
- #37: We will expose a mechanism for sending named events to an orchestrator from outside the orchestration context – e.g. REST API and/or output binding.