A while back I wrote about Azure Functions and their limitations. I highlighted the lack of telemetry processors support and the large volume of telemetry emitted by the runtime as two pain points in the Application Insights integration. I managed to add support for telemetry processors and discard the duplicated telemetry. My implementation was clunky and mostly uncovered by tests but I’ve been running it for over a year on many Azure Functions and it seems to be working.

I didn’t publish my customisation as I was hoping Azure Functions v4 would make it obsolete. I recently played around with In-Process Functions v4 and discovered the same issues are present and the runtime is emitting more telemetry. This motivated me to remove a few rough edges in my implementation and add support for v4.

I’ve recently started using Azure Functions. What interested me most was to understand why users are picking Functions over “plain” Azure Web Apps to host HTTP APIs. I found the HTTP binding to be limited, the development experience to be clunky and the Application Insights integration to behave differently that on ASP.NET Core.

In this post I’ll describe the limitations I faced when working with Azure Functions. In follow-up posts I’ll describe the workarounds I’m using to address some of these limitations.

I was recently working on a project that contained secrets in source control. The team was aware of this fact but had never been able to allocate time to get rid of them. The circumstances changed and I was tasked with cleansing the repository. I was still unfamiliar with the code-base so I started to look around for config files. I realised quickly this approach would not work out:

• Some secrets were hard-coded directly in the code
• Some secrets had previously been committed to source control but had since then been removed

I needed a tool that would not only attempt to identify secrets but would also do so over the complete Git history.

I was recently faced with an interesting problem. A company wanted to cost the migration of thousands of VMs to Azure using a lift and shift approach (also known as rehost). Due to the short deadline, we were not able to get our hands on detailed data. All we were provided with was a machine name, CPU cores count, RAM and a description field that was sometimes populated. Utilisation, storage and network usage were notably missing. We knew we couldn’t cost the migration accurately due to these unknowns, but we had enough data to cost the VMs themselves as we had access to CPU cores count and RAM. I must also add that the VMs varied greatly in their hardware specifications.

Microsoft offers a pricing calculator but it only supports manual input which disqualified it for our use case. A few Microsoft employees wrote web applications automating the pricing of VMs by importing Excel spreadsheets or CSV files. The ones I tried only offered USD as a currency and choked for anything bigger than a few hundred VMs. The output file was using a en-us culture so it had to be post-processed before being open in Excel. I didn’t have the time to review and select a commercial solution (Azure Migrate requires to create a VM on-premises which was not possible). At the end of the day I came up with a semi-automated process that did the trick, but I felt that not much work would be required to empower teams to price VMs based on a limited data set.