Serverless on Azure – Azure Functions Review

I’ve been learning and using Azure Functions for the past couple of months, so this is my experience so far. Developing and deploying to Azure Functions is very simple if you’re running an up to date version of Visual Studio.  In the Visual Studio installer, be sure to tick “Azure Development” under the Web and Cloud workflow options.  At the time of writing the latest VS 2017 version is 15.6.4.  The free community edition works fine for this. Once that’s installed, you’ll have an option under File -> New Project to start an Azure Functions project: When you start a new project, you’ll get an option to select which API version you want to code against (v1 or v2), and a choice of triggers.  These can all be changed afterward they’re just useful scaffolding: Recently Microsoft released version 2 of the Azure Functions Runtime, which allows you to use .NET Core or .NET standard rather than the full-fat .NET framework.  There are some limitations however.  I’ve used both v1 and v2, but I’m only using Http and Queue triggers so I haven’t run into any issues (yet). The great thing about Azure Functions is you can write them in more-or-less any language, with bindings provided for C#, F#, Python, PHP, Javascript/Node and Powershell/Bash.  The function.json file is the heart of the function, and it describes how to trigger your job and its inputs and outputs. If you’re developing in a language with first-class support such as C#, then the functions.json file is automatically generated for you when… Read More

You’re doing HttpClient wrong

Today I learned something that shocked me to my core. The following piece of c# code is wrong: using (var client = new HttpClient()) { // client.GetAsync(…); } Why is this wrong? Superficially, HttpClient implements IDisposable, and if you’re like me (and I suspect 90% of all .Net developers) you’ve been taught to diligently call Dispose() on anything that implements IDisposable. Except that HttpClient is a bit different, it’s actually designed to be a shared object, and thread-safe.  If you come up against problems with TCP socket exhaustion, you’ve probably got loads of connections in TIME_WAIT state, and it could be due to this simple issue.  The use of HttpClient in a using block is so common across the internet, and in Microsoft’s documentation that it was a real shock that this was wrong. What should I do instead? You can instead just instantiate HttpClient once, either as a class-level static, or pass it around in your IoC container.  You could come up against some issues with setting properties such as Timeout after instantiation, and it may not respect changes to DNS but if you’re having problems with using too many sockets this is the only solution. References: https://stackoverflow.com/questions/15705092/do-httpclient-and-httpclienthandler-have-to-be-disposed https://docs.microsoft.com/en-gb/azure/architecture/antipatterns/improper-instantiation/