Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

techcrunch.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#21

Post by icebraining »

old-gregg wrote: post #20
icebraining wrote: post #16

Earlier quoted context omitted.

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…

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.

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#22

Post by old-gregg »

icebraining wrote: post #21
old-gregg wrote: post #20

Earlier quoted context omitted.

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.

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#23

Post by pm »

old-gregg wrote: post #18
pm wrote: post #15

Curious, was just thinking about this the other day. What does Gravitational offer in the way of special sauce that can't be achieved just be working with Docker/Kubernetes directly? What cost to the developer? How are you taking on customers at the moment? Just asking because I was in the planning stages for something and this was the first step to what I wanted to achieve. I don't know if it's worth learning Docker…

Sure, Docker and Kubernetes are fine tools for deploying and orchestrating an application into an environment you have full control over (typical SaaS scenario). Our "distribution" of Kubernetes is optimized for running in "hostile" unknown environments with varied networks, storage, etc. It comes in HA-configuration with self-updating and self-monitoring turned on. Secondly, once you have thousands of instances depl…

I am the team I am afraid, and only at the planning stage so there is no code to speak of as yet. I'm in Australia so it might be better to send an e-mail and see what can be done. Thanks for the info.

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#24

Post by avifreedman »

Hi, looks interesting...

Some questions:

All based on what we do at Kentik, where we run a large distributed column store with high speed data ingest layers feeding it, and a relatively more easy core cluster of portal/high-level metadata nodes. Ingest nodes are 20 core low-disk and data nodes 36-core 24x2tb disk w/ ZFS, which we rely on for compression.

We use docker but on top of known equipment types of deterministic latency and performance. Machines are netbooted and much of the system is controlled by puppet push. Typical clusters range from 10 to low hundreds of nodes. We do on-prem but they are typically on top of bare metal and using our control stack.

So with that as background...

For an application that requires high speed native (in particular disk) performance and persistent disk to run, how is Gravitational requiring that at deployment time?

Is there an ability to add metrics to dashboards for on-prem 'operators' to access? Send those through logged mail gateways for SaaS companies to watch on-prem status remotely, at least at an aggregate level (dashboards plus perhaps some log excerpts)? Have part-time (customer-controlled) logged ssh gateways for supervised and/or logged remote access by SaaSco engineers?

How do you do versioning, deployment, and distributed rollout to running systems with 24x7x100% uptime expectation? Is there the ability to support partial upgrade of only some nodes of specific roles followed by automated and/or human checks? How about rollback?

Thanks, and good luck with the company!

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#25

Post by old-gregg »

avifreedman wrote: post #24

Hi, looks interesting... Some questions: All based on what we do at Kentik, where we run a large distributed column store with high speed data ingest layers feeding it, and a relatively more easy core cluster of portal/high-level metadata nodes. Ingest nodes are 20 core low-disk and data nodes 36-core 24x2tb disk w/ ZFS, which we rely on for compression. We use docker but on top of known equipment types of determinis…

Hey Avi,

I'll try to be concise:

  - There is no performance penalty.
  - We can do hardware profiling prior to installation/upgrade to 
    guarantee capabilities as defined in the system requirements 
    for an application.
  - Updates are applied in a "rolling" fashion with rollbacks in 
    case of a failure.
  - No, I am afraid we cannot not do 24x7x100% the application needs 
    to be designed to deliver this.
Happy to dive into the details. Your profile doesn't have an email address listed, ping me at ev@gravitational.com!

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#26

Post by icebraining »

old-gregg wrote: post #22
icebraining wrote: post #21

Earlier quoted context omitted.

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 h…

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!

Re: Gravitational (YC S15): Software On-Prem or in Cloud from Single Code Base

#27

Post by avifreedman »

old-gregg wrote: post #25
avifreedman wrote: post #24

Hi, looks interesting... Some questions: All based on what we do at Kentik, where we run a large distributed column store with high speed data ingest layers feeding it, and a relatively more easy core cluster of portal/high-level metadata nodes. Ingest nodes are 20 core low-disk and data nodes 36-core 24x2tb disk w/ ZFS, which we rely on for compression. We use docker but on top of known equipment types of determinis…

Hey Avi, I'll try to be concise: - There is no performance penalty. - We can do hardware profiling prior to installation/upgrade to guarantee capabilities as defined in the system requirements for an application. - Updates are applied in a "rolling" fashion with rollbacks in case of a failure. - No, I am afraid we cannot not do 24x7x100% the application needs to be designed to deliver this. Happy to dive into the det…

avi @ kentik is my email but I'll ping you.

So HW profiles can include IOPS and throughput testing, disk space, etc?

The 24x7x100% is more of a concern re: not restarting all VMs at once, or at least being able to specify subsets and rollout orders.

Will take to email to discuss further.

thanks

Post reply on HN