Live data from Hacker News

We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

blog.mikoto.io

31–40 of 74 posts

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#31
post #22

Earlier quoted context omitted.

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fiddling with the production environment manually. I know, it's overkill and I don't like it that much either, but it's the industry standard.

You can get declarative deployments via a systemd config. If you really want to use Docker then use a Compose file. If jobs are what you are concerned about then I can assure you no company is skipping on software developers because they don't know Kubernetes syntax.

imo systemd is more complicated than k3s

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#32
post #22

Earlier quoted context omitted.

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fiddling with the production environment manually. I know, it's overkill and I don't like it that much either, but it's the industry standard.

You can get declarative deployments via a systemd config. If you really want to use Docker then use a Compose file. If jobs are what you are concerned about then I can assure you no company is skipping on software developers because they don't know Kubernetes syntax.

That doesn't capture the same thing. It doesn't capture volumes, versions of binaries, nginx/postgres/whatever configs, etc.

Ansible/Salt/Puppet/Chef/CFEngine are closer comparisons.

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#33
post #9

Not really. You didn't factor in the time it takes to manage k3s yourself versus GKE which is managed.

Self management could be expensive if it’s actually going to burn hours of dev time. At teensy scale is k3s really gonna take much “management” after the bring-up? I don’t think so. For a teensy team, it seems totally worth it to take a runway from 12 months to 40 months for the price of a few afternoon’s work.

This. Just upgrading this made me (a fresh university grad with minimum savings) basically and my startup "default alive" so that the startup can be bootstrapped

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#34
post #7

It's wild to me that we are talking about a site running on a single 2 core VPS costing $15/mo and the developer didn't stop to consider that maybe they don't need Kubernetes for this. Like...just run your damn services on the box like we've been doing since web hosting first became a thing.

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fiddling with the production environment manually. I know, it's overkill and I don't like it that much either, but it's the industry standard.

For a tiny deployment like this, Docker Compose gets you declarative deployments in much the same way with arguably a much smaller learning curve and fewer moving parts.

I self-host ~10 services on a single physical server in my home, defined in a series of docker-compose.yaml files stored in a git repo. It's trivial to set up, declarative, and easier to run locally than k8s.

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#36
post #7

It's wild to me that we are talking about a site running on a single 2 core VPS costing $15/mo and the developer didn't stop to consider that maybe they don't need Kubernetes for this. Like...just run your damn services on the box like we've been doing since web hosting first became a thing.

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fiddling with the production environment manually. I know, it's overkill and I don't like it that much either, but it's the industry standard.

A different angle -- Ansible and many others provide declarative deployments too.

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#37

As an SRE who’s moved between a few companies recently, I’ve noticed a trend towards simpler infrastructure options rather than k8s. Most places I interviewed at used AWS with just fleets of EC2s managed through ASG and instance refresh. Deployments are no downtime. It’s pretty nice and if you want to run with docker on the host instances you can but you can also just install the application using systemd.

This is what we do for GCE. Our CI builds a system image and then that's deployed across our datacentres. Worked perfectly for years, but still people want to switch to kubernetes. What can you do?

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#38
post #22

Earlier quoted context omitted.

You can get declarative deployments via a systemd config. If you really want to use Docker then use a Compose file. If jobs are what you are concerned about then I can assure you no company is skipping on software developers because they don't know Kubernetes syntax.

That doesn't capture the same thing. It doesn't capture volumes, versions of binaries, nginx/postgres/whatever configs, etc. Ansible/Salt/Puppet/Chef/CFEngine are closer comparisons.

With Docker Compose you can define volumes, versions, and configs can be volumes that point to a file that lives alongside your compose.yaml.

Re: We cut costs by 70% by moving from GCP and CockroachDB to Hetzner and PostgreSQL

#39
post #7

It's wild to me that we are talking about a site running on a single 2 core VPS costing $15/mo and the developer didn't stop to consider that maybe they don't need Kubernetes for this. Like...just run your damn services on the box like we've been doing since web hosting first became a thing.

For a single node cluster, just use minikube (or RKE2 if you have masochistic tendencies). And if everything runs on a single small vps, why even use postgres and not SQLite.

k3s (512mb ram suggested) is smaller than minikube (2gb ram suggested)
Post reply on HN