Comment by twakefield | Hacker News Reader

Comment by twakefield | Hacker News Reader

A few reasons why we started working on this for some additional context:

1) We think developers have had to take on too much responsibility for operating the software they build (DevOps). We hope to create more clearly defined roles for developers and operators through better tooling for operators.

2) A lot of the engineering challenges with SaaS comes from multi-tenancy, which is one of the reasons Dev and Ops have merged into one role.

3) A big reason to use cloud software is that you (as a user) don't have to operate it but that has been conflated with the requirement that you need to give up control of your data.

4) Adoption of containers (Docker[0], Rkt[1]) and container orchestration (Mesos[2], Kubernetes[3]) technology have created the opportunity to rethink the traditional model for delivering and operating software.

[0]: https://www.docker.com/

[1]: https://github.com/coreos/rkt

[2]: http://mesos.apache.org/

[3]: http://kubernetes.io/

Edit: added some examples of container and orchestration tech with links

I find (2) curious, as our pains come from trying to build a single-tenant (as in 1 process per client, not 1 machine per client) hosted SaaS offering. Everywhere I look, there's plenty of tooling written for multi-tenant, distributed webapps, but barely anything if you want to automate the creation and management of isolated "instances" (subdomain + process + database).

We've built some manual deployment scripts for creating new instances, but having to build everything ourselves has been time-prohibitive. I really wish I could find some ready-made tools for our use case.

Hmm... interesting. I wonder how you define a "tenant" and how tenant affinity is applied to a connection (routing). I doubt you're talking about process-per-web-request, in that case a good ole CGI would do.

Shoot me an email to ev@kontsevoy.com, will be glad to chat more about this.

Not process-per-web-request, but a process-per-account. We route using DNS, by giving each accounts its own subdomain. Essentially, think something like WPEngine, except for a different software.

1st idea that comes to mind:

    1. Package your per-tenant application into a Kubernetes 
       pod (think of it as a lightweight VM, a collection of 
       Docker containers running on a same host).
    2. Write a request router: someone needs to look up tenants 
       based on the virtual hostname in a request.
    3. Use k8s API to find a pod with label == tenant. If 
       doesn't exist -> create one.
    4. Forward the request there.

I'd imagine you'll have to "garbage collect" and gracefully shutdown pods when they sit idle for a while. I'd probably pack that logic into a pod itself.

I have to thank you; I had seen the Pods concept, but didn't look deeply, since it sounded like they only managed the application itself, while I also need to manage data (primarily client databases) within the pods.

But now I see that Pods support some really interesting data volume management systems that could support moving it around if we need to migrate Pods between hosts.

Thanks!

How is this different from one of the more fully featured systems like OpenShift or Apprenda?

They are orchestration systems for clusters, and Gravitational offers tooling to aggregate thousands of them (owned by 3rd parties) to simplify operations.

...except we decided against using these PaaSes and placed a bet on Kubernetes.

In fact, our belief is that developers should think less about orchestration and let other people do the work. Kubernetes offers a perfect set of abstractions to make this thinking practical.

Reply on news.ycombinator.com