Slide 1

Slide 1 text

FaaS for Everyone, Everywhere Daron Yöndem Azure Application Development Tech Lead for MEA Microsoft http://daron.me @daronyondem

Slide 2

Slide 2 text

What langauges do you support? - C# .NET 4.8, 6, 7 - F# .NET 6, 7 - NodeJS 18, 16, 14 - Java 8, 11, 17 - Powershell 7.2 - Python 3.10, 3.9, 3.8, 3.7 - TypeScript (through transpiling to JavaScript) - Go, Rust, others (Custom Handlers)

Slide 3

Slide 3 text

What do you mean, Custom Handlers? Custom handlers are lightweight web servers that receive events from the Azure Functions host. Any language that supports HTTP primitives can implement a custom handler. This means that custom handlers can be used to create functions in languages that aren't officially supported. 📚 Go Sample: https://github.com/Azure-Samples/functions-custom- handlers/tree/master/go

Slide 4

Slide 4 text

Can I bring anything? - Would you like Custom Containers? - We give you base Linux Image. - Premium Plan or Dedicated App Service Plan Host is a must. 📚 https://learn.microsoft.com/azure/azure-functions/functions- create-function-linux-custom-image ⚠️ Linux Containers can only be deployed to Linux Premium and Linux Dedicated plans.

Slide 5

Slide 5 text

What are hosting options? - Consumption - Pay per GB-s - Execution Count Charge - Premium - vCPU + Memory Duration - App Service Elastic Premium plans (SKU starts with E) - Autoscales out of the box. - Every premium plan has at least one active (billed) instance at all times. - Multiple Functions Apps can share a single plan. - Dedicated - App Service Premium V2 plans (SKU starts with P) - Wont autoscale unless you do.

Slide 6

Slide 6 text

Am I stuck with public cloud? - Azure Functions = Runtime + Scale Controller - Runtime might need an Azure Storage Account. - Docker container base image https://hub.docker.com/_/microsoft-azure-functions-base - Supporting seamless event-driven scale within a Kubernetes cluster using Kubernetes-based Event Driven Autoscaling (KEDA). 📚 https://learn.microsoft.com/azure/azure-functions/functions-kubernetes- keda

Slide 7

Slide 7 text

What is this Isolated Process thing? - In-Process mode runs everything with the same runtime process. - Isolated means: - Not stuck with the .NET Version used by runtime. - Less dependency conflict - Dependency injection and middleware support for .NET.

Slide 8

Slide 8 text

My next API has no servers… API for Free!

Slide 9

Slide 9 text

Queue me up baby! Bindings and Triggers

Slide 10

Slide 10 text

Let’s talk Workflows… • Azure Logic Apps: For those who like user interfaces and workflow definition files. • Azure Durable Functions: For those who like codifying workflows, and more.

Slide 11

Slide 11 text

Durable Functions! • Stateful functions • Managed state, checkpoints, and restarts when needed. • Define stateful workflows in orchestrator functions. .

Slide 12

Slide 12 text

Workflows you said? • Define workflows in code. No JSON schemas or designers are needed. • They can call other functions synchronously and asynchronously. Output from called functions can be saved to local variables. • They automatically checkpoint their progress whenever the function awaits. Local state is never lost if the process recycles.

Slide 13

Slide 13 text

Problem 1 : Function Chaining • No visualization to show relationship between functions and queues. • Middle queues are an implementation detail – conceptual overhead. • Error handling adds a lot more complexity.

Slide 14

Slide 14 text

Function chaining DEMO

Slide 15

Slide 15 text

Problem 2 : Fan-out/Fan-in • Fanning-out is easy, but fanning-in is more complicated. • Functions offers no help with this scenario today • All the same problems of the previous pattern

Slide 16

Slide 16 text

Fan-Out DEMO

Slide 17

Slide 17 text

Problem 3 : Eternal Processes • Long running processes • Built-in state management • orchestrationClient or built-in webhooks can be used.

Slide 18

Slide 18 text

Problem 5 : Human Interaction • Durable timers to wait for external events. • orchestrationClient binding can be used to use built-in bindings.

Slide 19

Slide 19 text

External Events DEMO

Slide 20

Slide 20 text

Important Orchestrator Limitations Orchestrator code is replayed on every rehydration to restore all local state (local variables, etc). • Follows the Event Sourcing stateful pattern • 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

Slide 21

Slide 21 text

Durable Task Framework Engines DurableTask.AzureStorage Default backend, serverless, low cost DurableTask.Netherite 10X Performance, Combine with Event Hubs with Faster DurableTask.SqlServer No Azure needed!

Slide 22

Slide 22 text

Resources Which triggers require a storage account and which don’t. • https://learn.microsoft.com/azure/azure-functions/storage-considerations Workflow Definition Language schema for Azure Logic Apps • https://goo.gl/r3fx4T Durable Task Framework • https://goo.gl/q4yjUc Durable Functions Nuget Package • https://goo.gl/p1ma8T

Slide 23

Slide 23 text

Thanks http://daron.me | @daronyondem Grab slides on http://decks.daron.me/