Before we begin, if this is your first time here, welcome to the Quantum Blog! We regularly write short form blogs with the intention of helping you on your journey in business. We are a tech company so a lot of our content will be based on applying technology to your business in order for it to run a bit smoother. If you find value in these blogs give us some love on our socials (LinkedIn, Facebook, Instagram)
Just after posting this S.E.A results were published. This was the result:
Seems like they are already using Azure but their web app isn't configured to take advantage of auto scaling. Unfortunate.
If you are reading this, you more than likely fall into one of the following groups:
- Government IT staff
- Private sector IT workers
- A member of the public that has used government IT services.
In either of the cases you would be exposed to the IT services of the government. Utilizing the various services that are provided as you navigate your daily life. Think to yourself, has this made my life easier? Or is it a frustration to use? Either way, we think that digitization of government services are essential to reducing operational cost of government organisations (because governments are usually budget strapped) and in general making the lives of citizens better.
We hypothesize that:
- Lack of technical understanding when deploying government scale IT services.
- Performance requirements are not clearly defined.
- User experience (UX) is not considered as part of the requirements elicitation process.
A Case In Point - ttvaccine.com
Before we continue we should note that the point of this article is not to point fingers but simply to highlight the problems, provide solutions and underscore that we should do better.
TTVaccine.com was launched during the C-19 Pandemic to manage distribution of vaccines to the public. The site facilitated appointments for vaccination across Trinidad & Tobago. However it was plagued with issues:
- Basically unusable due to the load on IT infrastructure.
- A soft queue implemented to help curb server load was the most disgusting solution to any IT problem ever. Imagine waiting in line to use a website? Who does that?
- A OTP code that never came. Thankfully for the poor implementation if you were tech savvy you could inspect the network requests in your browser and get the OTP code without it ever reaching your phone.
- Not IT related but imagine after all of that you finally got an appointment that no one cared about at vaccine sites.
The solutions to these problems seem rather trivial for the typical software engineer:
Cloud providers like AWS and Azure make it very easy to deploy a highly available (HA) architecture in the cloud. In general A couple application server behind a load balancer should do the trick. Azure and AWS allow you to define Horizontal and Vertical scaling policies so none of your software engineers have to manually scale the servers when there are load spikes. The cloud provider will automatically handle scaling down when demand subsides so your costs do not remain elevated for no reason. Pretty neat right?
Lets make the assumption for now that you were unable to setup some type HA architecture. At a minimum you should be doing load testing. This is standard part of any deployment strategy to ensure your provisioned server capacity could handle the demand that you expect.
Elastic Strategy with Queues
Servicing a huge amount of network requests synchronously could definitely require a lot of compute. Something like an OTP code could be offloaded to an asynchronous micro-service. Azure queues and AWS SQS provide simple interfaces for deploying and utilizing queues to handle your workloads. Queues by nature are elastic so it checks the box for handling spikes in load. To process the data on your queues you have two options. Either deploy workers on your own servers to handle the processing OR take advantage of server-less functions like AWS Lambda. There is no requirement here for manually scaling an infrastructure since serverless functions are event driven.