Implementation Lessons

This was my first attempt at authoring an Azure function and that meant that a considerable amount of time was spent learning and creating the toolchain. Comparing it to AWS it offers some features I like. The Azure storage explorer initially annoyed me as it’s a separate application that must be installed to perform bulk uploads to storage tables, but I do enjoy its interface. The other annoyance was an insistence on using VSCode to author the functions if you want to include libraries that are not standard base packages to python. Though the Azure method of declaring them in a requirements file as opposed to the AWS requirement to package/zip them and upload them as layers is much nicer.

CORS

This was much simpler to manage as poart of a function app than it was in AWS. There is a CORS blade menu and even a tooltip to add an asterisk to make your funciton publicly accessable

Toolchain torment

While I like all of the tools in the toolchain for this I struggled to set up several of the components. There was a day or two of hair pulling about connecting VS Code to the proper Python interpreter in anaconda. There was the requirement to use Vs code at all if I needed something as simple as the Requests package. There was the need to install a function runtime to do local testing of functions. Once its all set its not so bad, but the initial hurdle is not nothing.

Application Insights

In AWS there is a logging tool that can give you a lot of robust data about your Lamda executions and outputs. Here the Azure application insights felt lacking in the details. Specifically when trying to debug and later when attempting to benchmark performance. It may be that I just do not know how to properly set these systems up to give me the detail I was looking for, but It also wasnt immediately apparent.

Overwrite Failure

When doing a bulk upload of a CSV file to fill in the storage table I ran into an issue where the upload would fail. It later turned out that there were some entries in the file with repeating ID values (null placeholders that never got removed). This caused the entire upload to fail. When doing this operation on AWS Dynamo the repeated IDs just overwrite that row. This may or may not be a good thing depending on you like your fail states. But it took some digging to understand what was happening.

Service Connector

This is touted as a way to build fast connection between your pieces of infrastructure, without having to do complex setups. In reality it added an environmental variable to the function that let it access a connection string specifying the protocol, name, and key for the storage account. All of which are needed for the python SDK to connect and query the tables. Im not sure if just manually adding it would have been the same, or if it auto updates on a key rotation


Retrospective

I was a bit disappointed in the results of this. I had hoped that the functions and tables would be comparable to the AWS architecture. While the architectural layout is similar with storage tables also being a nosql (although structured) database, and Azure functions also being serverless and consumption-based python ready code executions. The Azure system was just too slow. This may be from the consumption app service plan throttling down to zero and causing a cold start delay. It may be that queries on storage tables do not have single digit millisecond SLAs like DynamoDB tables do. Or it may be that the service connector between these two services (connection string) adds some delay that perhaps using a standard plan with the ability to collocate inside a vnet might resolve.

As it is its a good proof of concept, but the idea that this could be stood up inside Azure in the same manner as it is in AWS may need some rethinking.