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
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.
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.
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
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.
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.
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.
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.
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
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
daronyondem
rilmayer
comucal
knsg16
loglass2019
hhiroshell
okamototakuyasr2
inureyes
masasuzu
.png){kind=icon}
3playmarketing
akkie76
orgachem
yukimatsuyoshi
jonyablonski
garrettdimon
colly
bkeepers
shpigford
keathley
dougneiner
marcelosomers
maggiecrowley
holman
bcantrill
addyosmani