Awfully Thorough Guide to Choosing the Best Serverless Solution, Part 1.2: Azure Functions
So far we’ve examined AWS FaaS service. In this blog post we’ll deep dive into Azure FaaS offer, aka Azure Functions.
Previous Post in FaaS Series
Microsoft Azure Functions
Despite previously offering other PaaS solutions (back in the day this was another way to describe “serverless”) much earlier than AWS, Microsoft announced its Azure FaaS more than a year after AWS, only in March 2016 In keeping with its latest trend of going open-source, the underlying internals of Azure are also open-source and accessible on GitHub. The concept is the same: small independent pieces of code that react to event triggers. The implementation, however, is quite different.
Note that a new function is not a standalone resource but part of a bigger “Function App,” but we won’t address it in this post.
Neither ACL nor any other security feature is defined despite the fact that unlike AWS Lambda, it does have a publicly-accessible URL endpoint straight out of the box. The choice of the underlying OS is also a differentiator (which, one might say, contradicts the whole concept of serverless), as is a concept of a storage, something totally missing in Lambda. A ridiculous “Hosting” dropbox will cause trouble as we’ll go on to explain.
To summarize — there are a lot of not-so-serverless settings when creating a new Azure Function, but security is surprisingly lacking.
Unlike Lambda, Azure Functions has only two built-in triggers: HTTP request and a scheduled run. Any other triggers, like message queues, DB or even Twilio SMS, should be separately installed and used via a separate GUI.
Language support capabilities depend on the Azure Functions version (more on that here). The GA status is only for C#, F# and JS, while Java 8 is GA supported on version 2.x only. PowerShell, Python, TypeScript, Bash and PHP have either experimental or no support on both versions. Detailed mapping is here and the roadmap for planned changes to language support is here.
Like Lambda, it is possible to write a code inline through Azure, but there is no option to upload a .ZIP file thought GUI. It is possible to do so, however, through the API and CLI tools meaning CI/CD integration does exist and is well developed.
Tooling and Debugging
Similar to Amazon’s offering, Microsoft provides dedicated toolkits for well-known IDEs including: Visual Studio, VSCode, JetBrains, IntelliJ and Eclipse. Additionally, the company developed Azure Functions Core Tools, which “lets you develop and test your functions on your local computer from the command prompt or terminal.” Well done.
Monitoring and Logging
Aside from the built-in Logs console available for every function (something much more accessible and user-friendly than Lambda CloudWatch), Azure offers built-in integration with Azure Application Insights, a powerful monitoring and performance management tool. This tutorial shows you how to configure Azure Functions to send system-generated log files to Application Insights.
So as far as logging and monitoring is concerned, Azure Functions clearly overtakes AWS Lambda.
Performance and Scaling
As with many things in Azure, measuring and experimenting with Azure Functions performance and scale is not an easy task. There are three possible hosting plans (am I supposed to forget about hosting in serverless?) that impact how your function will scale. To summarize, two out of three hosting plans — the Consumption plan and a Premium plan — will scale your function automatically, while a third — the App Service plan — “allows you to take advantage of dedicated infrastructure, which you manage.” Seriously, Microsoft? A dedicated infrastructure I manage for a FaaS? More details about those three plans are discussed in this official Azure blog post.
But everything in the world’s a trade-off, and approach allows Azure to handle those infamous cold starts much more efficiently than any other provider. Mark Heath shows how in his recent blog post. Take a look.
Since Azure Functions are publicly accessible by default, security is a crucial concern from the very beginning. That said, security features are not part of the function definition and can be added as nice-to-have additional components. HTTP-triggered functions can be protected with OAuth providers such as Azure Active Directory, Facebook, Google, Twitter and Microsoft Account. Also, you can use a built-in authorization level or “hide” it behind an API Gateway.
VNet, Azure’s version of AWS VPC, does not work well with Azure Functions: it is possible to leverage it only with a recent, still in beta, Premium Plan. This Azure blog post will guide you through the process.
Bottom line: AWS Lambda, with built-in IAM roles part of the function definition and similar API Gateway OAuth authorizers, is the clear winner here.
In addition to the standard per-seconds resource consumption and executions plan that offers similar options of 1M requests and 400,000 GB-SECONDS as part of a Free Tier, Azure Function can also leverage an existing App Service plan, which allows you to use an existing underlying infrastructure and avoid additional costs. More on that is available on the Azure Function Pricing page. You may also find the Azure Functions cost calculator useful.
Running Azure Function under constant high load while using a standard pricing plan is, as in case with Lambda, not the best solution possible.
Wrap Up and Further Reading
Microsoft is doing its best to close the gap on Amazon but still has a lot of work to do, especially when it comes to language support. Mixing FaaS with the previously existing PaaS AppServices solution is controversial but helps in some scenarios. The bottom line: if you are locked-in with the Azure platform you stay calm and bet on Azure Functions. Microsoft has invested a lot in its FaaS offering and will continue to do so.
Next Post in a FaaS Series