3 ms·

This is a good articulation of the ambivalence I can feel around this. One approach that I’ve considered is to start with the standard tooling (k8s + gitops) f

This is a good articulation of the ambivalence I can feel around this. One approach that I’ve considered is to start with the standard tooling (k8s + gitops) from day one, but still run it in a single VM. Any thoughts?

shakiXBT 2y ago
k3s single node + ArgoCD/Flux is what I would if I had to build infrastructure of a small startup by myself. Unfortunately it's HN so people are more likely to do everything in bash scripts and say a big "fuck you" to all new hires that would have to learn their custom made mess
- bjornsing 2y ago
  This is exactly the setup I’ve been considering. Feels like the best of both worlds: you learn the standard tooling and can easily upgrade to full blown distributed k8s, but you retain the flexibility and low cost aspects of single VM. Also leaning towards putting it behind a Cloudflare tunnel and having managed Postgres for both k3s and application state. Counterpoints anyone?
  - mlnj 2y ago
    No counterpoints from me. Have been running k3sup provisioned nodes on Hetzner for services and even a Stackgres managed Postgres cluster on another node (yes, it backs up to the cloud). And it's been great. Incredibly low cost and I do not have to think about running out if compute or memory for everything I need for a tiny startup.
imiric 2y ago
There's no correct answer here. Your choice seems reasonable _if_ you already have some previous familiarity with managing k8s. If not, you might want to consider starting with a managed k8s solution from a cloud provider. The bulk of the work will be containerizing your stack, and getting familiar with all the concepts. You don't want to do all that while also keeping k8s running. After that you would be able to relatively easily migrate to a self-hosted cluster if you need to. If you do want to self-host, k3s could also be an option, like a sibling comment suggested. It's simpler to start with, though it still has a learning curve since it's a lightweight version of k8s. I reckon that you would still want to run at least 3 nodes for redundancy/failover, and maybe a couple more for just DB workloads. But you can certainly start with one to setup your workflow, and then scale out to more nodes as needed.

shakiXBT 2y ago

k3s single node + ArgoCD/Flux is what I would if I had to build infrastructure of a small startup by myself. Unfortunately it's HN so people are more likely to do everything in bash scripts and say a big "fuck you" to all new hires that would have to learn their custom made mess

bjornsing 2y ago
This is exactly the setup I’ve been considering. Feels like the best of both worlds: you learn the standard tooling and can easily upgrade to full blown distributed k8s, but you retain the flexibility and low cost aspects of single VM. Also leaning towards putting it behind a Cloudflare tunnel and having managed Postgres for both k3s and application state. Counterpoints anyone?
- mlnj 2y ago
  No counterpoints from me. Have been running k3sup provisioned nodes on Hetzner for services and even a Stackgres managed Postgres cluster on another node (yes, it backs up to the cloud). And it's been great. Incredibly low cost and I do not have to think about running out if compute or memory for everything I need for a tiny startup.

imiric 2y ago

There's no correct answer here. Your choice seems reasonable _if_ you already have some previous familiarity with managing k8s. If not, you might want to consider starting with a managed k8s solution from a cloud provider. The bulk of the work will be containerizing your stack, and getting familiar with all the concepts. You don't want to do all that while also keeping k8s running. After that you would be able to relatively easily migrate to a self-hosted cluster if you need to. If you do want to self-host, k3s could also be an option, like a sibling comment suggested. It's simpler to start with, though it still has a learning curve since it's a lightweight version of k8s. I reckon that you would still want to run at least 3 nodes for redundancy/failover, and maybe a couple more for just DB workloads. But you can certainly start with one to setup your workflow, and then scale out to more nodes as needed.