Using the stressor analysis to rate flows

We have a central flow in the system, the generate report flow, that’s quite interesting from an architectural perspective. The report is generated in the desktop application given to us, and using a Windows desktop application in a Cloud environment is, let’s say interesting.

I’ve designed three different versions of the flow, calling them A, B and C, and then using the stressor analysis to calculate the Residual Index. I removed lots of the stressors that I’m certain will not have any impact on this specific flow.

I know, I’m mixing Swedish and English. Sorry not sorry. But here we see Flow A where a frontend-click calls an Azure Function that triggers a Windows Container to start, with the desktop application in it. Parameters are passed down using Environment Variables, and the desktop application calls the database to get information and uses Libre Office to generate a PDF-report, that is saved in an Azure Blob Storage. The Blob Storage triggers a function to update the database when the file is stored. This is the current flow, and our main issue is that the Windows Container takes 3-5 minutes to start.

Flow B has a Queue where the Azure Function puts the parameters for the report, and a Container always running and subscribing to that Queue to generate the reports in the exact same way as in Flow A. The main win here is that we get rid of the startup time of the Container. We can still have more Containers running to scale, based on Queue length or something, making it equally scalable, but faster.

There’s also a Flow C, where we rewrite the Report Generator to run without the need of the Desktop Application. Using Azure Functions is giving us Auto Scale, and this flow would allow direct response to the user, without the Fire & Forget flow as in A and B. This will also allow us to remove the dependence on Libre Office and instead use a Word to Pdf component that’s made for using in code.

Here’s the Residual Index calculation

The main benefit using Flow C is the reduced dependency on our external developer (called main developer in the Stressor Analysis). He’s great, but him being alone and no one else having access to the code is a risk.

Cost wise, Flow A has cost for multiple Containers running, where Flow B has cost for Container always on. Is one of them to prefer? We can’t tell until we see consumer behavior. As for Flow C, rewriting stuff always come with a cost, and possibly also a licensing cost. However, decisions regarding cost will come at a later stage.