Improve the architecture

This week we addressed the fact that, by default, Azure only allows you to allocate 10 vCores per region. Each Container Instance needs one or more vCores, making it limiting the number of Container Instances we spin up.

Another issue with the original architecture is that whenever we start a Container Instance, with the desktop app, it isn’t removed when the app is done, it’s just idle, still having the resources allocated. This isn’t a cost issue, since idle resources are free of charge, but with the resources being limited by number, it’s a big issue.

We will be designing a system that handles Container Instances that are no longer running. How that will be designed is yet to be decided.

In the original architecture (A), each click in the frontend application starts a new Container Instance. This is great for scalability. Since all the Instances write to the same database (at least for now), this might cause heavy load. Also, there’s the 10 vCore limit, and the current implementation just fails to start an Instance, with no error handling. This could of course be handled with decent error handling and increasing the vCore limit, but I hade another idea.

The improved architecture (B) has a Queue, where the instructions for the Crawl is put. We also create a new Container Manager, that will read the Queue only when a new Container Instance can be created. This minimize the risk of Crawl requests being dropped. We can also control the number of Container Instances being created, to avoid heavy load on the database.

We also have stressors indicating that the maximum number of concurrent crawls per Agency might be set by their license. Other stressors suggest DDos attacks, and tho this whole flow is behind login, in architecture A, a user might still cause chaos.

In total, the Residuality Index for architecture B is 0,06. A positive number indicates that the architecture is better than the baseline (architecture A).