Microsoft’s Serverless Glue: Azure Functions

Combining Events ( ⚡) and Code (</>) is the story behind Azure Function’s purpose and logo. Similar to AWS Lambda or Google Cloud Functions, Azure Functions is Microsoft Azure’s Functions-as-a-Service (FaaS) offering, but the logo is just the tip of the iceberg of Azure Functions’ awesomeness.

The Azure Functions Logo

Azure Functions’ architecture is actually fairly unique compared to its’ counterparts, and with that comes some unique benefits. As the evolution of Azure’s Web Apps and Web Jobs, Azure Functions inherit much of the functionality: Continuous Integration, Kudu, Authentication, Certificates, Custom Domains, etc.; that means it has a lot of great, mature features in the platform. There are also two options from an OS perspective: Windows and Linux (Preview).

While it may spawn debates on serverlessness in the latter option, Azure Functions has two types of “Hosting Plans”: Consumption (based on usage, which is traditionally what you think when you think FaaS) and App Service (where you can leverage servers in an App Service plan). While arguably less “serverless,” the App Service plan provides predictable costing and is a model not available with AWS Lambda or Google Cloud Functions.

Azure Functions is also open source (there are links to the component repositories inside this parent repository), though I don’t know of any forks or implementations of the codebase outside of Microsoft’s usage. The FaaS solutions from Google and Amazon are not open source, though they do have some open source components within them; IBM’s Cloud Functions is based on the open source Apache OpenWhisk project.

Azure Functions are grouped into “Function Apps” which then house multiple functions themselves inside them. The interface and topology is much different from how AWS Lambda and Google Cloud Functions appear; while speculation on my part, I suspect this is based on Azure Function’s architecture built on the back of the Windows platform whereas the others were built on the back of Linux platforms. With that said, I don’t think the difference is particular worse or better, just different and may take someone used to the other FaaS offerings a second to get their bearings.

Azure Functions exist under the Compute section of the Azure Portal

Azure Functions supports a fairly wide range of triggers and languages. From the trigger perspective, Azure Functions supports: Blob Storage, HTTP, Azure Cosmos DB, Timer, Webhook, Queue Storage, Service Bus Queue / Topic, Event Hub, Event Grid, External File. From a language perspective, Azure Functions supports: C#, F#, Javascript, as well as the following “Experimental” languages: TypeScript, PHP, PowerShell, Python, Bash; experimental languages are noted by Microsoft to not scale well and not support all bindings. Despite that large language list, if you like examples from Microsoft’s online documentation, I hope you like C#!

Joking aside, JavaScript has full-featured support and we’ll run through creating a quick example function with an HTTP Trigger using JavaScript and the Azure Functions Core Tools (as opposed to the Azure Portal, which is fairly straightforward).

Azure Functions Core Tools CLI

Prerequisites / Assumptions: These steps are performed using Windows / PowerShell (there are some differences between the 1.x and 2.x Azure Functions runtimes, but for the purpose of this we will be using 1.x as it is the only supported production version). Please also ensure NodeJS 8.x/npm are installed, as well as Visual Studio Code. Install the .NET Core SDK to enable debugging the Function in VS Code.

We’ll create, test, debug, and publish an Azure Function locally!
  1. Launch PowerShell (as Admin to install the tools) and execute: npm install azure-functions-core-tools -g. Launch a new non-privileged PowerShell terminal after installation completes.
  2. Type func and the help/usage should be displayed.
  3. Type func azure account list which, if not already logged in, will open a browser window to prompt for Azure credentials. It will then list subscriptions (which can be changed with func azure account set if needed).
  4. Initialize a new local Functions project with func init azure-func-app1. This will create a new git-enabled directory called azure-func-app1 with skeleton files: .gitignore (determines which files and directories for git to ignore), host.json (metadata file contains global configuration options that affect all functions for a function app), local.settings.json ( stores app settings, connection strings, and settings for Azure Functions Core Tools), launch.json (debugging configuration information for VS Code).
  5. Enter into the function app direction: cd azure-func-app1.
  6. Create a new function: func function create. Select: JavaScript as language, HTTP trigger as trigger, HttpTriggerJS as name. It will create the following within a child directory named after the chosen function name: index.js (function handler code), sample.dat (sample for the trigger), function.json (defines the function bindings and other configuration settings).
  7. From here, it’s easier to edit the code within VS Code. Launch a VS Code session with: code . — from there you can either edit the function by modifying the index.js or just leave it as the sample code which will respond with “Hello <name>”. (Side note: In the sample code that it uses context.log() instead of console.log as may be expected in other FaaS solutions. console.log() will not work as you expect due to the architecture of Azure Functions.)
  8. Back in PowerShell inside the azure-func-app1 directory, run func host start --debug vscodeand when the Windows Security Alert pops up, select Allow access to allow the server to run. The server should launch and show the trigger running on: http://localhost:7071/api/HttpTriggerJs as well as the Debugger listening on [::]:5858.
  9. Browse to http://localhost:7071/api/HttpTriggerJs and you should receive a response to “Please pass a name on the query string or in the request body”.
  10. Browse to http://localhost:7071/api/HttpTriggerJs?name=Earl and should receive a response of “Hello Earl”.
  11. Switch to the PowerShell window running the local server. Logs of interaction and execution are scrolled through this window and can help with troubleshooting.
  12. Try editing index.js and saving it (e.g. add a comma after Hello in the response). Reload your request in your web browser and it should now show the new response. Note that you didn’t have to relaunch your local server, but just save the file and it auto-updates the local function — this speeds up development process.
  13. Within the VS Code window that was launched, let’s use the debugger. Select Debug from the left menu (or press Ctrl+Shift+D). Ensure “Attach to Azure Functions” is within the drop down and then select the green play button to Start Debugging.
  14. Add a breakpoint on line 4 by right-clicking the space to the left of the line number and clicking “Add Breakpoint” — a red dot should appear. Now, browse to http://localhost:7071/api/HttpTriggerJs?name=Earl again. The debugger should catch the request and break where selected. Let’s check out the “req” variable that will be checked in this if statement: expand req query name and it should be set to “Earl” as expected.
  15. Press the green play button at the top of the window (or press F5) to continue through the function; the response should now appear in the browser window. This debugging integration also speeds up the development process! (Side note: Debugging in VS Code only works for Javascript; to debug C#, use Visual Studio.)
  16. Deploy a shell Function App through the portal or whatever means desired. To do so via the Portal, browse to Create a Resource → Compute → Function App. Enter a globally unique App Name (e.g. name-azfn-app1), select the Subscription that was selected at the command line by Azure Functions Core Tools, and either configure the rest or leave it as defaults. It takes a few seconds to a minute to deploy.
  17. Once the Function App is deployed within Azure, publish the local Function App to it with: func azure functionapp publish name-azfn-app1.
  18. Browse to the Azure Portal and the HttpTriggerJS function should be deployed. Select the function and click “</> Get Function URL” at the top next to “Run”. The URL should look like https://name-azfn-app1.azurewebsites.net/api/HttpTriggerJs?code=XXXX. Try running it with and without “&name=Earl” on the end of the URL and it should behave the same as the local function.

Tada! You’ve now gone through the process of creating an Azure Function locally, testing it, debugging it, and deploying it to Production!

Debugging an Azure Function inside Visual Studio Code

For more information on Azure Functions, check out:

Like what you read? Give Earl Gay a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.