4 ms·

> Web servers upgraded to Hetzner’s AX42 (AMD 8700GE, 8 cores). On the old machines, saw a few nonsensical Python exceptions. A kernel update and a reboot didn’

> Web servers upgraded to Hetzner’s AX42 (AMD 8700GE, 8 cores). On the old machines, saw a few nonsensical Python exceptions. A kernel update and a reboot didn’t fix it. Rather than messing with hardware troubleshooting, I upgraded to newer, faster, and more efficient machines. > Database servers upgraded to Hetzner’s EX101 (Intel 13900, 8+16 cores). I was setting up new database replicas after an outage and failover event and took the opportunity to upgrade hardware. Does anybody know if this setup is containerized? I have to say, I love that this is running on dedicated servers. I don't know how many times I burned myself out trying to setup infrastructure in AWS for personal projects only to accumulate a significant monthly bill and nothing substantial to show for it.

rvnx 2y ago
From the blog posts: > Main values: Simple is good. Efficient is good. Less is more. > The core infrastructure runs on Hetzner bare metal machines. Hetzner offers amazing value for money and is a big part of the reason why Healthchecks.io can offer its current pricing. > No containers, no auto-scaling, no “serverless”. Plain old servers, each dedicated to a single role: “load balancer”, “application server” and “database server”. > The machines are closer to “pets” than “cattle”: I have provisioning scripts to set up new ones relatively quickly, but in practice the working set of machines changes rarely. For example, the primary database server currently has an uptime of 375 days.
- killingtime74 2y ago
  Further here (https://blog.healthchecks.io/2022/02/healthchecks-io-hosting-setup-2022-edition/ https://blog.healthchecks.io/2022/02/healthchecks-io-hosting...) it says no auto fail over.
- rco8786 2y ago
  So much nostalgia reading that. I wish we could go back
  - sgarland 2y ago
    Nothing is stopping you. Reject modernity, embrace stability.
  - aprdm 2y ago
    fwiw that's what most of the big companies do on their product that actually make money. All the "kubernetes revolution" is pretty new, as are contianers, and companies move very slowly. The core products only move if they really see an advantage
  - forgetfreeman 2y ago
    Oh, we will. This is just another swing of the fat-vs-thin client pendulum.
  - Toutouxc 2y ago
    There are tens of thousands of companies who continue to work that way. You don't hear about them often, because there's nothing to write about.
myaccountonhn 2y ago
If you're using Go, Rust, OCaml etc. then you can deploy a static binary and have a systemd-service or similar take care of keeping it running with nginx as a reverse-proxy. I do that with NixOS which enables me to also have my infra as code. Another simpler alternative is to just run a cgi-bin on hetzner webhosting (https://www.hetzner.com/webhosting/level-9/ https://www.hetzner.com/webhosting/level-9/).
- creesch 2y ago
  Static binaries make things easier, but even without them things can be quite manageable depending on what you need. I suppose it sits halfway in between as you do need the java runtime, but with fat jars you can also quite reliably and easily run on bare metal managed through systemd. There are a few things to consider outside of that, though those are also fairly easy to manage. Log rotation and clean up is something a lot of cloud native people will not be familiar with.

rvnx 2y ago

From the blog posts: > Main values: Simple is good. Efficient is good. Less is more. > The core infrastructure runs on Hetzner bare metal machines. Hetzner offers amazing value for money and is a big part of the reason why Healthchecks.io can offer its current pricing. > No containers, no auto-scaling, no “serverless”. Plain old servers, each dedicated to a single role: “load balancer”, “application server” and “database server”. > The machines are closer to “pets” than “cattle”: I have provisioning scripts to set up new ones relatively quickly, but in practice the working set of machines changes rarely. For example, the primary database server currently has an uptime of 375 days.

killingtime74 2y ago
Further here (https://blog.healthchecks.io/2022/02/healthchecks-io-hosting-setup-2022-edition/ https://blog.healthchecks.io/2022/02/healthchecks-io-hosting...) it says no auto fail over.
rco8786 2y ago
So much nostalgia reading that. I wish we could go back
- sgarland 2y ago
  Nothing is stopping you. Reject modernity, embrace stability.
- aprdm 2y ago
  fwiw that's what most of the big companies do on their product that actually make money. All the "kubernetes revolution" is pretty new, as are contianers, and companies move very slowly. The core products only move if they really see an advantage
- forgetfreeman 2y ago
  Oh, we will. This is just another swing of the fat-vs-thin client pendulum.
- Toutouxc 2y ago
  There are tens of thousands of companies who continue to work that way. You don't hear about them often, because there's nothing to write about.

myaccountonhn 2y ago

If you're using Go, Rust, OCaml etc. then you can deploy a static binary and have a systemd-service or similar take care of keeping it running with nginx as a reverse-proxy. I do that with NixOS which enables me to also have my infra as code. Another simpler alternative is to just run a cgi-bin on hetzner webhosting (https://www.hetzner.com/webhosting/level-9/ https://www.hetzner.com/webhosting/level-9/).

creesch 2y ago
Static binaries make things easier, but even without them things can be quite manageable depending on what you need. I suppose it sits halfway in between as you do need the java runtime, but with fat jars you can also quite reliably and easily run on bare metal managed through systemd. There are a few things to consider outside of that, though those are also fairly easy to manage. Log rotation and clean up is something a lot of cloud native people will not be familiar with.