Everybody loves Azure Functions. My team recently deployed a production service using Azure Functions as the back end backbone. I’d like to share some lessons and tips we learned along the way. We’re using Azure functions in consumption plan – which basically means the platform scales in and out as required without our intervention. But […]
We looked at Azure Functions. We also looked at security around Azure Function used to implement APIs. Something people will quickly notice when implementing an Webhook / API function is that its URL or route is always prepended by /api. For instance, if we create a webhook function in C# and we setup the route […]
If you want to create an Azure Resource Manager (ARM) template that deploys Functions or Logic Apps, you can build your own as shown here. Just provide your GitHub repository URL and it will quickly create an azure.deploy.json file for you to include with your repos.
These samples are available in a either C# or NodeJS and can be deployed to your Azure subscription with a click of a button. The samples cover a number of useful tasks that can easily be incorporated into your application or simply used for learning purposes. If you’re interested in contributing to this project or browsing through the code please take a look at the GitHub repository.
In my previous post “Introduction to Azure serverless with Azure Functions, Logic Apps and Azure Event Grid” I briefly introduced each of those services from Azure. In this post I’ll show you how you can try Azure Functions for free without signing up for an Azure subscription. Let’s get started.
Microsoft has setup a free sandbox environment for trying out Azure Functions for free. Navigate to the free trial link and select the function you want to create:
After clicking on the Create this function button you will be asked to choose an auth provider. Any will do and it’s just needed to get some basic information for the trial. No credit card information is required:
After a few seconds you should see your new HttpTrigger C# function (based on the selection from the previous screen). Click on the Run button to see your function run. From this portal you can edit your function code and save the changes, run the function and view the logs from the, test your function with different input, and see the output and status.
Your function also has a URL you can use to run your function outside of this portal. Go to the top right corner and click on Get function URL:
You will then see the get function URL modal with the key and URL. Click on the copy link and then open up another browser tab or use it within Postman:
Paste your function link and then add the required query string parameter Name with a value. You should then see the output of your function like so:
This environment is limited in what you can do. So although you can change your function code and the integrations it works with, you are prevented from managing your function app. You also only have only 59 minutes to try it out.
As you can see you can quickly try out Azure Functions in a sandbox environment. If and when you’re ready you can move to an Azure subscription where you can fully manage your Azure Function and get access to a world of other resources to use with your function app. It’s worth mentioning that with your Azure subscription you get access to a number of Azure resources for free within certain limits…including Azure Functions. So take a look and give Azure Functions a try.
In this blog post I’ll introduce you to what is serverless and then what services in Azure provide serverless capabilities. First let’s define what is serverless.
What is the definition of Serverless
- It’s an abstraction of servers. This doesn’t mean there are no servers, there are still servers behind the scenes but this means you don’t need to worry about optimizing which OS to run, about OS patching, etc. You also don’t need to worry about optimizing utilization and scaling up and down for demand. Think of it as less server more code.
- It’s an event driven process. You simple tell Azure how or when to run your code. This could be based on a schedule or when a new customer is added to Salesforce, or when items are added to a queue, to a table storage, etc.
- It’s micro-billing. This means you’re only charged for your usage.
The benefits of serverless
- Reduced DevOps – You can dynamically and elastically scale to meet demand.
- Focus on Business Logic – Allows you as the developer to focus on your business logic and everything else is taken cared of for you. No need to provision resources and wait on ITOPS. In some cases you can design and develop your serverless code offline.
- Faster Time to Market – By focusing on your business logic and features, you’re able to drastically increase time to market.
Let’s now look at three Azure services that provide serverless capabilities.
1. Azure Functions
Azure Functions is an event driven, compute-on-demand experience. You can easily and quickly build the apps you need using simple serverless functions that scale and meet demand and you only pay for your usage.
Azure Functions allows you to bind into services. This means you can integrate Azure Functions into Cosmos DB, Logic Apps, queues, table storage, on premise and so much more.
With Azure Functions you simply provide your code and then let Azure take care of the rest…meaning that when an event happens, Azure will automatically take care of everything to run that code at scale.
2. Logic App Service
Azure Logic Apps are built around the idea of events, triggers and workflows. When you think about building microservices, there are a lot of moving parts to manage. Azure Logic Apps lets you stitch them all together much more easily and provides you with a central place to build and manage all of your event-driven services.
Logic Apps are a fully managed iPaaS (integration Platform as a Service) that provide serverless workflows that allow developers to easily integrate data with their apps instead of writing complex glue code between disparate systems. This allows you to orchestrate and connect the serverless functions and APIs of your applications.
Benefits of Logic Apps
1. You can quickly tap into the power of the cloud and fire events from other services.
2. You can orchestrate almost anything:
- Run mission-critical, complex integration scenarios with ease
- Connect on-premises, hybrid and cloud applications
- Position for future with API centric connectivity
- Easily connect custom on-premises applications to the cloud
At the time of this post there are over 200 connectors available out of the box. Connectors reduce integration challenges and enable you to quickly and easily connect apps, data and devices anywhere.
Creating a Logic App
The following is a sample Logic App. As you can see you simply string together Connectors, Triggers, Conditions and Actions to form the basis of your Logic App. When your Logic App is running you can monitor and inspect each run iteration and see what data came in and the path it took through the Logic App.
In summary Logic Apps is the workflow engine built for the cloud with cloud scale, massive compute and high availability built in.
3. Azure Event Grid
Finally there is Azure Event Grid which is a messaging service built to easily build application with event-based architectures. You simply select the Azure resource you would like to subscribe to, and give the event handler or webhook endpoint to send the event to. Event Grid also has built-in support for events coming from other Azure services, like resource groups, subscriptions, storage blobs, and event hubs.
Topics and Subscriptions
Event Grid is similar to Azure Service Bus in that a Topic is an endpoint that receives messages, and a Subscription is used to receive messages through the Topic that will be handled by a message listener. These concepts are basically the same, but there are some differences in how they work. Event Grid it uses a concept of events instead of messages since it’s an event-based messaging system, and because Event Grid is based on events, it lends itself nicely to microservice architectures using serverless compute options like Azure Functions and Logic Apps in addition to other implementations.
There are also more differences between Azure Event Grid and other message queue services. The capabilities of Azure Event Grid are centered around speed, scale, breadth, and low cost. Rather than being a general / generic messaging service, Azure Event Grid is built specifically for Serverless architectures.
Currently Azure Event Grid has built in support for the following event publishers:
- Event Hubs
- IoT Hubs
- Blog Storage
- Custom Topics
- Azure Subscriptions (management operations)
- Resource Groups (management operations)
Currently the following Azure services have built-in handler support for Event Grid:
- Azure Functions
- Logic Apps
- Event Hubs
- Azure Automation
- Microsoft Flow
If using Azure Functions as your handler, use the Event Grid trigger over the generic HTTP trigger as it automatically validates Event Grid Function triggers.
Azure Event Grid is built specifically for Serverless architectures.
Event Grid Architectures
Azure Event Grid is designed to be used in microservices and event based architectures. It can be used in a serverless application to connect data sources and event handlers. In an ops automation scenario you can notify Azure Automation when virtual machines are created, or when a SQL database is spun up. Finally you can use Event grid to connect your application with other services. The possibilities are really limited by your imagination.
As you can see all three services provide a different component to the serverless story and each of them integrate nicely with each other. They each allow you to think less about the server and more about your code and you only pay for your usage. The best way to learn about these Azure serverless offerings is to create a free Azure account and try it out yourself.
Attribution: This post uses one or more graphics from the official Azure Event Grid documentation, such as diagrams.
Last week I did a presentation on Azure Functions at Canada’s Technology Triangle .NET User Group (CTTDNUG) in Kitchener, Ontario. One of the audience members was kind enough to film the presentation and post it on YouTube.
Here is a link to my presentation on An Introduction to Serverless Compute with Azure Functions.
In this post I’m going to answer a question someone asked me recently when I presented an Introduction to Azure Functions – can we return JSON from the HttpTrigger function? The answer is yes and it’s not limited to the Http trigger function and I’ll walk you through one of many ways to do this.
First let’s start off by taking a look at the output that shows up by default from the HttpTrigger Function I had created in the Azure portal. As you can see the default output is XML as shown here:
The same goes for the response when the require “name” parameter is missing in the query string or the body of the request:
You might think that there is a simple property in the Azure Function properties to configure the output, but there isn’t, at least at this point in time with version 1 runtime.
Creating a C# Http Trigger Function
Let’s quickly create an Azure Function in the portal and I can show you one of many ways to return JSON from your Azure Function.
1. Create a new Serverless Function App:
2. Once your Azure Function app is running, create a new C# Http trigger function and then provide it a name and authentication model:
3. Now that your function is created you will see the following code in the run.csx file. If you run it you will get XML as your response, so let’s go ahead and update this function to return JSON.
Changing the return type to JSON
For this example I’ll import Newtonsoft.Json package and then serialize a simple object to return back when the function is called.
1. Add Newtonsoft.Json package and other using references:
2. Update function code to use Newtonsoft.Json. Looking at the following code you will see that I’ve created a simple POCO object which is what I’ll be returning from the function. I then changed the response to return a serialized string in UTF8 encoding and application/response:
3. Now when we run the function through either the browser or Postman we’ll see the response in JSON format. Here is what we would see in Postman:
and then in a browser we would see this:
Azure Functions is a powerful component in Azure serverless offering and as you can see your not limited to XML as the only response format.
Let me know if you have any questions and I’d be happy to investigate and follow up.