Our serverless saviours?

Barely a year passes without the tech industry throwing a slew of new technical jargon onto our plate to digest. Deep Learning. Quantum. Blockchain.

Serverless computing may also be thrown into the mix, but what does it mean and how can we use it in the National Digital Platform?

The evolution of servers

Servers literally “serve” us data. Whenever you visit any website, a server responds with information - an image, a webpage, a list of patient medications. Where a server lives and how we manage it has evolved.

In the good ol' days of the internet (think Ask Jeeves and keyboard-playing cats), companies would house their servers on-premises (“on-prem”). They’d buy powerful (and noisy) computers, plug them into a spare office and host the applications themselves. The company was then responsible for ensuring the server was powered, resourced, cooled, networked, patched, secure and ultimately, available.

Then in the early 2010s came cloud computing. Companies like Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) arrived and said “Hey, fed up managing your own hardware? How about you use some of ours and we’ll deal with the nasty stuff”. In “the cloud” you could rent hardware as virtual machines (VMs). This is your server, but you’re only concerned with what runs on it. This was a highly successful model - you only have to examine the last decade of Microsoft and Amazon stock (spoiler - it wasn’t because they sold more Windows 10 or Prime subscriptions).

Towards the end of the 2010s however, we saw the wider adoption of serverless - a concept built upon cloud technologies.

Serverless benefits

When it comes to reducing the management of the platform your services run on, serverless goes that step further. A cloud provider might lend you a VM, but this is still yours to manage. You must:

• Pre-install all the software
• Ensure it has enough CPU, memory and disk space
• Basically, keep the thing alive.

Meanwhile in serverless world, just drop your code in, and you’re good to go. This concept can even be extended beyond writing code. “Serverless” is often used for any service that doesn’t require you to manage a server and most providers supply products for common tasks.

Need a file server to store your data? Try Azure Blob Storage.

Need an email server to contact your mailing list? Give AWS Simple Email Service (SES) a go.

Need a job scheduler to run scheduled tasks? Google Eventarc might be suitable.

Need a queue for messages waiting to be processed? Sounds like a job for AWS Simple Queue Service (SQS).

Serverless allows engineers to focus on the functionality and business logic of a system, not the underlying maintenance. It can be cheaper too, you only pay for what you use, and it scales very well.

How does the National Digital Platform currently use Serverless?

Our work on the NDP has utilised serverless in AWS and Azure for a wide range of tasks including:

• AWS Simple Notification Service (SNS) and AWS Lambda is used for service monitoring. If a server is having problems (e.g. ran out of memory), then an alarm message is sent into SNS, where all alarms are collated and forwarded into a Lambda function. The Lambda then processes the message into a human-readable format and posts into MS Teams to alert the engineers. If a service on the NDP goes offline, we’ll know about it because of serverless.
• Azure SQL is a managed service for running databases. Azure takes care of all the SQL version upgrades, availability, provisioning of storage and scaling to allow the engineers to focus on the applications that use the database - such as the Vaccination Management Tool.
• AWS Cognito manages users and authentication to some services on the platform. Whenever someone accesses the EMPI service - they must go through the serverless Cognito identity service first.
• We send vaccination data from the National Clinical Data Store (NCDS) into GPIT via Azure Data Factory. Simply sending data from one system to another doesn’t work - there needs to be some processing layer in between. Instead of writing and managing an application from scratch, we use Data Factory to create our processing layer in a simple and scalable, business logic way without getting too bogged down in the code. The reverse data flow also exists for GPIT to NCDS where an opposite Data Factory flow is used.
• AWS Lambda is used to generate PDF patient care summaries for the ReSPECT product. The Lambda is also backed up by SQS - when a PDF is requested it is added to the queue and the Lambda processes them in order, allowing the generation to happen more safely and efficiently. Patients are now receiving a more tangible summary of their care thanks to serverless.

What’s next?

Some say we could do everything serverless. However appealing this sounds, I would disagree. Serverless technologies are limited. There are only so many products and customisations serverless can provide before either the cloud provider says “this isn’t viable to manage” or the engineer says “this would just be easier to develop myself”. Lambda and Azure Functions are a great way to run custom code easily in the cloud, but are still limited in the languages, frameworks and integrations available.

For something as wide-ranging and complex as the National Digital Platform, I don’t believe it will ever be possible to go fully serverless.

But there is great scope to combine serverless and the NDP in future. Integration engines that map data from one standard to another (a common health tech problem) are crying out to be “serverless-ified”. And as the NDP starts growing for the population of Scotland - serverless scaling capabilities will be invaluable.

For discrete, repeatable tasks to common problems, there’s a serverless solution out there that’s likely easier, quicker and cheaper.

To learn more about serverless, watch this video which builds on the themes in this blog.