Live data from Hacker News

Why we use our own hardware

fastmail.com

491–500 of 547 posts

Re: Why we use our own hardware

#491

Earlier quoted context omitted.

My suggestion would be to try Purelymail. They don't offer much in the way of a web interface to email, but if you bring your own client, it's a very good provider. I'm paying something like $10 per year for multiple domains with multiple email addresses (though with little traffic). I've been using them for about 5 years and I had absolutely no issues.

Pricing it hard to understand: https://purelymail.com/advancedpricing Usernames on shared domains: 1 to 6 letters: $0.20 per user per year 7 to 12 letters: $0.05 per user per year 13+ letters: $0.02 per user per year WTF?

I have no idea why that's a thing. :D

Personally I use the simple pricing scheme and looking at billing page, I pay around ~$0.35-0.4 monthly for 5 domains, with 4 explicitly set email addresses and catch-all for all domains to a common mailbox. Also I must state again, there is quite little traffic on all.

Re: Why we use our own hardware

#492

Plugging https://BareMetalSavings.com in case you want to ballpark-estimate your move off of the cloud Bonus points: I'm a Fastmail customer, so it tangentially tracks ---- Quick note about the article: ZFS encryption can be flaky, be sure you know what you're doing before deploying for your infrastructure. Relevant Reddit discussion: https://www.reddit.com/r/zfs/comments/1f59zp6/is_zfs_encrypt... A spreadsheet of re…

Yeah, we know about the ZFS encryption with send/receive bug, it's frustrating our attempts to get really nice HA support on our logging system... but so far it appears that just deleting the offsending snapshot and creating a new one works, and we're funding some research into the issue as well. This is the current script - it runs every minute for each pool synced between the two log servers: https://gist.github.co…

Thanks for sharing!

Re: Why we use our own hardware

#493

Earlier quoted context omitted.

>As the fortunes of AWS et al rose and rose and rose, I kept looking at their pricing at features and kept wondering what I was missing. They seemed orders of magnitude more expensive for something that was more complex to manage and would have locked us into a specific vendor's tooling. But everyone seemed to be flocking to them. In 2006 when the first aws instances showed up it would take you two years of on demand…

"buying the hardware from a retail store." Never buy wholesale and never develop on immature hardware, I have seen c** with multiple 9 y.o. dev servers. I could shorten the ROI to less than 6 months.

What is c*? (seriously, I am not a native speaker and cannot turn the stars into a word that makes sense)

Re: Why we use our own hardware

#494
post #431

Earlier quoted context omitted.

You know how to set up a rock-solid remote hands console to all your servers, I take it? Dial-up modem to a serial console server, serial cables to all the servers (or IPMI on a segregated network and management ports). Then you deal with varying hardware implementations, OSes, setting that up in all your racks in all your colos. Compare that to AWS, where there are 6 different kinds of remote hands, that work on all…

It's really not like that at all. If it was, I expect after 25 years of growth FastMail would probably have noticed. Much of what you're describing assumes a poorly run company that isn't able to make good choices -- if you have such a mix of odd hardware os OSes then that's pretty bad sign. Prioritise simplicity. For remote hands, 2 kinds is sufficient: IP KVM, and an actual person walking over to your machine. Can'…

> Every time this conversation has come up online over the last few decades there's always a few people who parrot this claim it's all too hard. I can't imagine these comments come from people that have actually gone and done it.

My experience of this is that people either fall into the camp of having done it under a set of non-ideal constraints (leading them to do it badly), or it's post-rationalising that they just don't want to.

Re: Why we use our own hardware

#495

Earlier quoted context omitted.

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

I guess since this is Hacker News, I shouldn’t be surprised that there are a bunch of commenters who are absolutely certain they and their random colo provider will do a better job of defeating the almighty NSA than AWS.

You won’t even know when they serve your Colo provider with a warrant under gag order, and I’m certain they’ll be able to bypass your own “tamper-proof” protections.

Re: Why we use our own hardware

#496

Earlier quoted context omitted.

When you say “cloud”, are you including old school web hosts that will rent you a dedicated server? Like OVH, Hetzner or Hivelocity? Because you can get some insane servers for like $300/month (eg brand new 5th gen Epyc 48-core / 0.5TB ram / lots of NVME) and globally available.

Those could count. But you'll still end up having to do some linux admin, which a lot of people can't do anymore. The whole point is that the closer you can get to "write code, run code", the faster you can launch and innovate.

It sounds like you’re describing PaaS then.

Re: Why we use our own hardware

#497

I've been doing this job for almost as long as they have. I work with companies that do on-prem, and I work with companies in the cloud, and both. Here's the low down: 1. The cost of the server is not the cost of on-prem. There are so many different kinds of costs that aren't just monetary. ("we have to do more ourselves, including planning, choosing, buying, installing, etc, ") Those are tasks that require expertise…

> 7. ... Another business I worked for literally hired and fired four separate teams to build an on-prem OpenStack cluster, and it was the most unstable, terrible computing platform I've used, that constantly caused service outages for a large-scale distributed system.

I've seen similarly unstable cloud systems. It's generally not the tool's fault, it's the skill of the wielder.

Re: Why we use our own hardware

#498

Earlier quoted context omitted.

AWS is only expensive if you intend to run a lot of workloads and have a large, competent technical team. For businesses with I can teach someone from accounting how to restore the entire VM farm in an afternoon using the AWS web console. I've never seen an on prem setup where a similar feat is possible. There's always some weird arcane exceptions due to economic compromises that Amazon was not forced to make. When y…

I'm confused why you would even need AWS then (what's running on the VMs)? My impression is the standard compute (as in CPUs+RAM) isn't expensive, it's the storage (1 PB is less than half a rack physically now, comparing with the yearly prices listed), and so if you don't have much data, the value of on-prem isn't there.

For smaller shops I'd argue storage is the hardest part. I've done several OpenStack and baremetal K8s deployments on prem and the part that always stressed me out the most was storage. I'd happily pay a markup for that vs just about anything else that would be more economical to do on prem for smaller simpler workloads.

Re: Why we use our own hardware

#499

Earlier quoted context omitted.

All of that is... completely unrelated to the GP's post. Did you reply to the right comment? Do you think "politics" is something you solve with Ansible?

> Cloud expands the capabilities of what one team can manage by themselves, enabling them to avoid a huge amount of internal politics. It's related to the first part. Re: the second, IME if you let dev teams run wild with "managing their own infra," the org as a whole eventually pays for that when the dozen bespoke stacks all hit various bottlenecks, and no one actually understands how they work, or how to troublesho…

> I keep being told that "reducing friction" and "increasing velocity" are good things

As always, good rules are good, and bad rules are bad.

Like most people on the internet, you are assuming only one of those sets exist. But you are just assuming a different set from everybody that you are criticizing.

Re: Why we use our own hardware

#500

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…

> how do people get so sold on a thing that they'll go online and fight about it, even when they lack facts or often even basic understanding?

Are you new to the internet?

Post reply on HN