A User Interface for Serverless

Transitioning our disaster recovery solution’s logic to a serverless paradigm occupied the bulk of the content in a previous article. This article features the effect on the supporting infrastructure — namely, how to preserve our product’s simple graphical user interface?

It is impossible to run a web server on AWS Lambda given that a function only runs periodically. How do we preserve our simple and intuitive interface that allows users to click their way through configuring automated disaster recovery protection for the cloud?

Because our UI is used mainly for initial provisioning of duplicate instances in a remote region, we needed a replacement to provide a simple interface to make a few selections — the instance to be duplicated, its subnet in the DR region, its size, and frequency of snapshot replication — and then drive the provisioning workflow.

The answer clearly is CloudFormation. Specifically, we provide a CloudFormation template that creates among other resources a custom resource, which invokes our Lambda function code that provisions a duplicate instance based on the selected attributes.

CloudFormation as compared to our SaaS UI — originally a standard web server hosting Javascript-enabled pages and a PHP backend — has many advantages:

• it is familiar to most AWS users
• we avoid the security headaches of keeping a web server up to date and protected
• authentication is native to AWS console users, that is, our interface doesn’t require a different set of users or complex Active Directory integration
• the results of the operation of quickly and persistently available as outputs to the stack

To the left is the “new” user interface, a familiar CloudFormation template requesting the necessary information and then launching the backend through Lambda.

The second requirement of our UI is to present logs to the user in order to confirm successful operation, or to quickly identify and correct errors. We needed a secure location where users could easily review these logs.

The answer here is CloudFront, specifically a signed URL that is generated when our function is initially deployed. The content of the URL is the logs that are generated by our function, stored and retrieved through AWS EventBridge, and written in simple HTML by our Lambda function on a regular basis. There is no need for fancy widgets or backend processing.

This URL is static, so can be bookmarked in a web browser. If the user forgets the URL, it is retrievable from the Outputs tab of the CloudFormation template during the initial deploy. It is even easily retrievable through a smartphone using the AWS Console app and navigating to the CloudFormation stack:

Eliminating our slick SaaS UI was a difficult decision, but the move to serverless will necessarily require sacrificing a certain portion of your code base. However, rather than spending time recreating a new UI, we let AWS do the heavy lifting. The result is an interface with which users are already familiar, and authentication, logging, and security are natively handled by AWS. If users are hosting their applications in EC2, they are probably also comfortable using CloudFormation, CloudFront, and EventBridge as well.

For our serverless GCP solution, we will just substitute Functions, Pub/Sub, Logging, and Workflows for Lambda, EventBridge and CloudFormation to achieve the same results.

The next article will outline how serverless makes our product more supportable and extensible.

In the meantime, if you are interested in beta testing Thunder for EC2 Serverless please contact us at info@thundertech.io