Somebody Else’s Problem

This post is for fans of The Hitchhiker’s Guide to the Galaxy series, whether you can recite the entire trilogy by heart or, like me, simply appreciate Douglas Adams’ clever British humor and keen social commentary. Wittingly or not he also offered sage business advice.

The last book in the trilogy brilliantly introduced the “SEP field”, where objects can become invisible if they are so unbelievable that people just consider them “somebody else’s problem”, or SEP. It turns out that SEP summarizes our business model as well.

Our original disaster recovery SaaS offering, for example, included a custom user-interface; we spent endless time developing, hardening, and maintaining. In moving to a serverless model, we jettisoned the UI in favor of CloudFormation templates and CloudFront signed URLs. Developing, hardening and maintain the UI became Somebody Else’s Problem. That somebody (AWS) has a lot more resources than we do, and the UI was not central to our mission.

Securely authenticating and authorizing users to the interface also served as a huge pain and not our core value-add. CloudFormation of course is authenticated and authorized through enterprise-class IAM roles in the AWS console. Somebody Else’s Problem.

Scheduling operations such as snapshot replication was done in SaaS through jury-rigging the Linux cron tool, which doesn’t have an API. The serverless model moved to Eventbridge rules, modifiable via API and console access. We were not selling a scheduler but spent a lot of time creating one. Now, it’s SEP.

Logging? CloudWatch logs. SEP (including any security vulnerabilities).

Mechanism to provide code updates for fixes and patches? Now we just place a jar file in a versioned S3 bucket and ask customers to upload the new jar to their Lambda function definition in the AWS console. Product maintenance and update mechanism? Somebody … Else’s … Problem.

Keeping track of new version of Java? New version of python? New version of Ubuntu? Fine, select the new version in the Lambda interface. You’ll automatically get it in the next scheduled run of the function. Most certainly Somebody Else’s Problem. You can guess whose.

After deployment, need an additional script for example for deep testing of a certain application? From where do you get it? Where do you put it? How do you keep track of it? How to execute it securely? Easy: deploy via CloudFormation as a Lambda function. All of the scaffolding for this: SEP.

Cryptography. Few disciplines are as mind-boggling complicated and time-consuming as securely storing passwords. Except that we don’t store any; Amazon does in AWS Secrets. On our export control form listing cryptographic algorithms in use by our product, I’m tempted to write: “SEP”.

What is our problem is robustly replicating data across regions, keeping backup instances up-to-date, and automating the testing, testing, and more testing of your DR plan. Which is fine, as this is our core competency and the value add of our solution. By outsourcing the other infrastructure as SEP we can focus or time and energy on our core. Sometimes our competitors’ legacy software is expensive and cumbersome because of the sheer amount of effort needed to build all of the components, whether central to their mission or not, and which reduces the amount of time spent developing and testing the core components.

If you are evaluating a disaster recovery automation solution for your mission-critical EC2 instances and you can’t believe that we can do it so simply and cost-effectively, know that our secret is the influence of that master business advisor: Douglas Adams. Drop us a note and info@thundertech.io for more information or to take it for a free test drive.

Originally published at https://www.linkedin.com.