21–24 of 24 posts
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...
Are there any plans yet on how to use Replicated on existing on-premise cluster installations, like DC/OS or Kubernetes? 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...
Are there any plans yet on how to use Replicated on existing on-premise cluster installations, like DC/OS or Kubernetes? 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...
Hi toblig. Absolutely. We do have support for installing Replicated on an existing Kubernetes cluster. For these installs, we provide a couple of k8s yaml files to create the deployment, service, etc on the cluster. It's still a beta feature, but we like the idea of supporting other schedulers.
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.
Recently 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…
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
}