Ask HN: Which co-location providers would you recommend in the US?

Not saying they are to blame, but it seems like there were electrical issues in the affected data center. Could be something for op to look out for.

Also, I think most situations don't need to go from 0-servers to 44U of servers. (Although VC backed bet-the-farm situations may like that route)

Location is clearly important. Where do you want your datacenter(s) and do you want all locations managed by the same company or different companies.

Electrical reliability: some sites are fed from multiple substations, have a well maintained battery room, redundant generators, well tested transfer switches... and some don't. Automatic transfer switches tend to be a SPoF though, and a major provider, doing everything right, is likely to have an outage at one of their facilities due to a transfer switch failure once every 3-10 years, and afterwards, there will be an unavoidable scheduled maintenance to replace it (unless it had to be replaced during the outage). Maybe there's a new way to install transfer switches redundantly though?

HVAC reliability: HVAC needs electricity too, so see the previous one, but servers don't like to be hot, what are their plans for when HVAC equipment fails.

Network reliability: if you're at a carrier neutral site, you'll get fiber to your rack from your upstreams and then it's all up to you or them. If your provider is your transit, do they deliver redundant connections (lacp), do they run redundant connections all the way to their border router, redundant connections to their upstreams, do they have multiple upstreams, will they pull fiber from an upstream carrier to your rack. Do they participate in the local peering exchange? Also, have a capacity in mind.

Remote hands / physical access is important. If you have a lockable rack, do all the racks have the same key? IPMI can avoid a lot of physical time on the machines, but not all of it.

In addition to all of these, there's a what they say, and what's actually the case, and if they'll let you inspect / audit.

There's no wrong answers on these, I have my personal hosting at a facility with probably wishy washy answers to everything and I have low trust, but it's cheap and I don't need nine nines. Other people need all the reliability. Or something in between.

This is certainly a relevant question for some businesses (e.g. US-based ones); but I would think not for the majority.

Say that I have a SaaS company that serves many US customers, but which currently has no physical presence in the US. (This isn't a hypothetical; my company is headquartered in Canada, and most of the employees are Canadian — some are remote, but we currently don't employ any Americans.)

And say that I want to run a low-latency base-load "POP" to serve US customers, ideally just starting with one DC that's placed as centrally (in Internet latency terms) to as much of the contiguous US as possible.

Say that I currently do this by just using IaaS — AWS and GCP obviously have great connectivity — but for base load, the egress is getting too expensive, and they also don't offer machines that are vertically resourced nearly as highly as modern technology makes possible. (We do realtime OLAP stuff; the ability to have 100+ cores, multiple TBs of memory, and — critically! — more than 9TB of NVMe per machine, is all very useful to us.)

Say that I don't expect our base-load needs to grow very quickly, so we don't expect to have high needs for physical access. And that we won't own very much hardware at first — maybe 20 (very expensive) machines.

My thinking, here, is that in such cases, it would actually be a waste of money to have even a single full-time ops staffer; that in such a case, it would be lower OpEx to just have some kind of retainer contract with an "ops as a service" company willing to send someone out to the DC on our behalf for installations, removals, upgrades, and troubleshooting. For anything that doesn't require putting hands on the hardware, we can fix it with BMC access (or, if we can't reach the BMC, then a phone call to the DC with strong suspicion that one of their switches is faulting upstream of us.)

Or, equivalently, there's no reason that we wouldn't work with a DC that's willing to do a "managed bare metal" offering with customer-supplied hardware — that's just an "ops as a service" offering provided by the DC staff, after all.

Or hey, why do we want to get into the business of eventually having to resell old server parts if we don't have to? We don't actually own the hardware yet; the plan to purchase the hardware is part of the greater plan to decrease base-load TCO. If we can find a provider who will lease us managed bare metal, in exactly the configurations we want, at reasonable prices, then that would make even more sense, wouldn't it? They'd also maintain the pool of spares for us, so we don't have to buy and sit on those. (Of course, this is starting to creep closer to having a middle-man who can extract rents by charging on a value-add basis, like IaaS providers do. Some managed-bare-metal leasing providers are like this; but I've found that there are others that operate on a cost-plus basis — probably because they're overgrown DC + managed-ops-staff offerings that haven't yet realized they've repositioned themselves to be middle-men.)

This was the line of thinking we went down, and in the end it actually lead us back out of the US entirely. Since we're Canadian, we found some financial advantages in going with a managed bare-metal offering from a company with a Canadian presence that we could pay in CAD. So we went with OVH Canada (i.e. their Montreal DC.) AFAICT, the network map from Montreal looks like "a fat 40ms-long pipe over to N. Virginia, and then peering equivalent to hosting in US-East-1 from there." Works great for peering with GCP US-Central-1, where we still have our elastic load.

For a company like mine, would you do something different?

- does the colo state think you having servers there is a business presence, and you owe them tax

It's interesting that they explicitly call ("√M") out MACSec support (encryption at OSI Layer 2/Ethernet):

* https://en.wikipedia.org/wiki/IEEE_802.1AE