Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem Kubernetes solves is "how do I deploy this" ... so I go to Rivet (which does look cool) docs, and the options are:

* single container

* docker compose

* manual deployment (with docker run commands)

But erm, realistically how is this a viable way to deploy a "serverless infrastructure platform" at any real scale?

My gut response would be ... how can I deploy Rivet on Kubernetes, either in containers or something like kube-virt to run this serverless platform across a bunch of physical/virtual machines? How is docker compose a better more reliable/scalable alternative to Kubernetes? So alternately then you sell a cloud service, but ... that's not a Kubernetes 2.0. If I was going to self-host Rivet I'd convert your docs so I could run it on Kubernetes.



Our self-hosting docs are very rough right now – I'm fully aware of the irony given my comment. It's on our roadmap to get them up to snuff within the next few weeks.

If you're curious on the details, we've put a lot of work to make sure that there's as few moving parts as possible:

We have our own cloud VM-level autoscaler that's integrated with the core Rivet platofrm – no k8s or other orchestrators in between. You can see the meat of it here: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...

For example, Rivet has an API to dynamically spin up a cluster on demand: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...

Once you start the Rivet "seed" process with your API key, everything from there is automatic.

Therefore, self-hosted deployments usually look like one of:

- Plugging in your cloud API token in to Rivet for autoscaling (recommended)

- Fixed # of servers (hobbyist deployments that were manually set up, simple Terraform deployments, or bare metal)

- Running within Kubernetes (usually because it depends on existing services)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: