Azure Functions creates a “serverless” event-driven experience, meaning that 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 in a certain interval or triggered by an event in an external system. 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.
2. Who am I?
• Udaiappa Ramachandran ( Udai )
• CTO, Akumina, Inc.,
• Consultant
• Focus on Cloud Computing
• Microsoft Azure, Amazon Web Services and Google
• New Hampshire Cloud User Group (http://www.meetup.com/nashuaug )
• http://cloudycode.wordpress.com
• @nhcloud
4. The evaluation of application platforms
• On-premises
• IaaS
• PaaS
• Serverless
5. Serverless
• What is serverless?
• Abstraction of servers
• Event-driven
• Micro-billing
• Benefits
• Automatically Scale
• Focus on business logic
• Faster time to market
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 languages
• 1.x – C#, Javascript, F#
• 2.x – C#, Javascript, F#, Java
• Pay-per-use pricing model
• Bring your own dependencies
• Integrated security
• Simplified integration
• Flexible development
• Open-source
• Flexible AppService Plan
• Consumption
• Dedicated
9. Triggers and Bindings
Bindings serve as the basis for
all connections to and from a
function. Many bindings can be
“bi-directional” as well
10. Common Scenarios
• 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
11. 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
12. Azure Durable Functions
• Extension of Functions and Web Jobs
• Stateful workflows in orchestrator function using DurableOrchestrationContext ,
DurableOrchestrationClient
• bindings - OrchestrationTrigger, ActivityTrigger
• External Events and External Orchestration
• Versioning
13. 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
14. Testing Functions
• Command-line tools
• 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
15. Demo
• Download Slide from
• https://www.slideshare.net/UdaiappaRamachandran
• Hands-On-Lab from Microsoft Technical Content
• http://bit.ly/2H956sc
• http://bit.ly/2EV6uZz
• https://azure.microsoft.com/en-us/resources/samples/?service=functions&sort=0
• Download Source from
• https://github.com/nhcloud/techtalk
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.
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.
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.
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 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.
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.