[NDC 2019] Functions 2.0: Enterprise-Grade Serverless

13. May 2019
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
[NDC 2019] Functions 2.0: Enterprise-Grade Serverless
1 von 51

Más contenido relacionado

Was ist angesagt?

201410 2 fiware-orion-contextbroker201410 2 fiware-orion-contextbroker
201410 2 fiware-orion-contextbrokerFIWARE
Parse London Meetup - Cloud Code Tips & TricksParse London Meetup - Cloud Code Tips & Tricks
Parse London Meetup - Cloud Code Tips & TricksHector Ramos
Firebase ng2 zurichFirebase ng2 zurich
Firebase ng2 zurichChristoffer Noring
«От экспериментов с инфраструктурой до внедрения в продакшен»​«От экспериментов с инфраструктурой до внедрения в продакшен»​
«От экспериментов с инфраструктурой до внедрения в продакшен»​FDConf
Coldbox developer training – session 5Coldbox developer training – session 5
Coldbox developer training – session 5Billie Berzinskas
Reactive Programming in Java 8 with Rx-JavaReactive Programming in Java 8 with Rx-Java
Reactive Programming in Java 8 with Rx-JavaKasun Indrasiri

Similar a [NDC 2019] Functions 2.0: Enterprise-Grade Serverless

El camino a las Cloud Native Apps - IntroductionEl camino a las Cloud Native Apps - Introduction
El camino a las Cloud Native Apps - IntroductionPlain Concepts
Integration-Monday-Stateful-Programming-Models-Serverless-FunctionsIntegration-Monday-Stateful-Programming-Models-Serverless-Functions
Integration-Monday-Stateful-Programming-Models-Serverless-FunctionsBizTalk360
Working with data using Azure Functions.pdfWorking with data using Azure Functions.pdf
Working with data using Azure Functions.pdfStephanie Locke
Azure Durable Functions (2018-06-13)Azure Durable Functions (2018-06-13)
Azure Durable Functions (2018-06-13)Paco de la Cruz
Building workflow solution with Microsoft Azure and Cloud | Integration MondayBuilding workflow solution with Microsoft Azure and Cloud | Integration Monday
Building workflow solution with Microsoft Azure and Cloud | Integration MondayBizTalk360
CQRS and Event SourcingCQRS and Event Sourcing
CQRS and Event SourcingSergey Seletsky

Último

Citi Tech Talk  Disaster Recovery Solutions Deep DiveCiti Tech Talk  Disaster Recovery Solutions Deep Dive
Citi Tech Talk Disaster Recovery Solutions Deep Diveconfluent
The art of AI ArtThe art of AI Art
The art of AI ArtDennis Vroegop
Document WhatsApp MessagingDocument WhatsApp Messaging
Document WhatsApp MessagingGeminate Consultancy Services
Salesforce @AXA.pdfSalesforce @AXA.pdf
Salesforce @AXA.pdfPatrickYANG48
Game Dev Session 01.pdfGame Dev Session 01.pdf
Game Dev Session 01.pdfAbelPhilipJoseph
OpenAI GPT in Depth - Questions and MisconceptionsOpenAI GPT in Depth - Questions and Misconceptions
OpenAI GPT in Depth - Questions and MisconceptionsIvo Andreev

[NDC 2019] Functions 2.0: Enterprise-Grade Serverless

Hinweis der Redaktion

  1. Abstraction of servers, infrastructure, OS config “Functions as a Service” OS/framework patching No need to manage infrastructure Event-driven scale Triggered by events within Azure or third-party services React in near real time to events and triggers Scales within seconds quickly, limitlessly* No scale configuration required Sub-second billing Pay only for the time your code is running
  2. Bindings Microsoft.NET.Sdk.Functions (.NET Standard 2.0) HTTP Timer Microsoft.Azure.WebJobs.Extensions.Storage 3.0.0 Microsoft.Azure.WebJobs.Extensions.ServiceBus 3.0.0 Microsoft.Azure.Webjobs.Extensions.EventHubs 3.0.0 Microsoft.Azure.WebJobs.Extensions.CosmosDB 3.0.0 Microsoft.Azure.Webjobs.Extensions.EventGrid 2.0.0 Microsoft.Azure.WebJobs.Extensions.DurableTask 1.4.0 Microsoft.Azure.Webjobs.Extensions.MicrosoftGraph 1.0.0-beta Scenarios Web/Mobile app workloads IoT-connected backends Real-time processing Automation of infrastructure
  3. The time it takes to ready an instance when no instance yet exists Varies greatly on a number of factors like language and # of files Today for C# in v1 is generally around 3-4 seconds today, 1-2 seconds in on-deck release Few angles of attack Pre-warmed “workers” Zipped artifacts without extract (Zip Deploy) Keep alive (keep warm longer) Users can help mitigate by: Using Zip Deploy if possible (paired with something like funcpack for Node) Use C# Class Libraries over .csx for large functions If push comes to shove, a “pinger” can keep warm
  4. Function with blob full of files I want to encrypt haven’t called it in last twenty minutes Call premium and consumption
  5. -- K8 is reactive: container CPU/memory -- Fx is event-driven: ex. queue depth, Kafka stream length -- partnered w/Red Hat -- scale from 0-1000s of instances -- containers consume events directly from source; no decoupling w/HTTP -- routing through HTTP == data and context loss -- extensible -- Azure Functions are containerizable -- deploy in-cloud or on-prem -- Fx run integrated w/OpenShift [[WHAT IS THIS]] -- adds event sources to K8s -- we see most of our executions come from non-HTTP sources (HTTP only 30%) -- Kafka, Azure Queues, Azure Service Bus, RabbitMQ, HTTP, and Azure Event Grid / Cloud Events. More triggers will continue to be added in the future including Azure Event Hubs, Storage, Cosmos DB, and Durable Functions. -- runs alongside Virtual Kubelet and AKS Virtual Nodes [[ WHAT ARE THESE ]] -- open source -- webinar! May 28: aka.ms/keda-webinar -- when to consider KEDA
  6. https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local#v2 https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function-azure-cli https://stackoverflow.com/questions/46877667/how-to-push-a-new-initial-project-to-github-using-vs-code
  7. Imagine a scenario where I have to take the output of a Function and use it as the input to call another Function. I’ll have to coordinate the chaining manually. If I have to have a function that takes some sort of event and then parallelizes it into multiple Functions, I can still do that but how will I know when all Functions have finished executing so I can aggregate the results and move on. What if I had to listen on multiple events and aggregate their outcome to determine which specific job or function to run in my application. What if I wanted to do some kind of extended monitoring on an endpoint? For example, if I were to monitor the temperature of a remote machine and take action x if the temperature were lower than a certain threshold, else do y or run job y. What if I have an API or endpoint that was running for a long time? I know Functions are short-lived but sometimes you guys put some serious load on them. Could there be a mechanism to provide status of the execution back to the client so they’re not left hanging? And lastly, what if I wanted to get some sort of human interaction in there? For example, if I am to do some sort of 2FA in the middle of my function execution but also don’t want to wait forever because sometimes people take forever to reply especially when the texts are automated. Today, I’m going to be talking about some of these problems – how you can approach them in regular FaaS? And how they can be simplified with the technology of Durable Functions.
  8. In the function chaining pattern, a sequence of functions executes in a specific order. In this pattern, the output of one function is applied to the input of another function.
  9. The async HTTP APIs pattern addresses the problem of coordinating the state of long-running operations with external clients. A common way to implement this pattern is by having an HTTP call trigger the long-running action. Then, redirect the client to a status endpoint that the client polls to learn when the operation is finished.
  10. The monitor pattern refers to a flexible, recurring process in a workflow. An example is polling until specific conditions are met. You can use a regular timer trigger to address a basic scenario, such as a periodic cleanup job, but its interval is static and managing instance lifetimes becomes complex. You can use Durable Functions to create flexible recurrence intervals, manage task lifetimes, and create multiple monitor processes from a single orchestration.
  11. Many automated processes involve some kind of human interaction. Involving humans in an automated process is tricky because people aren't as highly available and as responsive as cloud services. An automated process might allow for this by using timeouts and compensation logic.
  12. Grasping how orchestrators use execution history to replay and rebuild their local state is key to understanding how Durable Functions works, so let’s walk through the execution of a simple orchestrator function. The light blue box at the top of the slide is the orchestrator’s code. “SayHello” our activity function, which returns “Hello” and whatever input you give it. Our execution history is currently empty. As we start to record events, they’ll show up here. (Indicate area.) 1. A request is made to the orchestrator function. 2. The orchestrator starts and begins executing until it’s asked to await some async work. In this case, we want to call an activity function. 3. The orchestrator checks the execution history for a record of the activity function. 4. There’s no record of the activity function being called or completed, so the orchestrator schedules that work. 5. While the orchestrator waits on work to complete, it shuts down. 5. The scheduled activity function runs. 6. A record of this is added to the execution history. In this case we produced output, so that’s stored. 7. Now the orchestrator has more work to do. It restarts and executes its code **from the beginning** to build up its local state. 8. As before, the orchestrator executes until it reaches an await. 9. The orchestrator checks the execution history. This time there’s a record of the async work being done. 10. The activity function’s stored output is passed back to the orchestrator. In this case, the value is added to a list of strings. 11. The orchestrator continues executing. In a more complex orchestrator with multiple await calls, the checkpoint, schedule and replay steps would repeat for each one. This orchestrator runs to completion and returns its output. 12. And we’re done! - How does the framework know to wake up
  13. The sixth pattern is about aggregating event data over a period of time into a single, addressable entity. In this pattern, the data being aggregated may come from multiple sources, may be delivered in batches, or may be scattered over long-periods of time. The aggregator might need to take action on event data as it arrives, and external clients may need to query the aggregated data.