Downloaded 11 times
Uploaded byUdaiappa Ramachandran
Azure serverless computing
The document outlines a presentation on Azure serverless computing by Udaiappa Ramachandran, detailing key components such as Azure Functions, dependency injection, and Azure Durable Functions. It discusses the benefits of serverless architecture, including cost efficiency, scalability, and faster deployment, while also presenting common scenarios and supported languages. Additionally, it includes references to resources for further information on serverless technology in Azure and comparisons with other cloud providers like Amazon and Google.
More Related Content
Similar to Azure serverless computing
More from Udaiappa Ramachandran
Azure serverless computing
- 1. Azure Serverless Computing UdaiappaRamachandran ( Udai ) https://udai.io
- 2. Who am I? •Udaiappa Ramachandran ( Udai ) • CTO, Akumina, Inc., • Focus on Cloud Computing • Microsoft Azure, Amazon Web Services and Google • New Hampshire Cloud User Group (http://www.meetup.com/nashuaug ) • https://udai.io
- 3. Agenda • Serverless computing •Azure Functions • Dependency Injection • Dynamic Site Hosting • Azure Durable Functions/2.0 • Key Vault in Azure Functions • Scripting Azure Functions • Demo • References • Q & A
- 4. The evaluation ofapplication platforms • On-premises • IaaS • PaaS • Serverless
- 5. Serverless • What isserverless? • Built on Micro services • Abstraction of servers • Event-driven • Micro-billing (Pay-for-what-you-use) • Benefits • Automatically Scale • Focus on business logic • Faster time to market • Ops Cost Reduction
- 6.
- 7. Serverless components • Functions(serverless component) • Logic Apps (serverless workflow) • Flow (built on top of logic apps) • Event Grids (serverless events)
- 8. Azure Functions (Code+EventData) •Choice of language • Pay-per-use pricing model • Bring your own dependencies • Integrated security • Simplified integration • Flexible development • Open-source • Flexible AppService Plan • Consumption • Premium • Dedicated (App Service)
- 9. Supported Languages Language 1.x2.x 3.x1 C# GA (.NET Framework 4.7) GA (.NET Core 2.2) Preview (.NET Core 3.x) JavaScript GA (Node 6) GA (Node 8 & 10) Preview (Node 8 & 10) F# GA (.NET Framework 4.7) GA (.NET Core 2.2) Preview (.NET Core 3.x) Java N/A GA (Java 8) Preview (Java 8) PowerShell Experimental Preview (PowerShell Core 6) Preview (PowerShell Core 6) Python Experimental GA (Python 3.6.x) Preview (Python 3.6.x) TypeScript Experimental GA2 Preview2 Bash Experimental N/A N/A Batch (.cmd, .bat) Experimental N/A N/A PHP Experimental N/A N/A 1The Functions v3.x runtime is in preview. 2Supported through transpiling to JavaScript.
- 10. Triggers and Bindings 1In the version 2.x runtime, all bindings except HTTP and Timer must be registered. See Register binding extensions. All supported 2.x bindings are also supported in the version 3.x, unless otherwise noted. Type 1.x 2.x1 Trigger Input Output Blob storage ✔ ✔ ✔ ✔ ✔ Cosmos DB ✔ ✔ ✔ ✔ ✔ Event Grid ✔ ✔ ✔ Event Hubs ✔ ✔ ✔ ✔ HTTP & webhooks ✔ ✔ ✔ ✔ IoT Hub ✔ ✔ ✔ ✔ Microsoft Graph Excel tables ✔ ✔ ✔ Microsoft Graph OneDrive files ✔ ✔ ✔ Microsoft Graph Outlook email ✔ ✔ Microsoft Graph events ✔ ✔ ✔ ✔ Microsoft Graph Auth tokens ✔ ✔ Mobile Apps ✔ ✔ ✔ Notification Hubs ✔ ✔ Queue storage ✔ ✔ ✔ ✔ SendGrid ✔ ✔ ✔ Service Bus ✔ ✔ ✔ ✔ SignalR ✔ ✔ ✔ Table storage ✔ ✔ ✔ ✔ Timer ✔ ✔ ✔ Twilio ✔ ✔ ✔
- 11. Common Scenarios • BackgroundProcessing • Timer-based processing • Azure service event processing • SaaS event processing • Serverless web application architectures • Serverless mobile backends • Real-time stream processing • Real-time bot messaging
- 12. IoC-Dependency Injection • IoC(Inversion of Control) • Service Location • Events • Delegates • DI • DI (Dependency Injection) • Constructor • Setter/Getter • Interface/Methods • DI Pros & Cons • DI Frameworks • .NET: Unity, Structure Map, Autofac, Ninject, and Managed Extensibility Framework (MEF) • JAVA: Weld, Spring, Guice, Play framework, Salta, Glassfish HK2, Dagger
- 13. Dependency Injection inASP.NET Core • IServiceProvider • Service Lifetimes • Transient • Scoped • Singleton • Add, TryAdd, and TryAddEnumerable
- 14. DI in .NETAzure Functions • Pre-Requisites • Microsoft.Azure.Functions.Extensions • Caveats • The startup class is meant for only setup and registration • The dependency injection container only holds explicitly registered types • Service Lifetimes • Transient • Scoped • Singleton
- 15.
- 16. Azure Durable Functions •Extension of Functions and Web Jobs • Stateful workflows in orchestrator function Client, Orchestrator and Activity • DurableOrchestrationContext , DurableOrchestrationClient • bindings - OrchestrationTrigger, ActivityTrigger • External Events and External Orchestration • Versioning
- 17. Azure Durable Functions- Patterns Function Chaining Fan-out/fan-in Async HTTP APIs Monitoring Human interaction https://docs.microsoft.com/en-us/azure/azure-functions/durable-functions-overview Aggregator
- 18. Azure Durable Functions2.0 • Durable Entities for stateful entities (actor-like) • Durable HTTP for resilient HTTP request within an orchestration • Pluggable state providers • Roslyn Analyzer • Interface and testability improvements
- 19.
- 20. Azure Functions -Proxies • Proxies are created as a new endpoint on function app • Proxy to another resource • Enables microservices on existing large implementation • Dev/Test scenario: Ability to modify request/response
- 21. Key Vault inAzure Functions • Key Vault Integration of config using @Microsoft.KeyVault(<SECRET URI>) • Using assigned managed identities • Access from code using App Principal and SDK
- 22. Testing Functions • Command-linetools • 3rd party products such as Postman and Swagger • Direct web calls via cURL • Web browser • Postman • Microsoft Azure Storage Explorer • Nested functions • Timer trigger • Queue trigger • Visual Studio Cloud Explorer
- 23. Serverless from Amazonand Google • Amazon • Lambda • Google • Google Cloud Functions
- 24. Reference • https://docs.microsoft.com/en-us/azure/azure-functions/ • https://github.com/azure/azure-functions/ •https://functions.azure.com/try • https://github.com/Azure/azure-functions-durable-extension • https://docs.microsoft.com/en-us/aspnet/core/blazor/get- started?view=aspnetcore-3.0&tabs=visual-studio • https://blazor.net • https://azure.com/functions • http://aka.ms/durable/2docs • http://aka.ms/durable/entitysamples • http://aka.ms/durable/circuitsample
Editor's Notes
- #6 What is Serverless? Serverless is a new paradigm of computing that abstracts away the complexity associated with managing servers for mobile and API backends, ETL, data processing jobs, databases, and more. No upfront provisioning - Just provide your code and data, and Google dynamically provisions resources as needed. No management of servers - Get out of the repetitive and error-prone task of managing or automating server management like scaling your cluster, OS security patches, etc. Pay-for-what-you-use - Because of the dynamic provisioning and automatic scaling, you only pay for what you use. Why Serverless Applications with rapid time-to-market and unpredictable scale requirements benefit the most from Serverless. Here are some benefits experienced by Google Cloud Customers: Time-To-Market Improvement - Infrastructure management takes time, so eliminating it means you can get new code to production faster. Infrastructure Cost Reduction - Paying only for what you use means lower costs. Ops Cost Reduction - Automating repetitive provisioning and management tasks means you get to do higher-value devops tasks.
- #7 Azure allocates a preconfigured server from the pool of warm workers to your app. This server already has the Functions runtime running on it, but it is unspecialized. This worker becomes specialized by configuring the Functions runtime in ways that are specific to your app. A few things happen to do this specialization, including: The Azure Functions infrastructure mounts your Azure Files content to the worker you’ve been assigned App settings specific to your function app are applied to the worker The Functions runtime resets, and any required extensions are loaded onto the worker. To figure out which extensions to load, the runtime reads the function.json files of any function in the function app. For instance, this happens if you’re using Durable Functions, or if you have input or output bindings. The functions themselves are loaded into memory by language providers. This will take a varying amount of time based on the size of your application. Your code runs.
- #8 Functions - Code-first (imperative) Flow/Logic Apps - Designer-first (declarative)
- #9 Create a “serverless” event-driven experience that extends the existing Azure App Service platform by building “nanoservices” that can scale based on demand Azure Functions are “event-driven” meaning they run based on associated and configure events, or “triggers”. For example an Azure Function could be triggered by a simple timer, such as running a process once every 24-hours, or triggered by an event in a document management system, such as when a new document is uploaded to a SharePoint library. Azure Functions can also respond to Azure-specific events, such as an image added to a Storage Blob or a notification arriving in a Message Queue.
- #11 Without bindings, an Azure Function would just be a “disconnected” algorithm without any way to serve a purpose. Bindings server to connect functions and output to other services. Some of the most common binding types and features are listed in the table, however variations and adaptations can and do exist.
- #13 IOC (Inversion of control) is a general parent term while DI (Dependency injection) is a subset of IOC. IOC is a concept where the flow of application is inverted IoC is a generic term meaning rather than having the application call the methods in a framework, the framework calls implementations provided by the application. DI is a form of IoC, where implementations are passed into an object through constructors/setters/service lookups, which the object will 'depend' on in order to behave correctly. Advantages Dependency injection allows a client the flexibility of being configurable. Only the client's behavior is fixed. Dependency injection can be used to externalize a system's configuration. Dependency injection doesn’t require any change in code behavior Dependency injection allows a client to remove all knowledge of a concrete implementation that it needs to use. This helps isolate the client from the impact of design changes and defects. It promotes reusability, testability and maintainability Reduction of boilerplate code in the application objects, since all work to initialize or set up dependencies is handled by a provider component Dependency injection allows concurrent or independent development. Two developers can independently develop classes that use each other, while only needing to know the interface the classes will communicate through. Dependency Injection decreases coupling between a class and its dependency. Disadvantages Dependency injection can make code difficult to trace (read) because it separates behavior from construction. Dependency injection frameworks are implemented with reflection or dynamic programming. Dependency injection can encourage dependence on a dependency injection framework.
- #14 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.0
- #15 https://github.com/fabiocav/azfunc-di-demo https://channel9.msdn.com/Shows/On-NET/Leveraging-the-Dependency-Injection-support-in-Azure-Functions The startup class is meant for only setup and registration. Avoid using services registered at startup during the startup process. For instance, don't try to log a message in a logger that is being registered during startup. This point of the registration process is too early for your services to be available for use. After the Configure method is run, the Functions runtime continues to register additional dependencies, which can affect how your services operate. The dependency injection container only holds explicitly registered types. The only services available as injectable types are what are setup in the Configure method. As a result, Functions-specific types like BindingContext and ExecutionContext aren't available during setup or as injectable types.
- #16 Web Assembly is underlying technology where browser can execute exes; BLAZOR is .NET implementation .NET in the browser Blazor lets you build interactive web Uis using C# instead of JavaScript Can use WebAssembly to run .NET in a client-side browser dotnet new blazorwasm
- #17 Durable Functions is an extension of Azure Functions and Azure WebJobs that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints, and restarts for you. Versioning: Do nothing, Stop all in-flight instances, Side-by-side deployments Durable Entities, Examples and Scenarios You can use three durable function types: client, orchestrator, and activity. Client functions are the entry point for creating an instance of a Durable Functions orchestration. They can run in response to an event from many sources, such as a new HTTP request arriving, a message being posted to a message queue, an event arriving in an event stream. You can write them in any of the supported languages. Orchestrator functions describe how actions are executed, and the order in which they are run. You write the orchestration logic in code (C# or JavaScript). Activity functions are the basic units of work in a durable function orchestration. An activity function contains the actual work performed by the tasks being orchestrated Workflow function -- Durable Function Type Submitting a project design proposal for approval --Client Function Assign an Approval task to relevant member of staff --Orchestration Function Approval task --Activity Function Escalation task --Activity Function
- #18 Durable Functions is an extension of Azure Functions and Azure WebJobs that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints, and restarts for you. Pattern #1: Function chaining Function chaining refers to the pattern of executing a sequence of functions in a particular order. Often the output of one function needs to be applied to the input of another function Pattern #2: Fan-out/fan-in Fan-out/fan-in refers to the pattern of executing multiple functions in parallel, and then waiting for all to finish. Often some aggregation work is done on results returned from the functions. Pattern #3: Async HTTP APIs The third pattern is all about the problem of coordinating the state of long-running operations with external clients. A common way to implement this pattern is by having the long-running action triggered by an HTTP call, and then redirecting the client to a status endpoint that they can poll to learn when the operation completes. Pattern #4: Monitoring The monitor pattern refers to a flexible recurring process in a workflow - for example, polling until certain conditions are met. A regular timer-trigger can address a simple scenario, such as a periodic cleanup job, but its interval is static and managing instance lifetimes becomes complex. Durable Functions enables flexible recurrence intervals, task lifetime management, and the ability to create multiple monitor processes from a single orchestration. Pattern #5: Human interaction Many processes involve some kind of human interaction. The tricky thing about involving humans in an automated process is that people are not always as highly available and responsive as cloud services. Automated processes must allow for this, and they often do so by using timeouts and compensation logic. Pattern #6: Aggregator (preview) 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. The tricky thing about trying to implement this pattern with normal, stateless functions is that concurrency control becomes a huge challenge. Not only do you need to worry about multiple threads modifying the same data at the same time, you also need to worry about ensuring that the aggregator only runs on a single VM at a time.
- #19 Microsoft.Azure.WebJobs.Extensions.DurableTask - 2.0.0-beta2 Microsoft.NET.Sdk.Functions- 1.0.29
- #23 Many Azure Functions are exposed via an actual URL that can be called directly from a web client or browser. When an Azure Function is not exposed via a URL its common practice to call the function from another dunction, such as a Timer-based Function for testing purposes only. Since Azure Functions can be nested, testing scenarios can be quite varied. For managing and testing Azure Functions that integrate with Storage Containers, Microsoft provides the Microsoft Azure Storage Explorer, as well as the Visual Studio Cloud Explorer. The Logs console in the Azure Function Designer is also a great way to view and trace function processing.
- #25 .net, javascript durable entity,actor can only be .net sdk we also working on python support logic app declarative vs durable functions functions is own flavor of sdk az functions .net core 3 actor=a class that can contain state and modifes that state by processing messages it receives actor reference=a handle to an actor. alows you to send the actor messages without knowing its implementation type or location on network Actor system=a collection of actors that exist inside a signgle process and communicate via in-memory message passing cluster=a collection of networked actor systems whose actors communicate via TCP message passing https://docs.microsoft.com/en-us/samples/browse/?products=azure&term=functions https://github.com/Azure/azure-functions-durable-extension/tree/v2/samples/v2/entitites-csharp/Chirper