> I don't think the hardware is that trivial. I used to think that, but I've learned a lot more respect for the people who understand how to troubleshoot it, ho

> I don't think the hardware is that trivial. I used to think that, but I've learned a lot more respect for the people who understand how to troubleshoot it, how to purchase compatible components, and spot troublesome products and brands. It's a whole career, it has its nuances. I didn't mean to suggest there isn't a skillset there. And that's really important when you're doing it at scale. The person who knows what they're doing can do it in a fifth of the time -- they don't have to consult the manual because they already know the answer, they don't have to spend time exchanging an incompatible part for the right one. But when you're talking about an amount of work that would take the expert three hours a year, having it take the novice fifteen hours a year is not such a big deal. > Of course this is an advantage for hosting internal company stuff, for web facing things you may need to place hardware in remote datacenters, and then you do need people on location on call who can service it. You have to generally have much larger scale for that to make sense. On the other hand you have to have rather larger scale to even need a remote datacenter. A local business that measures its web traffic in seconds per hit rather than hits per second hardly needs to be colocated at a peering exchange. It's really when you get to larger scales that shared hosting starts to get interesting again. Because on the one hand you can use your scale to negotiate better rates, and on the other hand your expenses start to get large enough that a few percent efficiency gain from being able to sell the idle capacity to someone else starts to look like real money again.