In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.

High Level Architecture

VMchooser has the following high level architecture ;

Web App : The front-end of the application is hosted on an Azure Web App.

Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).

Application Insights : Application insights is used to have the needed insights into the usage & other metrics.

Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.

API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.

When I was working on the “CSV import” of VMchooser, I noticed that long jobs sometimes had issues. After some investigation, it quickly became apparent that I was hitting the time-out. So I had a need to increase it…

Logic Apps Time-out = 2 minutes

As a bit of back story, I first started off with my async parsing flow by using the combination of logic apps & functions. Where I at first thought it was due to the time-out on the functions side, it actually appeared to be on the logic apps side. And that one cannot be changed…

Azure Functions Time-out

So I browsed the web, and encountered two variables, which I both set on my platform ;

To reach set these, click on your functions bar (“kvaesvmapi” here), then “Platform Features”, and then “Application Settings” ;

But let’s get back to the variables… From various posts I saw these two popping up. Where I set them both to be safe, I started investigating a bit. The first one ;

WEBJOBS_IDLE_TIMEOUT – Time in seconds after which we’ll abort a running triggered job’s process if it’s in idle, has no cpu time or output (Only for triggered jobs).

This is actually the one you need for your function. As it’s clearly described in the kudu docs. Where the second one apparently is only related to the deployment phase; hence the “SCM_”-prefix.

Remember the last time you went shopping for a shirt? Then you surely also recall the moment in time when you were looking to find the right shirt size for yourself…

You probably also noticed that sizes might differ a bit depending on the context. A woman’s size vs & men’s size is totally different. There are geographical differences… and some people just like to wear cloths that have more “free space”.

So is today’s post about buying cloths? Hell no… 😉 But it’s to point out that there are analogies between finding the right shirt for you, and finding the right Azure Virtual Machine. Today we’ll delve into the aspects that will guide you a given T-shirt size in Azure ; for instance, why choose an FS1 above an A1_V2, where they both have 1 core & 2GB of memory. Though there is a price difference of 10€ per month on them.

Up in the Clouds

Views are my own

The content of this blog will, at all times, portray my own views. At no time will this reflect the views of the organization I am linked to. Neither can the information provided be used as support statement.