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

We cut our Mongo DB costs by 90% by moving to Hetzner

prosopo.io

Post reply on HN
Print view View original

191–200 of 214 posts

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#191

Post by [deleted] »

PenguinCoder wrote: post #92
dspillett wrote: post #81

Earlier quoted context omitted.

> You're using a single server in a single datacenter. This is a common problem with “bare metal saved us $000/mo” articles. Bare metal is cheaper than cloud by any measure, but the comparisons given tend to be misleadingly exaggerated as they don't compare like-for-like in terms of redundancy and support, and after considering those factors it can be a much closer result (sometimes down as far as familiarity and per…

Premature optimization. Not every single service needs or require 5 nines.

[deleted]

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#192

Post by Aeolun »

dspillett wrote: post #81
0xbadcafebee wrote: post #17

> Here's how we managed to cut our costs by 90% You could cut your MongoDB costs by 100% by not using it ;) > without sacrificing performance or reliability. You're using a single server in a single datacenter. MongoDB Atlas is deployed to VMs on 2-3 AZs. You don't have close to the same reliability. (I'm also curious why their M40 instance costs $1000, when the Pricing Calculator ( https://www.mongodb.com/pricing )…

> You're using a single server in a single datacenter. This is a common problem with “bare metal saved us $000/mo” articles. Bare metal is cheaper than cloud by any measure, but the comparisons given tend to be misleadingly exaggerated as they don't compare like-for-like in terms of redundancy and support, and after considering those factors it can be a much closer result (sometimes down as far as familiarity and per…

I think the problem is that the multi-az redundancy in AWS setups has saved me exactly zero times. The problem is nearly always some application issue.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#193

Post by walletdrainer »

ritcgab wrote: post #179

Looking at the root server hardware page on Hetzner [1], it is not clear if their server is using ECC memory. It would be pretty bad if not. [1] https://docs.hetzner.com/robot/dedicated-server/general-info...

https://www.hetzner.com/dedicated-rootserver/ax42/

Go to the product pages

(Yes all the normal Hetzner servers use ECC)

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#194

Post by wongarsu »

runako wrote: post #178
wongarsu wrote: post #156

Earlier quoted context omitted.

Hardware failures on server hardware at the scale of 1 machine are far less common than us-east-1 downtime The typical failure mode of AWS is much better. Half the internet is down, so you just point at that and wait for everything to come back, and your instances just keep running. If you have one server you have to do the troubleshooting and recovery work. But you need to run more than one machine to get fewer nine…

> Hardware failures on server hardware at the scale of 1 machine are far less common than us-east-1 downtime A couple pieces of gentle pushback here: - if you chose a hyperscaler, you should use their (often one-click) geographic redundancy & failover. - All of the hyperscalers have more than one AZ. Specifically, there's no reason for any AWS customer to locate all/any* of their resources in us-east-1. (I actively r…

Hetzner also offers more than one datacenter, which you should obviously use if you want geographic redundancy. But the comment I was replying was saying "Even dropping something on a single EC2 node in us-east-1", and for a single EC2 node in us-east-1 none of the things you are mentioning are possible without violating the premise

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#195

Post by nuschk »

zkmon wrote: post #48

Atlas is plain robbery. I see companies paying 600K USD/month on a few clusters, mostly used for testing. The problem is they got locked into this, by doing a huge migration of their apps and switching to a different tech would easily take 2 to 5 years.

Would a company paying 600k per month not also be able to employ a couple of devs to improve the situation? Sure, effort is required, but with the right people they could save a ton and have a very good ROI.

I think it's just more complicated than that. No hostage situation, just good old incentives.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#196

Post by dspillett »

PenguinCoder wrote: post #92
dspillett wrote: post #81

Earlier quoted context omitted.

> You're using a single server in a single datacenter. This is a common problem with “bare metal saved us $000/mo” articles. Bare metal is cheaper than cloud by any measure, but the comparisons given tend to be misleadingly exaggerated as they don't compare like-for-like in terms of redundancy and support, and after considering those factors it can be a much closer result (sometimes down as far as familiarity and per…

Premature optimization. Not every single service needs or require 5 nines.

This is true. Also some things are just fine, in fact sometimes better (better performing at the scale they actually need and easier to maintain, deploy, and monitor), as a single monolith instead of a pile of microservices. But when comparing bare metal to cloud it would be nice for people to acknowledge what their solution doesn't give, even if the acknowledgement comes with the caveat “but we don't care about that anyway because ”.

And it isn't just about 9s of uptime, it is all the admin that goes with DR if something more terrible then a network outage does happen, and other infrastructure conveniences. For instance: I sometimes balk at the performance we get out of AzureSQL given what we pay for it, and in my own time you are safe to bet I'll use something else on bare metal, but while DayJob are paying the hosting costs I love the platform dealing with managing backup regimes, that I can do copies or PiT restores for issue reproduction and such at the click of the button (plus a bit of a wait), that I can spin up a fresh DB & populate it without worrying overly about space issues, etc.

I'm a big fan of managing your own bare metal. I just find a lot of other fans of bare metal to be more than a bit disingenuous when extolling its virtues, including cost-effectiveness.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#197

Post by raxxorraxor »

0xbadcafebee wrote: post #17

> Here's how we managed to cut our costs by 90% You could cut your MongoDB costs by 100% by not using it ;) > without sacrificing performance or reliability. You're using a single server in a single datacenter. MongoDB Atlas is deployed to VMs on 2-3 AZs. You don't have close to the same reliability. (I'm also curious why their M40 instance costs $1000, when the Pricing Calculator ( https://www.mongodb.com/pricing )…

I don't buy it. It really depends on your service, but I don't believe the reliability story. All large providers have had outages and I do host services on a single server that didn't have an outage in a few years.

Depends on the service and its complexity. More complexity means more outages. In most instances a focus on easy recoverability is more productive than preemptive "reliability". As I have said, depends on your service.

And prices get premium very fast if you have either a lot of traffic or low traffic but larger file interchange. And you have more work to do if you use the cloud, because it uses non-standard interfaces. Today a well maintained server is a few clicks away. Even for managed servers you have maintenance and configuration. Plus, your provider probably changes the service quite often. I had to accommodate beanstalk while my application was just running on its own, free of maintenance needs.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#198

Post by raxxorraxor »

mads_quist wrote: post #57

OK guys, running on a single instance is REALLY a BAD IDEA for non-pet-projects. Really bad! Change it as fast as you can. I love Hetzner for what they offer but you will run into huge outages pretty soon. At least you need two different network zones on Hetzner and three servers. It's not hard to setup, but you need to do it.

Tell me about a service that needs this reliability please. I cannot think of anything aside perhaps some financial transaction systems, which all have some fallback message queue.

Also, all large providers had outages of this kind as well. Hell, some of them are partially so slow that you could call it an outages as well.

Easy config misstep and your load balancer goes haywire because you introduced unnecessary complexity.

I did that because I needed a static outgoing IP on AWS. Not fun at all.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#199

Post by raxxorraxor »

dvfjsdhgfv wrote: post #141

As much as I love Hetzner, the article is misleading. Using a single server today makes no sense whatsoever unless it's for hobby projects. It will fail. My servers at Hetzner routinely fail every few years (4-5 maybe), usually it's a hard drive, but sometimes motherboard or PSU. If it's a drive, you need to take it offline to rebuild the array, it can take a few hours. Like honestly, this article blew up my mind. I'…

I can deal with an outage every 4-5 years. I doubt you will get around that in a managed server environment, because you will fail configuration at some point when the service will inevitably change in the same timeframe.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#200

Post by ffsm8 »

bastawhiz wrote: post #169
PenguinCoder wrote: post #92

Earlier quoted context omitted.

Premature optimization. Not every single service needs or require 5 nines.

What does that mean, though? If I'm storing data on a NAS, and I keep backups on a tape, a simple hardware failure that causes zero downtime on S3 might take what, hours to recover? Days? If my database server dies and I need to boot a new one, how long will that take? If I'm on RDS, maybe five minutes. If it's bare metal and I need to install software and load my data into it, perhaps an hour or more. Being able to…

You're confusing backup with high availability.

Backups are point in time snapshots of data, often created daily and sometimes stored on tape.

It's primary usecase is giving admins the ability to e.g restore partial data via export and similar. It can theoretically also be used to restore after you had a full data loss, but that's beyond rare. Almost no company has had that issue.

This is generally not what's used in high availability contexts. Usually, companies have at least one replica DB which is in read only and only needs to be "activated" in case of crashes or other disasters.

With that setup you're already able to hit 5 nines, especially in the context of b2e companies that usually deduct scheduled downtimes via SLA

Post reply on HN