3 ms·

Recently just built and deployed an enterprise (on-prem) offering for my startup https://commando.io https://commando.io. The single biggest problem by far was

Recently just built and deployed an enterprise (on-prem) offering for my startup https://commando.io 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 } If/else in the master branch is what GitHub Enterprise does as well (at least was told so).

marcc 10y ago
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.
rymohr 10y ago
Good advice, definitely want to keep everything in a single branch. 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 } [1]: https://kumu.io/ https://kumu.io/

marcc 10y ago

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.

rymohr 10y ago

Good advice, definitely want to keep everything in a single branch. 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 } [1]: https://kumu.io/ https://kumu.io/