Serverless? Certainly!
A few years ago, we launched Thunder for EC2 and Thunder for GCP, disaster recovery automation tools for the public cloud, priced at one-tenth of the subscription cost of competing solutions. Because we develop exclusively for the cloud, we have no overhead for equipment, lab space and rent.
Many advisors cautioned against such a low price, warning that potential customers would not take our AWS and GCP Marketplace solutions seriously because they were too cheap.
After much consideration, we decided they were too expensive.
Storage and data management SaaS solutions like our spend most of their time waiting; in our case waiting for jobs to run, waiting for snapshots to be replicated, waiting for disasters to happen (which of course we hope never occurs). As a SaaS solution running in a dedicated EC2 instance or GCP virtual machine, the vast majority of CPU cost goes to idle cycles, making solutions like ours the perfect fit to go serverless.
Over the next several articles I will introduce our upcoming release of Thunder for EC2 Serverless, our disaster protection solution engineered for AWS Lambda. The same logic that automatically provisions, replicates, and fails over copies of your production EC2 workload between regions — logic which ran in a dedicated EC2 instance — now runs within a Lambda function, essentially eliminating your SaaS hosting costs. A similar transition to GCP Functions will follow soon after.
The workflow is still our proven method: the product creates a duplicate EC2 instance of each production instance, based on the same AMI, and in the same private subnet CIDR as the primary. Going forward, a snapshot of each production instance is periodically taken, replicated to the DR region, and attached to the DR instance. Each DR instance is tested after each replication job.
However, instead of waiting for the snapshot to be created and replicated, the function is merely instantiated every 15 minutes; if there is something to do, for example, the replica snapshot has completed and needs attaching, the function does it, otherwise it exits immediately. The Lambda function only spends a short of amount time every day exclusively doing useful work, and you are billed — or more precisely not billed — accordingly.
Even though our existing SaaS solution runs as a t3.micro instance, at roughly $25 per month for 24/7 usage on EC2, this still adds up to $300 per year and over $1500 over five years — in addition to the $20 per month subscription fee plus the cost of replicating data. Competitors charge much more and may run their SaaS offering in larger instances.
The Lambda function, when used with modest environments, may even fall within the free tier, essentially eliminating the $1500 SaaS hosting fee. Also, functions are easier to price and license, so we will offer an outright purchase license, meaning you won’t have to pay monthly for the service either.
Crossing the bridge to serverless affords many other benefits other than reduced cost — namely simplifying our product tremendously by forcing it to go 100% cloud native. For example, by eliminating our SaaS solution, how do we host a user-interface to allow users to provision and manage the solution? No problem, provision using familiar CloudFormation templates. Use a CloudFront signed URL to view the logs, which are stored in an S3 bucket. The UI is now delivered completely through the familiar AWS interface, virtually eliminating web vulnerability headaches in the process. What do you we use now to schedule our periodic replication jobs? We switched to CloudWatch Events and let AWS do the heavy lifting. Need a place to store database passwords, for example for deep testing? AWS Secrets. Daily email summaries? AWS SNS. Why spend the effort and complexity of developing all of that infrastructure ourselves, when we and the end user get it for mere pennies, fully supported by Amazon.
Over the next several articles I will delve into detail about our new serverless and 100% cloud-native approach, not only to hopefully whet your appetite for our new solution but also to do our part to spread education of new and innovative ways to architect robust, inexpensive solutions for cloud. That said, if you are interested in beta-testing Thunder for EC2 Serverless please write us at info@thundertech.io for more information.
