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

161–170 of 214 posts

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

#161

Post by tekno45 »

hsbauauvhabzb wrote: post #152
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 )…

> For example, during the AWS outage, my company was in us-east-1, and we never had any issues, because we didn't depend on calling AWS APIs to continue operating. Things already running continue to run. Naïve. If the network infrastructure is down, your computer goes down, it just happens that the functionality that went down you didn’t rely on. You could not rely on any functions at all by turning the server off, t…

yeah loadbalancers definitely removed instances during that outage. Watched it happen.

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

#162

Post by hdgvhicv »

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.

Hence you can use AWS to host them.

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

#163

Post by toast0 »

precommunicator wrote: post #155
toast0 wrote: post #73

Earlier quoted context omitted.

> Intelligent, robust design at one provider (like AWS) is way more resilient, and intra-zone transfer is cheaper than going out to the cloud ($0.02/GB vs $0.08/GB). If traffic cost is relevant (which it is for a lot of use cases), Hetzner's price of $1.20/TB ($0.0012 / GB) for internet traffic [1] is an order of magnitude less than what AWS charges between AWS locations in the same metro. If you host only at provide…

keep in mind, for dedicated servers, traffic is free and unlimited - see the page you've linked

Not if you're running at 10G...

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

#164

Post by hdgvhicv »

lxe wrote: post #110
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 think you underestimate how reduction in complexity can increase reliability. becoming a sysadmin for a single inexpensive server instance carries almost the same operational burden as operating an unavoidably very complicated cluster using a cloud provider.

Nowhere near the same. Admining a few servers is far easier than a mix of AWS cloud services, especially when they are either metal as a service or plain VMs.

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

#165

Post by antod »

travisgriggs wrote: post #104
chubot wrote: post #87

Earlier quoted context omitted.

It's not an apples-to-apples comparison, because EC2 and Google Cloud have ephemeral disk - persistent disk is an add-on, which is implemented with a complex and frequently changing distributed storage system On the other hand, a Hetzner machine I just rented came with Linux software RAID enabled (md devices in the kernel) --- I'm not aware of any comparisons, but I'd like to see see some It's not straightforward, an…

> by virtue of being more complex I just wish there was a way to underscore this more and more. Complex systems fail in complex ways. Sadly, for many programmers, the thrill or ego boost that comes with solving/managing complex problems lets us believe complex is better than simple.

One side effect of devops over the last 10-15yrs I've noticed as dev and ops converged is that infrastructure complexity exploded as the old school pessimistic sysadmin culture of simplicity and stability gave way to a much more optimistic dev culture. Also better tooling also enabled increased complexity in a self fulfilling feedback loop as more complexity also demanded better tooling.

It's kept me employed though...

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

#166

Post by jabwd »

izacus wrote: post #52
kachapopopow wrote: post #6

Always consider if 12 hours of lost revenue is worth the savings. Recently hetzner has been flakey with minimum or no response for support or even status updates that anything was wrong. My favorite was them blaming an issue on my side just to have a maintenance status update the day after about congestion.

My Hetzner instances all have higher reliability and uptime than AWS deployments. For years now. That was an interesting surprise.

Curious what kind of deployments you are running with them? I only have personal stuff with Hetzner; but never had issues so far (bare metal in my case coz cheap for what I get and need).

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

#167

Post by walletdrainer »

hsbauauvhabzb wrote: post #149
whatever1 wrote: post #135

Earlier quoted context omitted.

AWS and Azure were down for a full day in the past month. No way I cannot spin up my infra in a full day even if the current datacenter burns to the ground. So we have the same reliability.

Not if you don’t have hot replicated user data etc, assuming that matters, which it will unless you outsource auth and if you do that you’re back at square 1

Just have backups, you could literally sync everything to rsync.net unless you have a ridiculous amount of users

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

#168

Post by 0xbadcafebee »

mnutt wrote: post #68
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 )…

> we never had any issues, because we didn't depend on calling AWS APIs to continue operating. Things already running continue to run. I think it was just luck of the draw that the failure happened in this way and not some other way. Even if APIs falling over but EC2 instances remaining up is a slightly more likely failure mode, it means you can't run autoscaling, can't depend on spot instances which in an outage you…

> it means you can't run autoscaling, can't depend on spot instances which in an outage you can lose and can't replace

Yes, this is part of designing for reliability. If you use spot or autoscaling, you can't assume you will have high availability in those components. They're optimizations, like a cache. A cache can disappear, and this can have a destabilizing effect on your architecture if you don't plan for it.

This lack of planning is pretty common, unfortunately. Whether it's in a software component or system architecture, people often use a thing without understanding the implications of it. Then when AWS API calls become unavailable, half the internet falls over... because nobody planned for "what happens when the control plane disappears". (This is actually a critical safety consideration in other systems)

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

#169

Post by bastawhiz »

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.

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 recover from failure isn't a premature optimization. "The site is down and customers are angry" is an inevitability. If you can't handle failure modes in a timely manner, you aren't handling failure modes. That's not an optimization, that's table stakes.

It's not about five nines, it's about four nines or even three nines.

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

#170

Post by [deleted] »

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 )…

[deleted]
Post reply on HN