Live data from Hacker News

Why we use our own hardware

fastmail.com

201–210 of 547 posts

Re: Why we use our own hardware

#201

Earlier quoted context omitted.

No, using Ansible to distribute public keys does not get you very far. It's fine for a personal project or even a team of 5-6 with a handful, but beyond that you really need a better way to onboard, offboard, and modify accounts. If you're doing anything but a toy project, you're better off starting off with something like IPA for host access controls.

What's the risk you're trying to protect against, that a "better" (which one?) way would mitigate that this one wouldn't? > IPA Do you mean https://en.wikipedia.org/wiki/FreeIPA ? That seems like a huge amalgamation of complexity in a non-memory-safe language that I feel like would introduce a much bigger security liability than the problem it's trying to solve. I'd rather pony up the money and use Teleport at that p…

It's basically Kerberos and an LDAP server, which are technologies old and reliable as dirt.

This sort of FUD is why people needlessly spend so much money on cloud.

Re: Why we use our own hardware

#202

Earlier quoted context omitted.

Counterpoint: if you’re never “messing with servers,” you probably don’t have a great understanding of how their metrics map to those of your application’s, and so if you bottleneck on something, it can be difficult to figure out what to fix. The result is usually that you just pay more money to vertically scale. To be fair, you did say “my tune might change past a certain size.” At small scale, nothing you do within…

I don’t think you’re correct. I’ve watched junior/mid-level engineers figure things out solely by working on the cloud and scaling things to a dramatic degree. It’s really not a rocket science.

I didn't say it's rocket science, nor that it's impossible to do without having practical server experience, only that it's more difficult.

Take disks, for example. Most cloud-native devs I've worked with have no clue what IOPS are. If you saturate your disk, that's likely to cause knock-on effects like increased CPU utilization from IOWAIT, and since "CPU is high" is pretty easy to understand for anyone, the seemingly obvious solution is to get a bigger instance, which depending on the application, may inadvertently solve the problem. For RDBMS, a larger instance means a bigger buffer pool / shared buffers, which means fewer disk reads. Problem solved, even though actually solving the root cause would've cost 1/10th or less the cost of bumping up the entire instance.

Re: Why we use our own hardware

#203
post #188

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…

> The cloud is someone else’s computer

Isn’t it more like leasing in a public property? Meaning it is yours as long as you are paying the lease? Analogous to renting an apartment instead of owning a condo?

Re: Why we use our own hardware

#204

Earlier quoted context omitted.

But isn't using Fastmail akin to using a cloud provider (managed email vs managed everything else)? They are similarly a service provider, and as a customer, you don't really care "who their ISP is?" The discussion matters when we are talking about building things: whether you self-host or use managed services is a set of interesting trade-offs.

Yes, FastMail is a SAAS. But there adepts of a religion which would tell you that companies like FastMail should be built on top of AWS and it is the only true way. It is good to have some counter narrative to this.

Being cloud compatible (packaged well) can be as important as being cloud-agnostic (work on any cloud).

Too many projects become beholden to one cloud.

Re: Why we use our own hardware

#205

Earlier quoted context omitted.

Do you need those tools? It seems that for fundamental web hosting, you need your application server, nginx or similar, postgres or similar, and a CLI. (And an interpreter etc if your application is in an interpreted lang)

I suppose that depends on your RTO. With cloud providers, even on a bare VM, you can to some extent get away with having no IaC, since your data (and therefore config) is almost certainly on networked storage which is redundant by design. If an EC2 fails, or even if one of the drives in your EBS drive fails, it'll probably come back up as it was. If it's your own hardware, if you don't have IaC of some kind – even so…

Get two servers (or three, etc)?

Re: Why we use our own hardware

#206

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…

Most companies severely understaff ops, infra, and security. Your talking points might be good but, in practice, won’t apply in many cases because of the intractability of that management mindset. Even when they should know better. I’ve worked at tech companies with hundreds of developers and single digit ops staff. Those people will struggle to build and maintain mature infra. By going cloud, you get access to matur…

Using a commercial cloud provider only cements understaffing in, in too many cases.

Re: Why we use our own hardware

#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 and I get 5 inboxes. And it is based in Switzerland, so no EU or US jurisdiction.

I have a few websites and fastmail would just be prohibitive expensive for me.

Re: Why we use our own hardware

#208

Earlier quoted context omitted.

The thing that frustrates me is it’s possible to know how to do both. I have worked with multiple people who are quite proficient in both areas. Cloud has definite advantages in some circumstances, but so does self-hosting; moreover, understanding the latter makes the former much, much easier to reason about. It’s silly to limit your career options.

Being good at both is twice the work, because even if some concepts translate well, IME people won't hire someone based on that. "Oh you have experience with deploying RabbitMQ but not AWS SQS? Sorry, we're looking for someone more qualified."

That's a great filter for places I don't want to work at, then.

Re: Why we use our own hardware

#209

Earlier quoted context omitted.

> identity management (AAD/IAM) Do you mean for administrative access to the machines (over SSH, etc) or for "normal" access to the hosted applications? Admin access: Ansible-managed set of UNIX users & associated SSH public keys, combined with remote logging so every access is audited and a malicious operator wiping the machine can't cover their tracks will generally get you pretty far. Beyond that, there are commer…

No, using Ansible to distribute public keys does not get you very far. It's fine for a personal project or even a team of 5-6 with a handful, but beyond that you really need a better way to onboard, offboard, and modify accounts. If you're doing anything but a toy project, you're better off starting off with something like IPA for host access controls.

Why do think that? I did something similar at a previous work for something bordering on 1k employees.

User administration was done by modifying a yaml file in git. Nothing bad to say about it really. It sure beats point-and-click Active Directory any day of the week. Commit log handy for audits.

If there are no externalities demanding anything else, I'd happily do it again.

Re: Why we use our own hardware

#210
post #87

Earlier quoted context omitted.

Cloud solves one problem quite well: Geographic redundancy. It's extremely costly with on-prem.

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

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.

Post reply on HN