It seemed like a strange request, when a colleague asked me to look into upgrading our Function Apps to use .NET 10, ‘isolated worker’. Since when was it possible to change their runtime version ourselves? And what on God’s Green Earth was an ‘isolated worker’? It was time to investigate.
There are a couple of important things to remember about Function Apps, as a starting point. Firstly, my colleagues and I had developed Function Apps exclusively as custom Logic App components, to handle more cumbersome data transforms.
I’ve worked with several ’low code’ platforms in recent years. Some are better than others, but I’m always asking one question: What problems are they supposed to solve?
The biggest of them is ’technical debt’. Dependencies become outdated and unmaintained, updates sometimes have breaking changes that require code to be reworked, additional code gets tacked on over the years by various people, amateur code makes that harder, etc. Technical debt might be an inevitability for an organisation that’s been developing software in-house for long enough.
Azure Local was mentioned in a discussion with a few other engineers, the other month. I’d never heard of it, but I could guess it had something to do with running an on-premise instance of Azure. Apparently they’re calling it ’edge computing'.
There’s a list of things we don’t want migrated to Azure, when we think about it, such as security camera streaming and recording, database for the security cards, software-defined networking, internal hostname resolution, that sort of thing.
After resolving the previous issue with the Content-Type defect in the Azure Logic App’s storage connector, I ran into a second problem: The Web pages being generated were populated with the correct content type, but the incorrect content. I quickly discovered that was partly caused by a race condition and with how memory is managed by Azure.
By default, a Logic App will run up to twenty instances of a ‘For Each’ loop in parallel, but this is multi-threading instead of true parallel processing.
One of our Logic Apps, which we developed as a static site generator, began writing the Web pages to the storage account as octet stream files, and I narrowed down the problem to a defect in the storage account connector.
I believe (but I’m not 100% certain yet) Microsoft’s developers hadn’t implemented the ‘"headers": {"Content-Type": "text/html"}’ code for the storage account connectors, and the file type, therefore, always defaults to octet stream.
One of my Logic Apps originally had just three steps:
HTTP trigger Deserialise HTTP request JSON payload Send objects from the request payload to a Service Bus queue Another Logic App would read the objects from the Service Bus queue, use them to query another source for data, then send a email to whatever address was in the initial request. I used this approach because there could be more requests than a Logic App can handle concurrently, and it made sense, therefore, to queue the requests.
The security configuration of Azure services is a fairly broad subject area, and this is more of an introduction to how it works for a Resource Group, in the context of a Logic App that needs to interact with multiple resources. If a DevOps team, instead of the developers, is managing the security, a considerable amount of time will be spent planning and designing services beforehand, and later trying to figure out which security configurations are preventing the services working.
One of the most important lessons I’d learned from working with Azure, over the last year or so, is that careful thought should be given to whether it’s better to implement a service as a ’low code’ solution, or as conventionally-developed software. The former isn’t always the fastest, cheapest or more efficient way to get something deployed.
I’m currently of the opinion that Azure’s Logic App system is quite good for integrations and basic scheduled tasks - and it has indeed made those kind of things easier to manage - and there aren’t any convoluted deployment pipelines to bother with.
A security incident was flagged this week. As it turned out, nothing was compromised, but it served as a valuable warning of how vulnerable an organisation using Microsoft Azure (or perhaps AWS) could be to a subdomain takeover that could be used in a more sophisticated attack.
The incident had something to do with a subdomain that was initially mapped to a staging Web site hosted on Azure.
The Web site was removed some time ago, but the mapping between the subdomain and the site’s public ‘azurewebsites.
One way to help understand how Active Directory, App Registrations, managed identities and Key Vaults work in Microsoft Azure is to look at a typical Logic App that authenticates itself with an API that provides data only to services registered with the organisation’s Active Directory.
The basic sequence for the authentication part of the Logic App here is this:
Get a password from an Azure Key Vault. Get an OAuth token for the Logic App from Active Directory.
