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

141–150 of 643 posts

Re: Migrating from AWS to Hetzner

#141

Post by vidarh »

OutOfHere wrote: post #124
vidarh wrote: post #117

Earlier quoted context omitted.

They're cheap, so I'd expect they get a substantially higher proportion of users who might think their account termination is unfair, but that were actually flouting the rules, so I wouldn't be surprised if there were a higher proportion of claims of unfair account termination... I've recommended Hetzner to people since 2008-2009, and know lots of people who use it, and I've never heard first-hand accounts of termina…

If you haven't read first-hand reports, then you haven't read all that much. If you search on Reddit, you may see many reports. It happened to me personally after I started using their CPU at nearly 100% for about two months. That's a report for you. They're cheap because they don't actually want people using what they're paying for. This is a theme that I have seen with German services. Speaking of their rules, thos…

I've maxed out lots of CPUs at Hetzner over many years, and across multiple companies, and had clients do the same, so I find your claim to be dubious unless you're talking about shared CPU cloud instances in which case I wouldn't be surprised but also wouldn't consider it unfair.

So let me revise that to say I haven't seen any reports I can 1) verify are first hand, and 2) know accurately reflect an actual unfair termination. That is also why I don't bother going around reading accounts on Reddit.

Re: Migrating from AWS to Hetzner

#142

Post by bdcravens »

baobun wrote: post #134
pwmtr wrote: post #47

We’ve been seeing the same trend. Lots of teams moving to Hetzner for the price/performance, but then realizing they have to rebuild all the Postgres ops pieces (backups, failover, monitoring, etc.). We ended up building a managed Postgres that runs directly on Hetzner. Same setup, but with HA, backups, and PITR handled for you. It’s open-source, runs close to the metal, and avoids the egress/I/O gotchas you get on A…

In the adjacent category of self-managed omakase postgres: https://www.elephant-shed.io/

While I'm sure it's a great project, a few issues in the README gave me pause to think about how well it's kept up to date. Around half of the links in the list of dependencies are either out of date or just plain don't work, and referencing Vagrant with no mention of Docker.

Re: Migrating from AWS to Hetzner

#143

Post by ctm92 »

slig wrote: post #137

Anyone here using https://github.com/vitobotta/hetzner-k3s Or https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne... For a K3S cluster? Would love to hear any experience. Thanks!

We are using hetzner-k3s, super solid and easy to use. I love that it also utilizes the Hetzner Cloud Controllers to utilize the native Hetzner load balancers, volumes, network

Re: Migrating from AWS to Hetzner

#144

Post by ozim »

normie3000 wrote: post #92
pwmtr wrote: post #47

We’ve been seeing the same trend. Lots of teams moving to Hetzner for the price/performance, but then realizing they have to rebuild all the Postgres ops pieces (backups, failover, monitoring, etc.). We ended up building a managed Postgres that runs directly on Hetzner. Same setup, but with HA, backups, and PITR handled for you. It’s open-source, runs close to the metal, and avoids the egress/I/O gotchas you get on A…

This is one key draw to Big Cloud and especially PaaS and managed SQL for me (and dev teams I advise). Not having an ops background I am nervous about: * database backup+restore * applying security patches on time (at OS and runtime levels) * other security issues like making sure access to prod machines is restricted correctly, access is logged, ports are locked down, abnormal access patterns are detected * DoS and…

Applying security patches on time is not much problem. Ones that you need to apply ASAP are rare and for DB engine you never put it on public access, most of the time exploit is not disclosed publicly and PoC code is not available for patched RCE right on day of patch release.

Most of the time you are good if you follow version updates for major releases as they come you do regression testing and put it on prod in your planned time.

Most problems come from not updating at all and having 2 or 3 year old versions because that’s what automated scanners will be looking for and after that much time someone much more likely wrote exploit code and shared it.

Re: Migrating from AWS to Hetzner

#146

Post by YetAnotherNick »

You are doing calculations all wrong if you think saving $500/month is 75% of your cost.

Also first three lines of new stack is a sure shot way to get PTSD. You shouldn't manage database in your plane, unless you really know the internals of the tools you are using. Once you get off AWS then you really start to see the value of things like documentation.

Re: Migrating from AWS to Hetzner

#147

Post by baobun »

cyberpunk wrote: post #110
tmdetect wrote: post #97

+1 to running services on physical servers, OVH in my case. I'm really enjoying CI pushing to servers and having managed database provided by a 3rd party like Mongo Atlas.

Isn’t there quite a significant latency problem if you’re going across the internet for db instead of say, the same switch?

No experience with Mongo Atlas but other managed DB providers will IME be transparent about where they host and you can often request resources in an appropriate DC, sometimes even the same. Businesses providing this in Hetzner, OVH etc too. If you plan accordingly you can eat your cake and have it too.

Re: Migrating from AWS to Hetzner

#148

Post by matdehaast »

sergioisidoro wrote: post #86

I really liked Hetzner but I got burned by one issue. I had some personal projects running there and the payment method failed. Automated email communications also failed among so much spam and email notifications I receive, and when I noticed the problem they had wiped all my data without possibility of recovery. It was a wake up moment for me about keeping billing in shape, but also made me understand that a cloud…

I've had billing issues, and they have let it be resolved a couple of weeks later.

Re: Migrating from AWS to Hetzner

#149

Post by rs_rs_rs_rs_rs »

endymion-light wrote: post #36
rs_rs_rs_rs_rs wrote: post #10

You got me with the title and I was curious at first but then I got to the part where it shows the bill and realized this is just toy project.

It's really dismissive and frankly quite ignorant to have an attitude that just because a product doesn't have a massive AWS bill it's a toy project. It's a rotten attitude, and judging a projects worth by an AWS bill is a very poor comparator. I could spin up a massive aws bill doing some pointless machine learning workloads, is that suddenly a valid project in your eyes?

>I could spin up a massive aws bill doing some pointless machine learning workloads, is that suddenly a valid project in your eyes?

Can you spin it on a AWS competitor for a fraction of a cost? Absolutely yes I would be interested in reading about it!

Re: Migrating from AWS to Hetzner

#150

Post by adamcharnock »

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 hardware, and so actually allowing a modern CPU to do its job, makes a huge difference

- Disk IO – Dedicated NVMe access is _fast_.

And with it comes a whole bunch of other benefits:

- Auto-scalers becomes less important, partly because you have 10x the hardware for the same price, partly because everything runs 2x the speed anyway, and partly because you have a fixed pool of hardware. This makes the whole system more stable and easier to reason about.

- No more sweating the S3 costs. Put a 15TB NVMe drive in each server and run your own MinIO/Garage cluster (alongside your other workloads). We're doing about 20GiB/s sustained on a 10 node cluster, 50k API calls per second (on S3 that is $20-$250 _per second_ on API calls!).

- You get the same bill every month.

- UPDATE: more benefits - cheap fast storage, run huge Postgresql instances at minimal cost, less engineering time spend working around hardware limitations and cloud vagaries.

And, if chose to invest in the above, it all costs 10x less than AWS.

Pitch: If you don't want to do this yourself, then we'll do it for you for half the price of AWS (and we'll be your DevOps team too):

https://lithus.eu

Email: adam@ above domain

Post reply on HN