How ReadMe Went from SaaS to On-Premises in Less Than One Week
1–10 of 24 posts
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#2Here at Coveralls.io we can't recommend Replicated enough. We were able to migrate our internally-developed, Github Enterprise style packaged VM delivery approach over to their system in a couple weeks.
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.
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#3It's nice to see some momentum building behind the idea that multi-tenant SaaS doesn't have to be your only deployment. And congrats to the Replicated folks on the recent raise. It's great to see people validating these ideas/offerings. Based on mainstream tech press, you sometimes feel crazy working on something perceived as "anti-cloud".
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#4Here at Coveralls.io we can't recommend Replicated enough. We were able to migrate our internally-developed, Github Enterprise style packaged VM delivery approach over to their system in a couple weeks. 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.
Container folks currently advise to not put the database into a container unless you really really really know the internals of both. Even Kelsey Hightower stressed this in a talk - "if you want to keep your job, keep databases out of containers". ReadMe had no prior Docker experience, and they started by putting Mongo (which is complex to manage as is) into a container. This would make me uneasy.
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?
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#5Nice post from Readme.io, and I also want to shout out to Ben @ Replicated. He reached out to me when we launched our cloud HR SaaS offering, and talked about the possibilities of offering an enterprise on premise version using 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).
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#6Here at Coveralls.io we can't recommend Replicated enough. We were able to migrate our internally-developed, Github Enterprise style packaged VM delivery approach over to their system in a couple weeks. 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.
Container folks currently advise to not put the database into a container unless you really really really know the internals of both. Even Kelsey Hightower stressed this in a talk - "if you want to keep your job, keep databases out of containers". ReadMe had no prior Docker experience, and they started by putting Mongo (which is complex to manage as is) into a container. This would make me uneasy. Does Replicated ass…
Replicated founder here. Great question. The main concern most people have when considering putting a database in a container is around data loss or corruption. (i.e. What happens if the instance disappears and the data was stored on an ephemeral disk?) We have a couple of features to help with this:
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.
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#7Earlier quoted context omitted.
Container folks currently advise to not put the database into a container unless you really really really know the internals of both. Even Kelsey Hightower stressed this in a talk - "if you want to keep your job, keep databases out of containers". ReadMe had no prior Docker experience, and they started by putting Mongo (which is complex to manage as is) into a container. This would make me uneasy. Does Replicated ass…
Replicated founder here. Great question. The main concern most people have when considering putting a database in a container is around data loss or corruption. (i.e. What happens if the instance disappears and the data was stored on an ephemeral disk?) We have a couple of features to help with this: Replicated allows for the end customer to choose if they want to run the containerized version of the database, or pro…
Thanks, Marc.
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.
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#8Thanks for writing about your experiences. Its a weak spot for most of us, and it was a refreshing kick in the butt, to get ourselves in gear about this topic which has been on our mind for a long time.
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.
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#9Recently just built and deployed an enterprise (on-prem) offering for my startup https://commando.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
}
Re: How ReadMe Went from SaaS to On-Premises in Less Than One Week
#10Recently just built and deployed an enterprise (on-prem) offering for my startup https://commando.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 a…
This is great advice. Sometimes services can be removed from the on-prem version (billing), but some (queues, auth) need to find an on-prem compatible replacement. Most of the time, there are reasonable alternatives. But there are a lot of "on-prem" environments that run in AWS, so don't be afraid to start with an AWS-only "on-prem" version.
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.