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

Why we use our own hardware

fastmail.com

Post reply on HN
Print view View original

311–320 of 547 posts

Re: Why we use our own hardware

#311

Post by AtlasBarfed »

UltraSane wrote: post #235
evantbyrne wrote: post #223

Earlier quoted context omitted.

Making API calls from a VM on shared hardware to KMS is vastly more secure than doing AES locally? I'm skeptical to say the least.

Encrypting data is easy, securely managing keys is the hard part. KMS is the Key Management Service. And AWS put a lot of thought and work into it. https://docs.aws.amazon.com/kms/latest/cryptographic-details...

It's now been two years since I used KMS, but at the time it seemed little more than S3 API interface with Twitter size limitations

Fundamentally why would KMS be more secure than S3 anyway? Both ultimately have the same fundamental security requirements and do the same thing.

So the big whirlydoo is KMS has hardware keygen. im sorry, that sounds like something almost guaranteed to have nsa backdoor, or has so much nsa attention it has been compromised.

Re: Why we use our own hardware

#312

Post by [deleted] »

Beijinger wrote: post #207

I was told Fastmail is excellent, and I am not a big fan of gmail. Once locked out for good in gmail, your email and apps associated with it, are gone forever. Source? Personal experience. "A private inbox $60 for 12 months". I assume it is USD, not AU$ (AFAIK, Fastmail is based in Australia.) Still pricey. At https://www.infomaniak.com/ I can buy email service for an (in my case external) domain for 18 Euro a year a…

[deleted]

Re: Why we use our own hardware

#313

Post by johnklos »

motorest wrote: post #253
johnklos wrote: post #65

The whole push to the cloud has always fascinated me. I get it - most people aren't interested in babysitting their own hardware. On the other hand, a business of just about any size that has any reasonable amount of hosting is better off with their own systems when it comes purely to cost. All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding…

> All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding,(...) This is where you lose all credibility. I'm going to focus on a single aspect: performance. If you're serving a global user base and your business, like practically all online businesses, is greatly impacted by performance problems, the only solution to a physics problem is to deplo…

> This is where you lose all credibility.

People who write that, well...

If you're greatly impacted by performance problems, how does that become a physics problem that has as a solution which is being closer to your users?

I think you're mixing up your sales points. One, how do you scale hardware? Simple: you buy some more, and/or you plan for more from the beginning.

How do you deal with network latency for users on the other side of the planet? Either you plan for and design for long tail networking, and/or you colocate in multiple places, and/or you host in multiple places. Being aware of cloud costs, problems and limitations doesn't mean you can't or shouldn't use cloud at all - it just means to do it where it makes sense.

You're making my point for me - you've got emotional generalizations ("you lose all credibility"), you're using examples that people use often but that don't even go together, plus you seem to forget that hardly anyone advocates for all one or all the other, without some kind of sensible mix. Thank you for making a good example of exactly what I'm talking about.

Re: Why we use our own hardware

#314

Post by AtlasBarfed »

j45 wrote: post #188
UltraSane wrote: post #151

Earlier quoted context omitted.

"All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding," This is false. AWS infrastructure is vastly more secure than almost all company data centers. AWS has a rule that the same person cannot have logical access and physical access to the same storage device. Very few companies have enough IT people to have this rule. The AWS KMS is vastly m…

The cloud is someone else’s computer. It’s like putting something in someone’s desk drawer under the guise of convenience at the expense of security. Why? Too often, someone other than the data owner has or can get access to the drawer directly or indirectly. Also, Cloud vs self hosted to me is a pendulum that has swung back and forth for a number of reasons. The benefits of the cloud outlined here are often a lot of…

One of the ways the NSA and security services get so much intelligence on targets isn't by direct decryption of what they are storing in data or listening in. A great deal with their intelligence is simply metadata intelligence. They watch what you do. They watch the amount of data you transport. They watch your patterns of movement.

So even if eight of us is providing direct security and encryption in the sense of what most security professionals are concerned with key strength etc etc etc, Eddie of us still has a great deal about of information about what you do, because they get to watch how much data moves from where to where and other information about what those machines are

Re: Why we use our own hardware

#315

Post by ryao »

jmakov wrote: post #146
ryao wrote: post #46

Earlier quoted context omitted.

Unlike ext4 that locks the directory when unlinking, ZFS is able to scale on parallel unlinking. In specific, ZFS has range locks that permit directory entries to be removed in parallel from the extendible hash trees that store them. While this is relatively slow for sequential workloads, it is fast on parallel workloads. If you want to delete a large directory subtree fast on ZFS, do the rm operations in parallel. F…

Thank you very much for sharing this, very insightful.

Thank you for posting your original comment. The process of writing my reply gave me a flash of inspiration:

https://github.com/openzfs/zfs/pull/16896

I doubt that this will make us as fast as ext4 at unlinking files in a single thread, but it should narrow the gap somewhat. It also should make many other common operations slightly faster.

I had looked into range lock overhead years ago, but when I saw the majority of time entering range locks was spent in an “unavoidable” memory allocation, I did not feel that making the operations outside the memory allocation faster would make much difference, so I put this down. I imagine many others profiling the code came to the same conclusion. Now that the memory allocation overhead will soon be gone, additional profiling might yield further improvements. :)

Re: Why we use our own hardware

#316

Post by wslh »

UltraSane wrote: post #259
wslh wrote: post #250

Earlier quoted context omitted.

From a critical perspective, your comment made me think about the risks posed by rogue IT personnel, especially at scale in the cloud. For example, Fastmail is a single point of failure as a DoS target, whereas attacking an entire datacenter can impact multiple clients simultaneously. It all comes down to understanding the attack vectors.

Cloud providers are very big targets but have enormous economic incentive to be secure and thus have very large teams of very competent security experts.

You can have full security competence but be a rogue actor at the same time.

Re: Why we use our own hardware

#317

Post by TheFlyingFish »

Lots of people here mentioning reasons to both use and avoid the cloud. I'll just chip in one more on the pro-cloud side: reliability at low scale.

To expand: At $dayjob we use AWS, and we have no plans to switch because we're tiny, like ~5000 DAU last I checked. Our AWS bill is Meanwhile, RDS (for example) has given us something like one unexplained 15-minute outage in the last six years.

Obviously every situation is unique, and what works for one won't work for another. We have no expectation of ever having to suddenly 10x our scale, for instance, because we our growth is limited by other factors. But at our scale, given our business realities, I'm convinced that the cloud is the best option.

Re: Why we use our own hardware

#318

Post by mbesto »

maccard wrote: post #175
tylerchurch wrote: post #123

Earlier quoted context omitted.

I think this is only true for teams and apps of a certain size. I've worked on plenty of teams with relatively small apps, and the difference between: 1. Cloud: "open up the cloud console and start a VM" 2. Owned hardware: "price out a server, order it, find a suitable datacenter, sign a contract, get it racked, etc." Is quite large. #1 is 15 minutes for a single team lead. #2 requires the team to agree on hardware s…

I work for a 50 person subsidiary of a 30k person organisation. I needed a domain name. I put in the purchase request and 6 months later eventually gave up, bought it myself and expensed it. Our AWS account is managed by an SRE team. It’s a 3 day turnaround process to get any resources provisioned, and if you don’t get the exact spec right (you forgot to specify the iops on the volume? Oops) 3 day turnaround. Already…

> 3 day turnaround process to get any resources provisioned

Now imagine having to deal with procurement to purchase hardware for your needs. 6 months later you have a server. Oh you need a SAN for object storage? There goes another 6 months.

Re: Why we use our own hardware

#319

Post by pixelesque »

stefan_ wrote: post #299
motorest wrote: post #253

Earlier quoted context omitted.

> All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding,(...) This is where you lose all credibility. I'm going to focus on a single aspect: performance. If you're serving a global user base and your business, like practically all online businesses, is greatly impacted by performance problems, the only solution to a physics problem is to deplo…

Is everyone running online FPS gaming servers now? If you want your page to load faster, tell your shitty frontend engineers to use less of the latest frameworks. You are not limited by physics, 99% aren't. I ping HN, it's 150ms away, it still renders in the same time that the Google frontpage does and that one has a 130ms advantage.

Erm, 99%'s clearly wrong and I think you know it, even if you are falling into the typical trap of "only Americans matter"...

As someone in New Zealand, latency does really matter sometimes, and is painfully obvious at times.

HN's ping for me is around: 330 ms.

Anyway, ping doesn't really describe the latency of the full DNS lookup propogation, TCP connection establishment and TLS handshake: full responses for HN are around 900 ms for me till last byte.

Re: Why we use our own hardware

#320

Post by dietr1ch »

sgarland wrote: post #121
bdangubic wrote: post #113

Earlier quoted context omitted.

if you see that you are doing it wrong :)

AWS has had multiple outages which were caused by a single AZ failing.

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.

Post reply on HN