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.
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.
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.
- 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.
funcand the help/usage should be displayed.
func azure account listwhich, 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 setif needed).
- 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).
- Enter into the function app direction:
- Create a new function:
- 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
console.logas may be expected in other FaaS solutions.
console.log()will not work as you expect due to the architecture of Azure Functions.)
- 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.
- 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”.
- Browse to http://localhost:7071/api/HttpTriggerJs?name=Earl and should receive a response of “Hello Earl”.
- Switch to the PowerShell window running the local server. Logs of interaction and execution are scrolled through this window and can help with troubleshooting.
- 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.
- 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.
- 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.
- 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.
- Once the Function App is deployed within Azure, publish the local Function App to it with:
func azure functionapp publish name-azfn-app1.
- 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!
For more information on Azure Functions, check out:
- Microsoft’s Azure Functions Documentation
- PluralSight’s Azure Functions Fundamentals Course
- Udemy’s Getting Started with Azure Functions Course
- PluralSight’s Build a Serverless Node Web API with Azure Functions Course