Well chose Infinity Works as a partner because of our experience delivering healthcare solutions, often on critical National Health Service (NHS) systems, and capability to engineer high scale cloud-based applications.
Within Well, Infinity Works had built up a reputation for being low-fuss, technically excellent and suited to delivery of complex agile projects.
Infinity Works had provided much of the engineering capability and cloud infrastructure for Well’s online pharmacy offering, and had developed an understanding of Well’s business that meant they were uniquely qualified to deliver this project.
A secure API integrating with Serverless components
Infinity Works proposed that a suitable solution would be to provide a secure API enabling pharmacy systems to check stock, order prescriptions from the central fulfilment facility, and track the status of orders.
This system would need to include a mechanism for integrating into warehouse technology, and a way to collect up-to-date stock data from the warehouse inventory management systems.
Infinity Works proposed the use of AWS API Gateway due to its security features and integration with other serverless components. API Gateway provides strong protection against incoming HTTP-based attacks, rate limiting, and only supports TLS connectivity, preventing accidental misconfiguration that could result in transmission of customer data over plaintext protocols.
API Gateway is well integrated into AWS Lambda, which was selected as the compute platform for the project. AWS Lambda functions were used to build the APIs and connect to:
- AWS S3 to collect stock data.
- DynamoDB to store and retrieve prescription data.
- SQS to broker communication with on-premises warehouse systems.
AWS Lambda was selected over other options such as EC2 because of its high scalability, low cost, low maintenance requirements, and security. Under the AWS Shared Responsibility Model, AWS manages the security of the compute platform, while we are responsible for the code that runs on the platform. This reduces the total cost of ownership by removing the need to manage the security lifecycle of the compute platform.
The database platform that drives the warehouse inventory management system was configured to push regular stock data updates to an S3 bucket. This low-cost approach simplified integration between systems, while providing fault tolerance and preventing the need for on-premises systems to accept inbound network connections.
DynamoDB was used to store prescription data due to its simplicity and reliability, low cost, and strong encryption features. The unique TTL (Time-To-Live) DynamoDB feature ensures that data is automatically deleted according to compliance policies.
Amazon Simple Queue Service (SQS) was selected as a queue mechanism to control the throughput of messages to the warehouse system, smoothing out usage spikes. A small agent written in the Go programming language runs on-premises and connects via the AWS SDK to the SQS queue system within AWS to collect messages and forward them on to the warehouse equipment, returning information back to the cloud via another queue. SQS’s built-in encryption features and built-in AWS Lambda integration allowed us to spend more time working on features than working on developing a platform or connecting systems.
SQS also allowed for scheduled maintenance of the warehouse systems – the queue processing can be paused and resumed after maintenance is complete – while the dead letter feature allowed us to be sure that all messages had been processed and to handle issues.
We chose to use AWS Serverless technology in order to minimise the amount of engineering time we would need to spend on platform engineering, prefering to focus on product features, compliance requirements, and automatic scaling to meet demand.
Deploying the power of Serverless
Number of Lambda functions
|
10 – used to process API requests, handle queue messages and to process streams of updates from DynamoDB.
|
Events per month
|
24M
|
AWS services used
|
Amazon API Gateway, AWS Lambda, Amazon DynamoDB, Amazon SQS, Amazon S3, Amazon Kinesis, or AWS Step Functions.
|
Framework
|
Serverless framework.
|
Languages
|
Go
|
Deployment
Well Pharmacy had some initial concerns about the use of Serverless due to unfamiliarity with the overall toolset and its ability to meet the stringent compliance requirements required by healthcare. By working with compliance and security teams to help them understand the security capabilities of AWS, the specific AWS services we were using, and the AWS Shared Responsibility Model, we were able to demonstrate that the solution met or exceeded all requirements.
To deploy the solution we built a continuous integration pipeline using a continuous integration (CI) platform and Serverless Framework – a command line tool that can be used to build and deploy Serverless applications by generating CloudFormation templates.
This allowed the new versions of the application to be deployed to non-production environments automatically in order for functional and user-acceptance testing to be carried out. The CI pipeline standardised the release process and the use of CloudFormation allowed us to be certain that our non-production environments matched production environments. The “pay for value” aspect of Serverless technology meant that our non-production environments cost nothing to run when not in use as per the Serverless Architectures with Lambda whitepaper.