Modifying a SaaS app to run in a VM

[author:alex]

So you built a great SaaS web application, you’re ready to grow your business and get enterprise customers, but you don’t know how to get your distributed application running on 1 single virtual machine.

This is a common problem for many people. Either their web, database and file storage are on different servers, or they’re using external cloud services such as Amazon S3, SQS or DynamoDB.

Cloud services

If you’re using external cloud services in your SaaS app, you need to find out if there are direct swap-out replacements that can run locally. Of course, you can store files to the local filesystem instead of S3, and you can replace DynamoDB with MariaDB, but the change might not be that simple. In any case, you’ll need to look for alternatives since a “behind the firewall” virtual appliance will likely not have access outside the firewall (that one should be obvious to you).

Scalable SaaS app

If your SaaS app was designed to be scalable and is spread across multiple servers, then your app will be much easier to port. Two methods are: change all IPs to point to localhost or ::1, or use containers to isolate each scalable element as its own private instance.

There are some tools getting traction nowadays, such as Docker for creating containers, but their usage is limited to Linux (mostly Ubuntu), along with newer kernels. It is still in alpha and not recommended for production use, but it’s an option nevertheless.

A solution for FreeBSD exists using Jails. I’m guessing if your servers are running FreeBSD, then you likely don’t need this blog post to help you figure out what to do.

Modifying the code

The hardest part to get right is modifying code without maintaining two separate branches (one for the appliance, one for the SaaS).

This was a small mistake GitHub made back in the days prior to launching GitHub Enterprise. It was corrected, and I’ll provide some recommendations below:

• Create an environment variable which defines whether the app is running in a “scalable” environment (SaaS), or in a virtual appliance.
• Create helper functions which abstract what method to use for a certain task. Example: saveFile() could check the environment variable, and call saveToS3() or saveToDisk() depending on the value of the variable.
• Aggressively scan all your code for hard-coded IP addresses and calls to external service providers, and make sure those can be configured as variables or abstract methods, and set them depending on the environment.
• Test it! Jidoteki allows you to provision multiple times and test your code to see if everything checks out the way you want. You might want to download the first appliance you create, run it locally and test it manually.
• Once that’s done, you should automate those tests with something like Serverspec.

Don’t get overwhelmed

If your code is too complex to get running on one virtual appliance, there are other alternatives such as supplying multiple virtual appliances.

If you’re really stuck, feel free to contact us. We’re more than happy to help you prepare your code for distribution in a virtual appliance. That is our area of expertise after all.