Live data from Hacker News

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

blog.mikoto.io

51–60 of 74 posts

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

#51

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.

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

No, … Ansible is not declarative. Nowhere near the same as a k8s workload.

And I know they say that, but it's more or less YAML-as-a-programming language. It is pretty trivial to have side-effects that will persist well beyond and outside an Ansible playbook.

It's certainly better than a complete snowflake of a VM, but it's really closer to saying "we init this VM with this shell script."

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

#52

Seems strange to have used CockroachDB but not leverage any of the distributed nature of it? I was looking forward to some interesting database problems in this article, but it was quite anticlimactic.

There were also some performance issues regarding the read/writes compared to plain PostgreSQL, but these were relatively minor compared to issues with the extensions and tooling

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

#53
post #4

48.08 USD per month on a single-node GKE cluster w/ 2 cores 4 gigs -> 15.34 USD per month Hetzner VPS w/ 4 cores 8 gigs.

48 seems really low to me, I've never seen a k8s cloud cluster for less then 100-150 a month on the very low end, also doesn't take egress into account how do you even run a k8s cluster "on 2 cores 4 gigs", don't you need at least 3 nodes?

You need 3 nodes for a high availability control plane if you’re managing the Kubernetes control plane yourself.

With GKE, the control plane is totally managed by Google Cloud, things like etcd etc are not running on any of your instances.

It’s fine to have just 1 compute node (like the before state), or to put all the k8s control plane on a single node (like the after state) if you don’t need high availability.

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

#54
post #4

48.08 USD per month on a single-node GKE cluster w/ 2 cores 4 gigs -> 15.34 USD per month Hetzner VPS w/ 4 cores 8 gigs.

48 seems really low to me, I've never seen a k8s cloud cluster for less then 100-150 a month on the very low end, also doesn't take egress into account how do you even run a k8s cluster "on 2 cores 4 gigs", don't you need at least 3 nodes?

It would have to be a zonal cluster, I think. A regional cluster would have 3 nodes, minimum (ish¹).

(Unless maybe if you can do a two-zone regional cluster? But I'm not sure why you'd ever do that, though. I don't have much experience w/ the zonal ones, since typically we want our service spread across multiple failure domains. OP seems to be in the bootstrap phase, so the cost savings might be > the reliability at their present scale, to them, which I can respect.)

¹you can have a zero node regional cluster, but it isn't going to do much work.

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

#55
post #24

The time investment here doesn’t really make sense to me. That 70% savings was actually only $33 a month. Was it really worth spending that dev time and effort for such a small return rather than the product itself? And yea now you get to manage your own cluster… thats an ongoing cost too, not free.

Now they get to write an article about it.

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

#56

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.

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.

It’s a bit weird to me to mention compose and kubernetes without bringing up Docker Swarm which feels like a nice middle ground. We actually run it at my very small SaaS company and it seems like a good fit for us though it’s still relatively early days for us; it’s been a very slow transition.

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

#57

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.

Use docker compose or ansible for this scenario.

Those seem like different things, I thought Ansible was more for configuring individual boxes.. then you would use something like Helm to configure Kubernetes.

Tech stack at my last workplace was insane like that. To deploy, they woud have a Buildkite job would launch Terraform, which would then be configured by Ansible, then k8s would deploy on the cluster. I think they could have avoided all this ess k8s and probably Terraform and gotten away with one big box and shell scripts (which they had plenty of anyway), and used swarm/compose, but what do I know.

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

#58

Earlier quoted context omitted.

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.

It’s a bit weird to me to mention compose and kubernetes without bringing up Docker Swarm which feels like a nice middle ground. We actually run it at my very small SaaS company and it seems like a good fit for us though it’s still relatively early days for us; it’s been a very slow transition.

I've never used Swarm myself, so I don't recommend it. I've heard several people like you, though, who found it works.

Obviously not needed for a single node, though.

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

#59

Earlier quoted context omitted.

> but it's the industry standard. I strongly disagree with this statement. Even at the most bubbly of Silicon Valley events you will not see kubernetes for a smaller deployment be an industry standard. It’s ok to make architectural mistakes, or otherwise over engineer a thing. We all do it. Let’s not standardize it. And to your credit thank you for publishing this example as a learning opportunity to others.

I mean as in what the big (and small) clouds support. I haven't seen any clouds supporting Hashicorp Nomad or Docker Swarm!

You shoudl be able to run any of those things on any cloud. A box with sshd is a box with sshd.

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

#60
post #53

Earlier quoted context omitted.

48 seems really low to me, I've never seen a k8s cloud cluster for less then 100-150 a month on the very low end, also doesn't take egress into account how do you even run a k8s cluster "on 2 cores 4 gigs", don't you need at least 3 nodes?

You need 3 nodes for a high availability control plane if you’re managing the Kubernetes control plane yourself. With GKE, the control plane is totally managed by Google Cloud, things like etcd etc are not running on any of your instances. It’s fine to have just 1 compute node (like the before state), or to put all the k8s control plane on a single node (like the after state) if you don’t need high availability.

interesting thanks, do you know if AWS offers something like that as well?
Post reply on HN