Using Azure Functions with .NET

Background

Serverless computing provides the ability to run code without the burden of managing servers and is a great way for organizations to reduce their infrastructure overhead. Starting back in 2014, all the major cloud platforms started to offer Functions as a Service (FaaS) options. Azure functions are Azure’s answer to AWS Lambda functions. All the big names in cloud platforms offer similar technologies. No matter which cloud platform your organization elects to use, or if you decide to host your own FaaS, having serverless functions is a valuable option when developing solutions.

What’s the value of Azure functions?

Azure functions offer organizations a way to run code without all the typical overhead associated with hosting modern computing languages. This allows their staff to focus on the critical components of a solution vs the things that don’t add any value. Azure functions specifically offer excellent ways to interface with all manners of different systems with their use of an event model. Also, the ability for developers to work with Azure functions locally aids in quicker and more robust development with fewer bugs.

Many solutions are being built on the concept of microservices. This speaks directly to the value of Azure functions, well suited when you want to decompose your logic into small chunks that can scale and operate independently of each other. The toolset for developing with Azure functions works really well, especially with NET. There are multiple applications you can use to aid with local development. Azure Functions CLI coupled with the integrated support in Visual Studio makes for a great development experience.

How are Azure functions different from AWS Lambda functions?

Configuration

All AWS Lambdas run on Amazon Linux in the background. They can vary in their memory footprint from 128MB all the way up to 3GB with processing power going up in proportion to the memory.

With Azure, the operating system running in the background is configurable between Linux & Windows. What is not as configurable with Azure is the memory and CPU. The memory for an Azure function app is limited to 1.5GB and one CPU.

In any FaaS solution, you will want to look over your code if you are hitting memory limits to find ways to decompose the logic into smaller function apps. This will ultimately allow your app to scale more effectively.

Language Options

For the most part, Azure & AWS both share similar programming languages. However, Azure does lack Go & Ruby.

Hosting

Hosting with AWS is pretty straight forward. Azure is quite configurable but can be harder to set up when starting out. On the plus side, it does allow for you to dial in your hosting costs for whatever best fits your needs.

Programming Paradigms

There is a large difference in the way you develop for AWS Lambda or Azure functions. With AWS, the contract is straightforward - you make a request to a function and it results in a response. With Azure, you can create more sophisticated models using triggers and bindings.

What are some gotchas?

Performance

Prior to June 2019, there weren’t a lot of options from Microsoft for the issues with cold start operations in Azure functions, specifically with .NET languages. Starting in June 2019, the options to deal with cold start woes drastically improved for .NET by allowing for options within their premium and dedicated plans. Prior to June 2019, developers would avoid issues by using what effectively amounts to heartbeat API requests. This would continue to run the code to mitigate the need to cold start the application after the first time.

Extensibility

Cloud platforms are constantly expanding and improving, providing many options for extensibility. Even with that, there are some things that are going to require more work to do. Triggering a function from a streaming platform like Kafka, for example, isn’t supported on Azure or AWS yet.

Run time

Azure functions are currently limited to 10 minutes. This was increased from 5 minutes to 10 minutes within the standard pay-as-you-go consumption plan earlier this year. If 10 minutes isn’t enough time for your code to run, there are premium plan options that extend the timeout further, to 60 minutes. When using an App Service Plan, there is no limit.

Storage

Be mindful when working within your storage accounts if you are using Azure functions. The function code files are stored within the main storage account of the function app. If you remove the code, you will need to restore it from source control.

Conclusion

If your goal is to adopt a serverless architecture or one where you reduce your server overhead, leveraging Azure functions written in .NET (or your language of choice) is a great option. Breaking away from the typical monolith structure that has been all too common with .NET applications creates opportunities to create solutions that can grow with you and reduce development time and bug reports. By having small functions in isolation, you are able to really hone in your logic and ensure it works exactly as expected. Proper test coverage on those functions is all you need to ensure contracts don’t get broken when you go to integrate your updates into the rest of the application.