How ReadMe Went from SaaS to On-Premises in Less Than One Week
stackshare.io
stackshare.io
The single biggest problem by far was ripping/replacing 3rd party SaaS services that we use/pay for with native code. While building a SaaS it is wonderful to use 3rd parties to save time and complexity. Examples include Stripe (payments), Rollbar (error tracking), Intercom (support/engagement), Iron.io (queue and async tasks), Gauthify (two factor auth)... Howerver, when you go to on-prem often times the servers don't have a public interface, so your entire application has to work offline.
2nd tip. While it may seem like a good idea to create a separate branch in your repo for on-prem (i.e. enterprise branch), this is bad idea. It ends up being much better to just if/else in the master branch all over the place:
if(enterprise) {
// do something
}
I completely agree with your advice about using "if (enterprise)" statements instead of a separate branch or repo for the enterprise version. Once you make that enterprise branch, it's tempting to let it sit too long and merging the upstream changes is one of the least-fun, most-dreaded tasks. By using the "if (enterprise)" approach, your enterprise version stays up to date. but it doesn't mean you need to constantly deploy the latest version to all of your customers.
While building the enterprise version of Kumu [1], I found it much easier to maintain if I used the environment to toggle configuration flags rather than scattering if(enterprise) calls throughout the codebase:
BILLING_ENABLED = APP_ENV !== 'enterprise'
if (BILLING_ENABLED) {
// do something
}
One difference is that I decided to stick with a raw Docker container rather than going with Replicated (who are really nice people, don't get me wrong). In my case, everything runs on a single horizontally-scaled server so it's pretty easy to get running "manually". Also, all the potential customers I asked said that they were comfortable managing their own Docker environment, and some would actually prefer to get Docker images since they'd be easier for them to manage than "virtual appliance" VMs.
Another difference was that I use Firebase for the app's datastore and Google doesn't (and likely never will) offer an on-premises version. This was a show-stopper for nearly all customers, but it turned out that offering at-rest encryption of sensitive data with a key that never leaves their premises was sufficient to get through many of the security reviews. This obviously won't be acceptable to everyone but it can be useful to know that even if you have a fundamental dependency on an external third-party service there may be a way to keep using it in your "on-premises" product.
Can we trade customers? Last year I've had to install our software in a CentOS 5.5 system. With no root access. Can't say compiling Python 2.7 and all that crap to run on a user account was much fun, but hey, at least they're billable hours.
Large, and especially public, companies seem to be the worst. SMBs were happy to receive a VM or OpenVZ image.
Quick edit: That's vertical scaling if you have a single server that you make bigger.
But I'd say the real value is in not needing to support an additional deployment platform -- their Docker based approach is like Heroku for on-prem, it abstracts the infrastructure details and just works.
Does Replicated assist with this database/persistence layer? Perhaps by helping you to spin up the DB as a separate VM on the clients' side?
Replicated allows for the end customer to choose if they want to run the containerized version of the database, or provide their own instance of it (not in a container) and simply provide a connection string so the application can use that instance. Generally this is exposed as a checkbox on the settings page, and doesn't require a lot of configuration.
If the end customer decides to install with the containerized version of the database, they can choose to run the database container on a specific instance (or instances) and control the host path of the volume mount(s). The idea here is that they will store the data on an EBS volume, network attached storage etc.
We also have a feature that allows for snapshots and restores to help in the scenario where the database was store on the local instance and there was a hardware failure or corruption.
These features work out of the box, without a lot of effort from the software vendor to configure.
After reading your docs and install scripts, I think another option for us is to run the database directly on the client's host. That is, as part of our installation guide, we'd say Step1:Install Replicated, Step2:Install DB, Step3:Run setup. This might be easier in a trusted environment where containers can be started on the host network. This approach has potential issues with replication, encryption, upgradeability, etc, but those are normal infrastructure challenges and have nothing to do with Replicated.
I haven't moved forward with that yet, but if I do, Replicated will be the team we work with. Ben spent a lot of time on a web hookup teaching me about Docker containers, and even suggesting how we might improve our development environments and processes (without using Replicated anywhere in the solution).
I think ReadMe's approach is pretty good, and I applaud them for making the move.
Our aim is a bit different from others, as we focus exclusively on "actual" on-premises (local virtual machines), as opposed to "on someone else's premises" (AWS).
[1] http://blog.unscramble.co.jp/post/128610241043/production-re...
Its great to see more startup support in this weak area. I really hope replicated/gravitational succeed, and perhaps more articles can be written to help the rest of us reduce the procrastination or fear of taking the steps toward supporting enterprise.
After having a look at the installation shell script, Replicated itself seems to run in containers and therefore should be deployable on DC/OS or the likes if I understand correctly...
I'm especially interested in DC/OS, because my company is building a SaaS in it, and ideally we'd want a general solution on how to ship and maintain an on-premise deployment.