5. Agenda
• Journey to Azure Functions
• Developing Azure Functions in Azure Portal
• Developing Azure Functions with Visual Studio
• Hosting and pricing
• Typical usage scenarios
6. App Service
• Hosting applications inside of IIS (Internet
Information Services) on Windows
• Needs an App Service Plan
• The App Service Plan defines the hardware resources
• Made to support mainly web applications
• Difficult to run
• Batch processing
• Scheduled tasks
• Long-running processes
7. Web Jobs
• Built-in triggers
• Azure Storage Queue
• Service Bus
• Schedule tasks
• Needs an App Service Plan
• The App Service Plan defines the hardware
resources
• Difficult to scale
10. Azure Functions
• More triggers
• Cosmos DB
• Event Hub
• HTTP
• Web Hook
• Pay-per-use
• Doesn’t need an App Service Plan
• Although can run on a App Service Plan too
• Easy to scale
22. Azure Functions Tools for Visual
Studio
• Edit, build, and run
functions locally.
• Publish directly to Azure.
• Use attributes to declare
function bindings directly in
the C# code.
• Develop and deploy pre-
compiled C# functions.
• Included in the Visual
Studio 2017 version 15.5
23. Azure Function App
• Based on .NET class
libraries
• Get the full power of
IntelliSense, unit testing,
and local debugging
29. Azure Functions hosting
• Consumption plan
• Instances are dynamically added and removed.
• Pay only when your functions are running.
• Scale out automatically, even during periods of high load.
• App Service plan
• Function apps run on dedicated App Service VMs.
• Pay for the utilized resources under the App Service plan.
• Functions can run longer than the maximum execution time
allowed on the Consumption plan (of 10 minutes).
30. Azure Functions scaling
• Up to 200
instances.
• A single instance
may process more
than one message
or request at a
time.
• New instances will
only be allocated
at most once every
10 seconds.
31. Azure Functions billing
• Based on per-second resource consumption and
executions
METRIC PRICE FREE GRANT (PER
MONTH)
Execution Time* $0.000016/GB-s 400,000 GB-s
Total Executions* $0.20 per million
executions
1 million executions
34. Usage 1 – as Web API
• HTTP Trigger Function == Web API Action *
// Endpoint URL: /api/products/{id}
public static async Task<HttpResponseMessage> Run(
[HttpTrigger(AuthorizationLevel.User, "get", Route = "products/{id}")]
HttpRequestMessage req,
int id, TraceWriter log)
{
var msg = new { Id = id, Message = "Hello World" };
return req.CreateResponse(HttpStatusCode.OK, msg);
}
// Endpoint URL: /products/{id}
[Route("products/{id}")]
[HttpGet]
public async Task<IActionResult> GetProduct(int id)
{
var msg = new { Id = id, Message = "Hello World" };
return Ok(msg);
}
* Except that is not!
35. Usage 1 – as Web API
• Functions are always static methods.
• Functions always receive HttpRequestMessage instance as
a parameter.
• DI not natively supported!
• Benefits in scaling and maybe in pricing due to micro
billing.
36. Usage 2 – for scheduled tasks
• Only one instance
runs at a time.
• Executions do not
overlap.
• Timer history
kept in storage.
37. Usage 3 – for backend event-based
processing
• Email when VM
changes.
• By using Azure Event
Grid.
• Process uploaded
images.
• By using Blob Trigger.
• Respond to Service
Bus event.
• By using Azure
Service Bus.
WebJobs
WebJobs were the first attempt to solve this problem. WebJobs have built-in triggers for a number of different events inside of Azure: storage queues, blobs, service bus queues, topics and schedule triggers.
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it.
Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Java, or PHP.
A developer can deploy a piece of code as a Function in Azure. The function is triggered in some way to spawn an instance of execution. One can view Functions as a successor to Web Jobs that were based on an App Service Plan.
Abstraction of servers, infrastructure and configuration of operating system
Event-driven scale
Sub-second billing
Stateless
Serverless compute is a fully managed service. Some refer to it as Functions as a Service
OS and Framework patching is performed for you
There is zero administrative tasks and no need to manage any infrastructure
You just deploy your code (function) and it runs
Your code runs within seconds and for very short period of time
Serverless compute scales quickly (almost instantly) and vastly
Automatically scales within seconds
No scale configuration is required (there is no way to configure scale or limits)
Scales to match any given workload. Scales from zero to handle tens of thousands concurrent functions invocations within seconds
Pay only for the time your code is running
Serverless compute reacts to events
React, in near real-time, to events and triggers
Triggered by virtually any event from Azure service or 3rd party services
Setup time, provisioning is long & costly
The experimental languages in version 1.x don't scale well and don't support all bindings. For example, 1.x Python is slow because the Functions runtime runs python.exe with each function invocation. And while Python supports HTTP bindings, it can't access the request object.
Experimental support for PowerShell in 1.x is limited to version 5.1, because that is what's installed by default on the VMs on which function apps run. If you want to run PowerShell scripts, consider Azure Automation.
The Scale Controller monitors the rate of events and determine whether to scale out or scale in.
The scale controller uses heuristics for each trigger type.
Executions
Functions are billed based on total number of requested executions each month for all functions. Executions are counted each time a function is executed in response to an event, triggered by a binding. The first million executions are included free each month.
Resource consumption
Functions are billed based on observed resource consumption measured in gigabyte seconds (GB-s). Observed resource consumption is calculated by multiplying average memory size in gigabytes by the time in milliseconds it takes to execute the function. Memory used by a function is measured by rounding up to the nearest 128 MB, up to the maximum memory size of 1,536 MB, with execution time calculated by rounding up to the nearest 1 ms. The minimum execution time and memory for a single function execution is 100 ms and 128 mb respectively. Functions pricing includes a monthly free grant of 400,000 GB-s.
Functions are always static methods. => Some architecture considerations.
HttpRequestMessage instance as a parameter. => pipeline is very different.
DI not natively supported. => Must use ServiceLocator or home made solutions.
Functions are always static methods. => Some architecture considerations.
HttpRequestMessage instance as a parameter. => pipeline is very different.
DI not natively supported. => Must use ServiceLocator or home made solutions.
Functions are always static methods. => Some architecture considerations.
HttpRequestMessage instance as a parameter. => pipeline is very different.
DI not natively supported. => Must use ServiceLocator or home made solutions.
