6 ms·

Every time I see this kind of article, no one really bothers about sb/server redundancy, load balancers, etc. are we ok with just 1 big server that may fail and

by mariopt 6mo ago

Every time I see this kind of article, no one really bothers about sb/server redundancy, load balancers, etc. are we ok with just 1 big server that may fail and bring several services down? You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.

timwis 6mo ago
I wondered the same! FWIW I'm currently migrating from managed postgres to self-managed on hetzner with [autobase](https://autobase.tech/ https://autobase.tech/). Though of course for high availability it requires more than one server.
- matteocontrini 6mo ago
  Beware of Hetzner Cloud volumes, they're unusable for a database, they're too slow. I'm not sure what workloads people run on Hetzner but the low-performance volumes and unreliable load balancers don't seem like a good fit for real production stuff with traffic.
  - arter45 6mo ago
    How slow is “too slow”? Do you happen to have any benchmark?
    - matteocontrini 6mo ago
      I've run some benchmarks a couple years ago, I don't have them at hand unfortunately but off the top of my mind, seqread 4k produced around 1500 IOPS while seqwrite was like a third of that. The practical performance was abysmal, I moved PostgreSQL storage to a volume and it was very noticeably slower just by browsing the web app (compared to NVMe SSD storage). For comparison, I'm now using UpCloud which uses network-attached storage for all volumes and easily hits 10k IOPS (up to 100k with some tuning). I certainly may have missed something while testing this so I'm happy if someone else wants to contribute and correct me if I'm wrong.
grey-area 6mo ago
It depends on the service and how critical that website is. Sometimes it's completely acceptable that a server will run for 10 years with say 1 week or 1 month of downtime spread over those 10 years, yes. That's the sort of uptime you can see with single servers that are rarely changed and over-provisioned as many on Hetzner are. Some examples: Small businesses where the website is not core to operations and is more of a shop-front or brochure for their business. Hobby websites too don't really matter if they go down for short periods of time occasionally. Many forums and blogs just aren't very important too and downtime is no big deal. There are a lot of these websites, and they are at the lower end of the market for obvious reasons, but probably the majority of websites in fact, the long tail of low-traffic websites. Not everything has to be high availability and if you do want that, these providers usually provide load balancers etc too. I think people forget here sometimes that there is a huge range in hosting from squarespace to cheap shared hosting to more expensive self-hosted and provisioned clouds like AWS.
- rzz3 6mo ago
  What struck me though is that OP did so much work to migrare the server with zero downtime. The _single_ big server. Something’s off here.
  - j45 6mo ago
    There is software that can help a lot. Also, in general, you can architect your application to be more friendly to migration. It used to be a normal thing to think about and plan for. VMware has a conversion tool that converts bare metal into images. One could image, then do regular snapshots, maybe centralize a database being accessed. Sometimes it's possible to create a migration script that you run over and over to the new environment for each additional step. Others can put a backup server in between to not put a load on the drive. Digital Ocean makes it impossible to download your disk image backups which is a grave sin they can never be forgiven for. They used to have some amount of it. Still, a few commands can back up the running server to an image, and stream it remotely to another server, which in turn can be updated to become bootable. This is the tip of the iceberg in the number of tasks that can be done. Someone with experience can even instruct LLMs to do it and build it, and someone skilled with LLMs could probably work to uncover the steps and strategies for their particular use case.
daneel_w 6mo ago
They may be making this decision based on a long history of, in fact, never really having run into "a lot of time in maintenance and future headaches".
- VorpalWay 6mo ago
  To be fair, I migrated a VPS from Linode to Hetzner a few years ago. Minor downtime is a non-issue: personal website and email server. I approximately halved the monthly cost, and I haven't had any downtime except what I caused myself when rebooting to upgrade the kernel every now and then. As a bonus, Hetzner is European.
Aurornis 6mo ago
These articles are popular where there's a mismatch between application requirements and the solution chosen. When someone over-engineers their architecture to be enterprise-grade (substitute your own definition of enterprise-grade) when really they were running a hobby project or a small business where a day of downtime every once in a while just means your customers will come back the next day, going all-out on cloud architecture is maybe not necessary. That's why you see so many comments from people arguing that downtime isn't always a big deal or that risking an outage is fine: There are a lot of applications where this is kind of true. The confusing part about this article is the emphasis on a zero-downtime migration toward a service that isn't really ideal for uptime. It wouldn't be that expensive to add a little bit of architecture on the Hetzner side to help with this. I guess if you're doing a migration and you're paid salary or your time is free-ish, doing the migration in a zero downtime way is smart. It's a little funny to see the emphasis on zero downtime juxtaposed to the architecture they chose where uptime depends on nothing ever failing
- j45 6mo ago
  Downtime is a strawman. Clever architecture will always beat cleverly trying to pick only one cloud. Being cloud agnostic is best. This means setting up a private cloud. Hosted servers, and managed servers are perfectly capable of near zero downtime. this is because it's the same equipment (or often more consumer grade) that the "cloud" works on and plans for even more failure. Digital Ocean definitely does not guarantee zero downtime. That's a lot of 9's. It's simple to run well established tools like Proxmox on bare metal that will do everything Digital Ocean promises, and it's not susceptible to attacks, or exploits where the shared memory and CPU usage will leak what customers believe is their private VPS. Nothing ever failing in the case of a tool like Proxmox is, install it on two servers, one VPS exists on both nodes (you connect both servers as nodes), click high availability, and it's generally up and running. Put cloudflare in front of it like the best preference practices of today. If you're curious about this, there's some pretty eye opening and short videos on Proxmox available on Youtube that are hard to unsee.
  - nine_k 6mo ago
    Sadly, hardware breaks. You still need a working backup and a working failover plan, even if it's just setting up a new server and running your Terraform / Pulumi / Saltstack scripts.
PunchyHamster 6mo ago
their original also run on single server ? If you can tolerate few hours of downtime and some data rollback/loss, single server + robust backups can be viable strategy
chalmovsky 6mo ago
What are you running on it is the only question which matters, obviously you dont want air traffic control to go down but some app… So what if it goes down? Backup is somewhere else if you even need it anyway. Github has uptime less than 90% according to this: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ . And the world keeps turning. Obviously we should strive for better, but also lets please not continue making this uptime fetish out of it, for vast majority of the apps it absolutely doesnt fucking matter.
wiether 6mo ago
To be fair they were using a single VM on DigitalOcean, so they didn't had the perks of a cloud provider, except maybe the fact that a VM is probably more fault-tolerant than a bare metal server. Usually those articles describe two situations: - they were "on the cloud" for the wrong reasons and migrating to something more physical is the right approach - they were "on the cloud" for the right reasons and migrating to something more physical is going to be a disaster Here they appear to be in the first situation. If their setup was running fine on DO and they put the right DR policies in place at Hetzner, they should be fine.
chillfox 6mo ago
A lot of things don't need that. Also, don't underestimate the reliability of simplicity. I was a Linux sysadmin for many years, and I have never seen as much downtime from simpler systems as I routinely see from the more complicated setups. Somewhere between theory and reality, simpler systems just comes out ahead most of the time.
NicoJuicy 6mo ago
Depends on the app and how long downtime would take. Deploying a new docker instance or just restoring the app from a snapshot and restoring the latest db in most cases is enough.
BorisMelnik 6mo ago
I agree with you, even for the servers I am responsible for I always make decisions like putting db on supabase instead of local, hosting files on s3 with versioning/multi region etc. then of course come up with a backup and snapshot system.
ozim 6mo ago
If you can restore from snapshot to a new instance on cloud provider having running second copy is waste of money. I know people like FAANG LARPing. Not everyone has budget or need to run four nines with 24/7 and FAANG level traffic.
Gud 6mo ago
What time in maintenance? Hetzner has been rock solid for me.
jgalt212 6mo ago
Hetzner has cheap load balancers and VMs.
neya 6mo ago
I was thinking the same. A managed database is just set and forget pretty much. I do NOT miss the old times where I had to monitor my email from routine security checkups hoping my database didn't get hacked by some script kiddie accompanied by blackmail over email.
wg0 6mo ago
If you have the setup within server fully scripted and automated (bash, pyinfra or ansible etc) and backups are in place then recovery isn't that hard. Downtime for sure maybe couple of hours for which you can point your DNS entries to a static page while you're restoring everything. Not a bad tradeoff for 99.8% of shops out there.
jdboyd 6mo ago
DO doesn't do high availability droplets, and their migration policy is will try, if we detect poor health of server before it fails. If someone starts thinking about redundancy and load balancers than DO's solution is rent a second similar sized droplet, and then add their load balancing service. If you do those things with Hetzner instead, you would still be spending less than you did with Digital Ocean. Personally, what is keeping me on DO is that no single droplet I have is large enough to justify moving on its own, and I'm not prepared to deal with moving everything.
pinkgolem 6mo ago
Tbh, my one server paperless deployment has a higher uptime then most services. If your scaling need is not that high, you can get very far with a single server
littlecranky67 6mo ago
To be fair, modern dedicated servers at hetzner have two power units, and come with a redundand ssd/hdd raid-1 config. AFAIK both ssd and power unit having hotplug capability, so in case either fails they can be replaced with zero downtime. Given the downtimes we saw in the past year(s) (AWS, Cloudflare, Azure - the later even down several times), I would argue moving to any of the big cloud providers give you not much of a better guarantee. I myself am a Hetzner customer with a dedicated vServer, meaning it is a shared virtual server but with dedicated CPUs (read: still oversubscribed, but some performance guarantee) and had zero hardware-based downtime for years [0]. I would guess their vservers are on similar redundant hardware where the failing components can be hotswapped. [0] = They once within the last 3 years sent me an email that they had to update a router that would affect network connectivity for the vServer, but the notification came weeks in advance and lasted about 15 minutes. No reboot/hardware failure on my vServer though.
supermatt 6mo ago
They already were on "1 big server" (a single VPS at digital ocean) and moved to another "1 big server" (a managed server at hertzner). They saved money and lost nothing. Now, if they so wish, they could use a portion of that to increase redundancy - but that wasn't the point of the article.
surgical_fire 6mo ago
The vast majority of services are actually alright with a little downtime here and there. In exchange, maintenance is a lot simpler with less moving parts. People underestimate how far you can go with one or two servers. In fact, what I have seen in ky career is many examples of services that should have been running on one or two servers and instead went for a hugely complex microserviced approach, all in on Cloud providers and crazy requirements of reliability for a scale that never would come.
ahofmann 6mo ago
In 20 years of hosting all kinds of web services, some of them serving over 200m requests per month, a crashing single server was twice a problem. Dealing with over engineered bullshit, that behaved in strange ways that disrupted the service was far more often a problem. So, yes, redundancy is something that can be left away, if you're comfortable to be responsible for fixing things at a Saturday morning.
- jijijijij 6mo ago
  People also tend underestimate how much compute these dedicated servers got, compared to cloud offerings, and what that feels like without 100 layers of management abstraction in-between. You are likely not going to ever choke a plenty-cored, funny-RAMed root server at a fraction of your cloud costs. This overkill resource estate can be the answer to a lot of scalability worries. It's always there, no sharing shit all.
izacus 6mo ago
I had like... less than 10 minutes downtime on Hetzner in years (funny enough, that makes my personal containers more reliable than productionized AWS and GCP deployments with their constant partial outages). So perhaps all that complexity (beyond maybe a backup container) isn't really necessary for companies where a bit of downtime doesn't really affect revenue? Like, I know Leetcode tells otherwise, but most companies really don't need full FAANG stack with 99.999% uptime. A day of outage in a few years isn't going affect bottom lines.
- ozim 6mo ago
  Second that I wrote the same in my comment somewhere above. LARPing as a FAANG is waste of money and lots of companies doesn’t even need 3 nines let alone 5ve.
pier25 6mo ago
I don't know about Hetzner but with Upcloud and Vultr my single VPS setups have been more reliable than multiregion with redundancy setups with other providers like Fly.
- stephenhuey 6mo ago
  A few weeks ago, I tested deploying Rails apps to Hetzner and Vultr for the first time using Hatchbox to deploy Rails apps onto them. I'm still supporting clients on Heroku, but there are potential new projects in the coming months that I might deploy elsewhere. Render is decent in some cases, but you can get a lot of bang for your buck deploying on Vultr, and Hatchbox makes it easy to do, whether you have one instance or a cluster. Hatchbox also helps with putting multiple apps/domains on a single server, a concept I had to give up long ago on Heroku. I've thought about deploying to DO plenty of times over the years, but there was always Heroku, and if I had to find a new home for Rails 8, I think I'd skip it in favor of a more powerful Vultr server. Hatchbox can provision Postgres for you, but Vultr has managed Postgres which is appealing to me. Or if you're just using Sqlite with Rails 8, that's easy to do with Hatchbox but not on Render since Render has an ephemeral file system.
  - anurag 6mo ago
    Render lets you attach a disk to your app: https://render.com/docs/disks https://render.com/docs/disks
  - rrvsh 6mo ago
    Vultr is goated, I've been using them since ~2020 and have never had any issues. I stopped a year or so back and recently went through the whole onboarding process again and it was dead simple even 6 years later, with barely any price increase compared to other providers. Hetzner will always be the worst to me because plainly their UX sucks; I can't imagine if I was a non-technical user trying to use it
grebc 6mo ago
Downtime happens in all different contexts of life that a web site/service being knocked offline is soo far down the priority list for most people. It’s amusing that the US government can shutdown for days/weeks/months over budget reasons and there’s no adult discussions that take place about fixing the cause. Yet the latest HN demo that 100 people will use need all 9’s reliability and hundreds of responses.
stephenhuey 6mo ago
I already made a comment here about testing Hatchbox. You point it to your servers and it can set up a cluster and load balancer with a few button clicks.
squirrellous 6mo ago
I’d even argue that most things operated by tech doesn’t need 24x7x365 availability. If it’s about life-and-death, then yes make it super reliable and available. Otherwise, bring back scheduled downtime please.
ies7 6mo ago
> You saved a lot of money but you'll spend a lot of time in maintenance and future headaches. Look from my perspective, I'll got flying color from my owner because of the cost saving and got my team morale up that I really need them to maintain the system instead of lay them off. Also in some cases that also mean new jobs opening.
apatheticonion 6mo ago
I've been running a production workload for a cost sensitive customer on a small cheap Vultr VPS for 10 years. Updates have zero downtime and there's lots of compute headroom so it never locks up. No, there's no redundancy and it is only performant in a single region - but that's okay with the customer as it's just a custom CRM. Not every use case requires Kubernetes, multiple nodes, dedicated database infra and auto-scaling.
locknitpicker 6mo ago
> Every time I see this kind of article, no one really bothers about sb/server redundancy, load balancers, etc. are we ok with just 1 big server that may fail and bring several services down? It seems that to start off the original system was hosted on a single Digital Ocean droplet with 32vCPUs and a total 192GB of RAM. They switched to a single Hetzner AX162-R instance. So the blogger switched from a single odd with 32 vCPUs to a dedicated server running a AMD EPYC 9454P and 256GB of RAM. That should answer your question with a clear yes. > You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.
tayloremilija9 6mo ago
[dead]

by mariopt 6mo ago

timwis 6mo ago

I wondered the same! FWIW I'm currently migrating from managed postgres to self-managed on hetzner with [autobase](https://autobase.tech/ https://autobase.tech/). Though of course for high availability it requires more than one server.

matteocontrini 6mo ago
Beware of Hetzner Cloud volumes, they're unusable for a database, they're too slow. I'm not sure what workloads people run on Hetzner but the low-performance volumes and unreliable load balancers don't seem like a good fit for real production stuff with traffic.
- arter45 6mo ago
  How slow is “too slow”? Do you happen to have any benchmark?
  - matteocontrini 6mo ago
    I've run some benchmarks a couple years ago, I don't have them at hand unfortunately but off the top of my mind, seqread 4k produced around 1500 IOPS while seqwrite was like a third of that. The practical performance was abysmal, I moved PostgreSQL storage to a volume and it was very noticeably slower just by browsing the web app (compared to NVMe SSD storage). For comparison, I'm now using UpCloud which uses network-attached storage for all volumes and easily hits 10k IOPS (up to 100k with some tuning). I certainly may have missed something while testing this so I'm happy if someone else wants to contribute and correct me if I'm wrong.

grey-area 6mo ago

It depends on the service and how critical that website is. Sometimes it's completely acceptable that a server will run for 10 years with say 1 week or 1 month of downtime spread over those 10 years, yes. That's the sort of uptime you can see with single servers that are rarely changed and over-provisioned as many on Hetzner are. Some examples: Small businesses where the website is not core to operations and is more of a shop-front or brochure for their business. Hobby websites too don't really matter if they go down for short periods of time occasionally. Many forums and blogs just aren't very important too and downtime is no big deal. There are a lot of these websites, and they are at the lower end of the market for obvious reasons, but probably the majority of websites in fact, the long tail of low-traffic websites. Not everything has to be high availability and if you do want that, these providers usually provide load balancers etc too. I think people forget here sometimes that there is a huge range in hosting from squarespace to cheap shared hosting to more expensive self-hosted and provisioned clouds like AWS.

rzz3 6mo ago
What struck me though is that OP did so much work to migrare the server with zero downtime. The _single_ big server. Something’s off here.
- j45 6mo ago
  There is software that can help a lot. Also, in general, you can architect your application to be more friendly to migration. It used to be a normal thing to think about and plan for. VMware has a conversion tool that converts bare metal into images. One could image, then do regular snapshots, maybe centralize a database being accessed. Sometimes it's possible to create a migration script that you run over and over to the new environment for each additional step. Others can put a backup server in between to not put a load on the drive. Digital Ocean makes it impossible to download your disk image backups which is a grave sin they can never be forgiven for. They used to have some amount of it. Still, a few commands can back up the running server to an image, and stream it remotely to another server, which in turn can be updated to become bootable. This is the tip of the iceberg in the number of tasks that can be done. Someone with experience can even instruct LLMs to do it and build it, and someone skilled with LLMs could probably work to uncover the steps and strategies for their particular use case.

daneel_w 6mo ago

They may be making this decision based on a long history of, in fact, never really having run into "a lot of time in maintenance and future headaches".

VorpalWay 6mo ago
To be fair, I migrated a VPS from Linode to Hetzner a few years ago. Minor downtime is a non-issue: personal website and email server. I approximately halved the monthly cost, and I haven't had any downtime except what I caused myself when rebooting to upgrade the kernel every now and then. As a bonus, Hetzner is European.

Aurornis 6mo ago

These articles are popular where there's a mismatch between application requirements and the solution chosen. When someone over-engineers their architecture to be enterprise-grade (substitute your own definition of enterprise-grade) when really they were running a hobby project or a small business where a day of downtime every once in a while just means your customers will come back the next day, going all-out on cloud architecture is maybe not necessary. That's why you see so many comments from people arguing that downtime isn't always a big deal or that risking an outage is fine: There are a lot of applications where this is kind of true. The confusing part about this article is the emphasis on a zero-downtime migration toward a service that isn't really ideal for uptime. It wouldn't be that expensive to add a little bit of architecture on the Hetzner side to help with this. I guess if you're doing a migration and you're paid salary or your time is free-ish, doing the migration in a zero downtime way is smart. It's a little funny to see the emphasis on zero downtime juxtaposed to the architecture they chose where uptime depends on nothing ever failing

j45 6mo ago
Downtime is a strawman. Clever architecture will always beat cleverly trying to pick only one cloud. Being cloud agnostic is best. This means setting up a private cloud. Hosted servers, and managed servers are perfectly capable of near zero downtime. this is because it's the same equipment (or often more consumer grade) that the "cloud" works on and plans for even more failure. Digital Ocean definitely does not guarantee zero downtime. That's a lot of 9's. It's simple to run well established tools like Proxmox on bare metal that will do everything Digital Ocean promises, and it's not susceptible to attacks, or exploits where the shared memory and CPU usage will leak what customers believe is their private VPS. Nothing ever failing in the case of a tool like Proxmox is, install it on two servers, one VPS exists on both nodes (you connect both servers as nodes), click high availability, and it's generally up and running. Put cloudflare in front of it like the best preference practices of today. If you're curious about this, there's some pretty eye opening and short videos on Proxmox available on Youtube that are hard to unsee.
- nine_k 6mo ago
  Sadly, hardware breaks. You still need a working backup and a working failover plan, even if it's just setting up a new server and running your Terraform / Pulumi / Saltstack scripts.

PunchyHamster 6mo ago

their original also run on single server ? If you can tolerate few hours of downtime and some data rollback/loss, single server + robust backups can be viable strategy

chalmovsky 6mo ago

What are you running on it is the only question which matters, obviously you dont want air traffic control to go down but some app… So what if it goes down? Backup is somewhere else if you even need it anyway. Github has uptime less than 90% according to this: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ . And the world keeps turning. Obviously we should strive for better, but also lets please not continue making this uptime fetish out of it, for vast majority of the apps it absolutely doesnt fucking matter.

wiether 6mo ago

To be fair they were using a single VM on DigitalOcean, so they didn't had the perks of a cloud provider, except maybe the fact that a VM is probably more fault-tolerant than a bare metal server. Usually those articles describe two situations: - they were "on the cloud" for the wrong reasons and migrating to something more physical is the right approach - they were "on the cloud" for the right reasons and migrating to something more physical is going to be a disaster Here they appear to be in the first situation. If their setup was running fine on DO and they put the right DR policies in place at Hetzner, they should be fine.

chillfox 6mo ago

A lot of things don't need that. Also, don't underestimate the reliability of simplicity. I was a Linux sysadmin for many years, and I have never seen as much downtime from simpler systems as I routinely see from the more complicated setups. Somewhere between theory and reality, simpler systems just comes out ahead most of the time.

NicoJuicy 6mo ago

Depends on the app and how long downtime would take. Deploying a new docker instance or just restoring the app from a snapshot and restoring the latest db in most cases is enough.

BorisMelnik 6mo ago

I agree with you, even for the servers I am responsible for I always make decisions like putting db on supabase instead of local, hosting files on s3 with versioning/multi region etc. then of course come up with a backup and snapshot system.

ozim 6mo ago

If you can restore from snapshot to a new instance on cloud provider having running second copy is waste of money. I know people like FAANG LARPing. Not everyone has budget or need to run four nines with 24/7 and FAANG level traffic.

Gud 6mo ago

What time in maintenance? Hetzner has been rock solid for me.

jgalt212 6mo ago

Hetzner has cheap load balancers and VMs.

neya 6mo ago

I was thinking the same. A managed database is just set and forget pretty much. I do NOT miss the old times where I had to monitor my email from routine security checkups hoping my database didn't get hacked by some script kiddie accompanied by blackmail over email.

wg0 6mo ago

If you have the setup within server fully scripted and automated (bash, pyinfra or ansible etc) and backups are in place then recovery isn't that hard. Downtime for sure maybe couple of hours for which you can point your DNS entries to a static page while you're restoring everything. Not a bad tradeoff for 99.8% of shops out there.

jdboyd 6mo ago

DO doesn't do high availability droplets, and their migration policy is will try, if we detect poor health of server before it fails. If someone starts thinking about redundancy and load balancers than DO's solution is rent a second similar sized droplet, and then add their load balancing service. If you do those things with Hetzner instead, you would still be spending less than you did with Digital Ocean. Personally, what is keeping me on DO is that no single droplet I have is large enough to justify moving on its own, and I'm not prepared to deal with moving everything.

pinkgolem 6mo ago

Tbh, my one server paperless deployment has a higher uptime then most services. If your scaling need is not that high, you can get very far with a single server

littlecranky67 6mo ago

To be fair, modern dedicated servers at hetzner have two power units, and come with a redundand ssd/hdd raid-1 config. AFAIK both ssd and power unit having hotplug capability, so in case either fails they can be replaced with zero downtime. Given the downtimes we saw in the past year(s) (AWS, Cloudflare, Azure - the later even down several times), I would argue moving to any of the big cloud providers give you not much of a better guarantee. I myself am a Hetzner customer with a dedicated vServer, meaning it is a shared virtual server but with dedicated CPUs (read: still oversubscribed, but some performance guarantee) and had zero hardware-based downtime for years [0]. I would guess their vservers are on similar redundant hardware where the failing components can be hotswapped. [0] = They once within the last 3 years sent me an email that they had to update a router that would affect network connectivity for the vServer, but the notification came weeks in advance and lasted about 15 minutes. No reboot/hardware failure on my vServer though.

supermatt 6mo ago

They already were on "1 big server" (a single VPS at digital ocean) and moved to another "1 big server" (a managed server at hertzner). They saved money and lost nothing. Now, if they so wish, they could use a portion of that to increase redundancy - but that wasn't the point of the article.

surgical_fire 6mo ago

The vast majority of services are actually alright with a little downtime here and there. In exchange, maintenance is a lot simpler with less moving parts. People underestimate how far you can go with one or two servers. In fact, what I have seen in ky career is many examples of services that should have been running on one or two servers and instead went for a hugely complex microserviced approach, all in on Cloud providers and crazy requirements of reliability for a scale that never would come.

ahofmann 6mo ago

In 20 years of hosting all kinds of web services, some of them serving over 200m requests per month, a crashing single server was twice a problem. Dealing with over engineered bullshit, that behaved in strange ways that disrupted the service was far more often a problem. So, yes, redundancy is something that can be left away, if you're comfortable to be responsible for fixing things at a Saturday morning.

jijijijij 6mo ago
People also tend underestimate how much compute these dedicated servers got, compared to cloud offerings, and what that feels like without 100 layers of management abstraction in-between. You are likely not going to ever choke a plenty-cored, funny-RAMed root server at a fraction of your cloud costs. This overkill resource estate can be the answer to a lot of scalability worries. It's always there, no sharing shit all.

izacus 6mo ago

I had like... less than 10 minutes downtime on Hetzner in years (funny enough, that makes my personal containers more reliable than productionized AWS and GCP deployments with their constant partial outages). So perhaps all that complexity (beyond maybe a backup container) isn't really necessary for companies where a bit of downtime doesn't really affect revenue? Like, I know Leetcode tells otherwise, but most companies really don't need full FAANG stack with 99.999% uptime. A day of outage in a few years isn't going affect bottom lines.

ozim 6mo ago
Second that I wrote the same in my comment somewhere above. LARPing as a FAANG is waste of money and lots of companies doesn’t even need 3 nines let alone 5ve.

pier25 6mo ago

I don't know about Hetzner but with Upcloud and Vultr my single VPS setups have been more reliable than multiregion with redundancy setups with other providers like Fly.

stephenhuey 6mo ago
A few weeks ago, I tested deploying Rails apps to Hetzner and Vultr for the first time using Hatchbox to deploy Rails apps onto them. I'm still supporting clients on Heroku, but there are potential new projects in the coming months that I might deploy elsewhere. Render is decent in some cases, but you can get a lot of bang for your buck deploying on Vultr, and Hatchbox makes it easy to do, whether you have one instance or a cluster. Hatchbox also helps with putting multiple apps/domains on a single server, a concept I had to give up long ago on Heroku. I've thought about deploying to DO plenty of times over the years, but there was always Heroku, and if I had to find a new home for Rails 8, I think I'd skip it in favor of a more powerful Vultr server. Hatchbox can provision Postgres for you, but Vultr has managed Postgres which is appealing to me. Or if you're just using Sqlite with Rails 8, that's easy to do with Hatchbox but not on Render since Render has an ephemeral file system.
- anurag 6mo ago
  Render lets you attach a disk to your app: https://render.com/docs/disks https://render.com/docs/disks
- rrvsh 6mo ago
  Vultr is goated, I've been using them since ~2020 and have never had any issues. I stopped a year or so back and recently went through the whole onboarding process again and it was dead simple even 6 years later, with barely any price increase compared to other providers. Hetzner will always be the worst to me because plainly their UX sucks; I can't imagine if I was a non-technical user trying to use it

grebc 6mo ago

Downtime happens in all different contexts of life that a web site/service being knocked offline is soo far down the priority list for most people. It’s amusing that the US government can shutdown for days/weeks/months over budget reasons and there’s no adult discussions that take place about fixing the cause. Yet the latest HN demo that 100 people will use need all 9’s reliability and hundreds of responses.

stephenhuey 6mo ago

I already made a comment here about testing Hatchbox. You point it to your servers and it can set up a cluster and load balancer with a few button clicks.

squirrellous 6mo ago

I’d even argue that most things operated by tech doesn’t need 24x7x365 availability. If it’s about life-and-death, then yes make it super reliable and available. Otherwise, bring back scheduled downtime please.

ies7 6mo ago

> You saved a lot of money but you'll spend a lot of time in maintenance and future headaches. Look from my perspective, I'll got flying color from my owner because of the cost saving and got my team morale up that I really need them to maintain the system instead of lay them off. Also in some cases that also mean new jobs opening.

apatheticonion 6mo ago

I've been running a production workload for a cost sensitive customer on a small cheap Vultr VPS for 10 years. Updates have zero downtime and there's lots of compute headroom so it never locks up. No, there's no redundancy and it is only performant in a single region - but that's okay with the customer as it's just a custom CRM. Not every use case requires Kubernetes, multiple nodes, dedicated database infra and auto-scaling.

locknitpicker 6mo ago

> Every time I see this kind of article, no one really bothers about sb/server redundancy, load balancers, etc. are we ok with just 1 big server that may fail and bring several services down? It seems that to start off the original system was hosted on a single Digital Ocean droplet with 32vCPUs and a total 192GB of RAM. They switched to a single Hetzner AX162-R instance. So the blogger switched from a single odd with 32 vCPUs to a dedicated server running a AMD EPYC 9454P and 256GB of RAM. That should answer your question with a clear yes. > You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.

tayloremilija9 6mo ago

[dead]