In this first part of a multi-series blog, I will explain why and how we should use Azure Functions and PowerShell together. Next, I will show you how to deploy a PowerShell based Function.
Azure Functions is a serverless compute service that allows you to run small pieces of code (called “functions”) without worrying about application infrastructure. The code that you deploy to a function will be executed based on a specific event. So a function is triggered by a specific type of event.
Azure Functions is a great solution to perform a particular task and to do that task as effectively as possible!
Let’s start with the beginning. Serverless computing, or in short serverless, is a cloud computing code execution model in which the cloud provider fully manages the infrastructure needed to serve requests.
Those requests are billed by calculating the CPU, Memory and I/O required to satisfy the request rather than on a per virtual machine, per hour basis.
Only manage code
There are several characteristics and benefits of serverless. First, creating and managing code and applications, and not servers or other infrastructure.
With Serverless, the focus is on creating and managing code and applications, not servers or other infrastructure!
Be aware that the term serverless doesn’t mean that there are no servers, there are certainly servers involved. However, we could say less servers then serverless. The responsibility for keeping those servers up and running, patching the OS layer, scaling when needed is all managed by Microsoft.
Use other Azure services
Another advantage of serverless technologies is a tight integration of other services in Azure. Think about networking, messaging technologies, relational or no-sql databases, object or blob storage, monitoring and telemetry.
- Blob storage
- Cosmos DB
- Event Grid
- Event Hubs
You can find all supported services here.
Only pay for execution
Because the smallest meaningful outcome of serverless computing is a single Function, pricing can be scoped just only for that function as well. With serverless, you only pay for compute resources used during execution of the code.
Does that sound like Platform as a Server (PaaS) or Infrastructure as a Service (IaaS)? It sort of is, but a finer-grained level. When you provision a PaaS or IaaS resource (such as a virtual machine), you are billed for the duration of VM uptime and running state. So regardless if your code is actually running during that uptime or not and whether the VM is 20% or 80% utilized, you pay the same price for that entire VM. By contrast, with serverless, you will be billed only for the resource execution time and resource consumption.
Code that only runs when it is needed, can achieve cost savings in a serverless deployment model versus a VM centric one.
Let’s go ahead and look at how Azure Functions work.
Azure Functions key concepts
Functions are event-driven and the focus of Functions are really code-based. You can think of a function as a little piece of code that gets executed when you need it.
Azure Functions are typically not complete or full-featured applications. Instead, functions handle specific, short-lived tasks. Another well known Serverless option in Azure is Azure Logic Apps . Logic Apps are also event-driven, but it are more focused on organizing a flow between API’s and different services. Logic Apps are less code.
When you’re writing Azure Functions, the core component that you’re dealing with is a Function App. Azure Functions are an extension of Azure App Service, so if you want to know all the features this service has to offer, you can read more about that on docs.com.
The Function App is your unit of deployment, it’s your unit of development and it’s also the unit of scale. So a single app will be scaled as a unit.
You can have multiple functions in an app but your app is your primary unit of development, deployment and scale.
Let me show you how that looks in the Azure Portal.
Go to the Azure Portal and search for Function App.
In the Azure Portal you can see a list of all the Function Apps you have.
If we select a Function App, and then go to functions on the left navigation menu, you can see a list of all the functions in your Function App.
As you can see, a Function App can have more then 1 Function in it.
Now that we know that a Function is some piece of code, let’s see how we can execute our code within our Function.
That’s when Triggers come into play!
A Trigger is an event or situation that causes something to start. This something can be some sort of processing of data or some other service that performs some action. A Trigger will pass some basic information to the code, in order to run. And when the code has completed, it has some output.
Important to know is, that all of the functions will have a trigger!
You can see a trigger as the event source that a Function is listening for, and the data that will be passed in, to let your function know that is has to execute.
Every function can only have one trigger! And the service itself will automatically be listening to that source.
Good to know is that you are not charged when a Functions is listening to something like a cue, waiting for a message to drop. You are only charged once that trigger fires and your code actually runs.
Triggers are what cause a function to run!
If we look at the options we get when creating a new Function in the Azure Portal, we see a list of Template Triggers.
Triggers can have the form of:
- Incoming HTTP requests
- Creation or modification in a storage account
- The arrival of a message on a queue
Another common option is the ability to invoke serverless logic on a timer. This can be useful for writing serverless functions to perform specific time based tasks like:
- Cleaning up old Azure resources
- Moving data to another storage tier
- Applying tags when needed
The preceding example shows the event that fires the trigger. The event here, is when a File has been added to a Blob storage. Once the trigger is fired, it runs the Azure Function associated with it. In this case, it runs some PowerShell code that Outputs another file. The output of the Function is placed on another Blob storage.
You can see that Azure Functions have a simplified integration where binding to triggers, inputs and outputs is very simple!
Bindings you say? What are bindings?
Well, bindings are data that you can pull in, or push out of your function without having to integrate with that service directly inside your code. Like in the example, we bind our trigger to a File that has been uploaded to Blob Storage. We don’t need to write code that creates that logic.
These are the most popular triggers and bindings:
We have two types of bindings:
- Input Bindings: Data that is pulled in at the start of an execution. You can have multiple input bindings.
- Output Bindings: Data that is pushed out after an execution. You can have multiple output bindings.
Binding to a function is a way of declaratively connecting another resource to the function. Bindings may be connected as input bindings, output bindings, or both. Data from bindings is provided to the function as parameters.
You can find all Triggers and Bindings here.
With the support of PowerShell in Azure Functions, we have a lot of opportunities for serverless automation tasks in production. We can now take advantage of the event-driven programming model for infrastructure management and scripting tasks across Azure and hybrid environments!
In part 2 of this blog-series, I will explain how to create a Function and executes some powershell code!