Transition to Serverless: A Review
Our articles in the past month detailed the transition of our product from an always-on SaaS model hosted in an EC2 instance to a serverless deployment that only uses CPU cycles when necessary. As a result the total cost of ownership is driven to the lowest possible level. For disaster recovery backup solutions like ours — where the risk is low but non-zero — the investment should also be low. Serverless and backup is the perfect marriage.
The previous articles were also heavily laden with details, so in this article it is worth pausing to summarize the journey to serverless. Moving to serverless did not require rewriting our original SaaS solution. The logic is sound and achieves its purpose of provisioning backup instances in a different AWS or GCP region, replicating snapshots to the DR instances, and testing those instances after each replication job. Instead, it involved evaluating the various components and moving them to a different appropriate cloud service, and then integrating the entire whole.
For example the most significant move involved converting the core Java code from EC2 to Lambda. Since Lambda necessarily involves timeouts, potentially long-running operations such as waiting for snapshots required new logic to chain together discrete invocations of the functions. Additionally, discarding an always-on SaaS model drove the need for a new user interface as a standard web server was no longer feasible, with CloudFormation and CloudFront filling the void. Eventbridge provided robust replacement for logging and job running. And all of our deep testing scripts — such as connecting to databases to confirm recovery — were easily converted to additional Lambda functions, which can be delivered, updated, and extended through Lambda itself, rather than trying to update scripts within an EC2 instance.
The figures below summarize the transition of the SaaS infrastructure to serverless, including the overwhelming advantages of making the change:
Transition to serverless must be considered on a case-by-case basis — the vast majority of applications will still likely run in EC2 instances given their always-on nature or the need for an interactive UI. However, for the select few that can benefit technically and financially from serverless, we hope these articles are helpful in demonstrating how the transition can be made seamlessly. And as always if you are interested in evaluating our new serverless version of disaster recovery automation for AWS please reach out to info@thundertech.io
