News for hackers. Stuff that matters.
Re:We use our own hardware at Fastmail by glitchc on Sunday December 22, 2024 @09:57AM (#42486693)
Cloud solves one problem quite well: Geographic redundancy. It's extremely costly with on-prem.
Re:We use our own hardware at Fastmail by sgarland on Sunday December 22, 2024 @10:05AM (#42486760)
Only if you’re literally running your own datacenters, which is in no way required for the majority of companies. Colo giants like Equinix already have the infrastructure in place, with a proven track record.

If you enable Multi-AZ for RDS, your bill doubles until you cancel. If you set up two servers in two DCs, your initial bill doubles from the CapEx, and then a very small percentage of your OpEx goes up every month for the hosting. You very, very quickly make this back compared to cloud.

Re:We use our own hardware at Fastmail by Cyph0n on Sunday December 22, 2024 @11:50AM (#42487492)
But reliable connectivity between regions/datacenters remains a challenge, right? Compute is only one part of the equation.

Disclaimer: I work on a cloud networking product.

Re:We use our own hardware at Fastmail by sgarland on Sunday December 22, 2024 @12:07PM (#42487610)
It depends on how deep you want to go. Equinix for one (I'm sure others as well, but I'm most familiar with them) offers managed cross-DC fiber. You will probably need to manage the networking, to be fair, and I will readily admit that's not trivial.
Re:We use our own hardware at Fastmail by irunmyownemail on Sunday December 22, 2024 @12:33PM (#42487794)
I use Wireguard, pretty simple, where's the challenge?
Re:We use our own hardware at Fastmail by Cyph0n on Sunday December 22, 2024 @12:44PM (#42487877)
I am referring to the layer 3 connectivity that Wireguard is running on top of. Depending on your use case and reliability and bandwidth requirements, routing everything over the “public” internet won’t cut it.

Not to mention setting up and maintaining your physical network as the number of physical hosts you’re running scales.

Re:We use our own hardware at Fastmail by icedchai on Sunday December 22, 2024 @10:49AM (#42487052)
Except, almost nobody, outside of very large players, does cross region redundancy. us-east-1 is like a SPOF for the entire Internet.
Re:We use our own hardware at Fastmail by liontwist on Sunday December 22, 2024 @11:25AM (#42487309)
Cloud noob here. But if I have a central database what can I distribute across geographic regions? Static assets? Maybe a cache?
Re:We use our own hardware at Fastmail by sgarland on Sunday December 22, 2024 @12:09PM (#42487634)
Yep. Cross-region RDBMS is a hard problem, even when you're using a managed service – you practically always have to deal with eventual consistency, or increased latency for writes.
Re:We use our own hardware at Fastmail by dietr1ch on Sunday December 22, 2024 @10:12AM (#42486822)
Does it? I've seen outages around "Sorry, us-west_carolina-3 is down". AWS is particularly good at keeping you aware of their datacenters.
Re:We use our own hardware at Fastmail by toast0 on Sunday December 22, 2024 @10:41AM (#42486989)
It can be useful. I run a latency sensitive service with global users. A cloud lets me run it in 35 locations dealing with one company only. Most of those locations only have traffic to justify a single, smallish, instance.

In the locations where there's more traffic, and we need more servers, there are more cost effective providers, but there's value in consistency.

Elasticity is nice too, we doubled our instance count for the holidays, and will return to normal in January. And our deployment style starts a whole new cluster, moves traffic, then shuts down the old cluster. If we were on owned hardware, adding extra capacity for the holidays would be trickier, and we'd have to have a more sensible deployment method. And the minimum service deployment size would probably not be a little quad processor box with 2GB ram.

Using cloud for the lower traffic locations and a cost effective service for the high traffic locations would probably save a bunch of money, but add a lot of deployment pain. And a) it's not my decision and b) the cost difference doesn't seem to be quite enough to justify the pain at our traffic levels. But if someone wants to make a much lower margin, much simpler service with lots of locations and good connectivity, be sure to post about it. But, I think the big clouds have an advantage in geographic expansion, because their other businesses can provide capital and justification to build out, and high margins at other locations help cross subsidize new locations when they start.

Re:We use our own hardware at Fastmail by dietr1ch on Sunday December 22, 2024 @12:18PM (#42487700)
I agree it can be useful (latency, availability, using off-peak resources), but running globally should be a default and people should opt-in into fine-grained control and responsibility.

From outside it seems that either AWS picked the wrong default to present their customers, or that it's unreasonably expensive and it drives everyone into the in-depth handling to try to keep cloud costs down.

Re:We use our own hardware at Fastmail by bdangubic on Sunday December 22, 2024 @10:25AM (#42486904)
if you see that you are doing it wrong :)
Re:We use our own hardware at Fastmail by sgarland on Sunday December 22, 2024 @10:36AM (#42486962)
AWS has had multiple outages which were caused by a single AZ failing.
Re:We use our own hardware at Fastmail by dietr1ch on Sunday December 22, 2024 @01:53PM (#42488276)
Yup, I was referring to, I guess, one of these,

- https://news.ycombinator.com/item?id=29473630: (2021-12-07) AWS us-east-1 outage

- https://news.ycombinator.com/item?id=29648286: (2021-12-22) Tell HN: AWS appears to be down again

Maybe things are better now, but it became apparent that people might be misusing cloud providers or betting that things work flawlessly even if they completely ignore AZs.

Re:We use our own hardware at Fastmail by ayuhito on Sunday December 22, 2024 @11:28AM (#42487337)
My company used to do everything on-prem. Until a literal earthquake and tsunami took down a bunch of systems.

After that, yeah we’ll let AWS do the hard work of enabling redundancy for us.