Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from AWS to Hetzner

digitalsociety.coop

Post reply on HN
Print view View original

501–510 of 643 posts

Re: Migrating from AWS to Hetzner

#501

Post by bearjaws »

bcrosby95 wrote: post #472
bearjaws wrote: post #367

Earlier quoted context omitted.

I feel like this is left out of the story too often - people tend to compare the most optimistic "self-hosted", usually just one or two servers at best, to a less than ideal cloud installation. My parent company (Healthcare) uses all on prem solutions, has 3 data centers and 10 sys admins just for the data centers. You still need DevOps too. I don't know how much it would cost to migrate their infra to AWS, but ~ $1.…

If your parent company sysadmins invest heavily into automation each sysadmin could be managing thousands of servers. Also, 6000 CPU "cores" on the cloud is more like 3000 CPU cores. Which you can get in just 20-50 servers. This is in the range of something that could be taken care of as a part time job.

Of course you could also invest heavily into cloud automation and likely run their payloads autoscaling and save a fortune too.

My point is, when people compare cloud to on prem they use a hypothetical on-prem installation vs a realistic actually working cloud deployment.

We only see these blog posts for things that are just 1-2 servers.

Very few companies are fully on-prem and saving a lot of money, they typically have very specific use cases like high bandwidth or IO usage.

Re: Migrating from AWS to Hetzner

#504

Post by spatley »

kitd wrote: post #253
radu_floricica wrote: post #215

Earlier quoted context omitted.

> What is old is new again. Over the years I tried occasionally to look into cloud, but it never made sense. A lot of complexity and significantly higher cost, for very low performance and a promise of "scalability". You virtually never need scalability so fast that you don't have time to add another server - and at baremetal costs, you're usually about a year ahead of the curve anyways.

People are usually the biggest cost in any organisation. If you can run all your systems without the sysadmins & netadmins required to keep it all upright (especially at expensive times like weekends or run up to Black Friday/Xmas), you can save yourself a lot more than the extra it'll cost to get a cloud provider to do it all for you.

Exactly, for the narrowly defined condition of running k8s on digital ocean with a managed control plane compared to Hetzner bare metal:

AWS and DigitalOcean = $559.36 monthly or Hetzner = $132.96 The cost of an engineer to set up and maintain a bare metal k8s cluster is going to far exceed the roughly $400 monthly savings.

If you run things yourself and can invest sweat equity, this makes some sense. But for any company with a payroll this does not math out.

Re: Migrating from AWS to Hetzner

#505

Post by grim_io »

fwip wrote: post #403
grim_io wrote: post #347

Earlier quoted context omitted.

Cloud providers and even cloudflare go down regularly. Relax.

Sure - but when AWS goes down, Amazon fixes it, even on the weekends. If you self-host, you need to pay a person to be on call to fix it.

Not every business needs that kind of uptime.

How often is GitHub down? We are all just fine without it for a while.

Re: Migrating from AWS to Hetzner

#506

Post by e12e »

baobun wrote: post #138
e12e wrote: post #85

Very interesting and detailed article! I'd love to hear more about how you use terraform and helm together. Currently our major friction in ops is using tofu (terraform) to manage K8s resources. Avoiding yaml is great - but both terraform and K8s maintaining state makes the deployment of helm from terraform feel fragile; and vice-versa depending on helm directly in a mostly terraform setup also feels fragile.

Not OP but I've lived through this too and my conclusion from that is that if you're doing tofu/terraform you're better off not introducing helm at all. Just tf the k8s.

Yes, this is what we do for example for the tailscale operator - but it's tedious to convert yaml to tf - and more importantly: error prone to correctly adapt upstream changes to update deployments as upstream refine their helm/k8s yaml files.

Re: Migrating from AWS to Hetzner

#507

Post by g8oz »

codethief wrote: post #87
lisperforlife wrote: post #11

I think you can get much farther with dedicated servers. I run a couple of nodes on Hetzner. The performance you get from a dedicated machine even if it is a 3 year old machine that you can get on server auction is absolutely bonkers and cannot be compared to VMs. The thing is that most of the server hardware is focused towards high core count, low clock speed processors that optimize for I/O rather than compute. It…

> I would love to know if they are any north-american (particularly canadian) companies that can compete with price and the quality of service like Hetzner FWIW, Hetzner has two data centers in the US, in case you're just looking for "Hetzner quality but in the US", not for "American/Canadian companies similar to Hetzner".

Similarly OVH is French and has bare metal in their US and Canadian data centers.

Re: Migrating from AWS to Hetzner

#508

Post by dematz »

torginus wrote: post #338
adamcharnock wrote: post #150

I cannot overstate the performance improvement of deploying onto bare metal. We typically see a doubling of performance, as well as extremely predictable baseline performance. This is down to several things: - Latency - having your own local network, rather than sharing some larger datacenter network fabric, gives around of order of magnitude reduced latency - Caches – right-sizing a deployment for the underlying har…

Yup, I hope to god we are moving past the age of 'everything's fast if you have enough machines' and 'money is not real' era of software development. I remember the point in my career when I moved from a cranky old .NET company, where we handled millions of users from a single cabinent's worth of beefy servers, to a cloud based shop where we used every cloud buzzword tech under the sun (but mainly everything was cont…

Tangential point but why is it that so often these leaving the cloud posts use the word "beefy" to describe the servers? It's always you don't need cloud because beefy servers handle pretty much any bla bla bla

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

If anyone from oxide computer or similar is reading, maybe you should rebrand to BEEFY server inc...

Re: Migrating from AWS to Hetzner

#509

Post by dijit »

lazide wrote: post #496
dinvlad wrote: post #481

Earlier quoted context omitted.

And now, on cloud it’s the same but much more expensive and worse performance. We’ve been struggling for over a month to get a single (1) non-beefy non-GPU VM allocated on Azure, since they’ve been having insane capacity issues, to the extent that even “provisioned” capacity cannot be fulfilled ;-(

Sure, but that’s because Azure. I’m sorry someone made the decision to go there. AWS & GCP, stock outs at least used to be nearly unheard of.

Until you hit a certain scale.

I totally agree about Azure being the worst of the three, they wanted us to commit to certain use before even buying hardware themselves. Crazy…

But I also had capacity issues with Google at large scales in many zones.

Re: Migrating from AWS to Hetzner

#510

Post by grim_io »

mjr00 wrote: post #428
wredcoll wrote: post #400

Earlier quoted context omitted.

If "cloud" took zero time, then sure. It actually takes a lot of time.

"It's actually really easy to set up Postgres with high availability and multi-region backups and pump logs to a central log source (which is also self-hosted)" is more or less equivalent to "it's actually really easy to set up Linux and use it as a desktop" In fact I'd wager a lot more people have used Linux than set up a proper redundant SQL database

Honestly, I don't see a big difference between learning the arcane non-standard, non-portable incantations needed to configure and use various forks of standard utilities running on the $CLOUD_PROVIDER, and learning to configure and run the actual service that is portable and completely standard.

Okay, I lied. The later seems much more useful and sane.

Post reply on HN