Hacker News new | ask | show | jobs
by ranrotx 2603 days ago
AWS employee here--thoughts and opinions are my own.

Prior to AWS, I was in IT Operations at a large financial services company. I saw the writing on the wall that over time, companies would not want to manage this part of their IT infrastructure themselves. Keep in mind, I was someone who was responsible for keeping the lights on for a decent number of Linux severs.

For an individual company, there really isn't much value in having to maintain firmware levels on all your hardware, patch hypervisors (and try to coordinate all of the maintenance around a fixed pool of hardware), perform months-long evaluation of new hardware before purchasing, test and validate configurations on new hardware, etc. I used to do all of this. I don't miss it either.

Yes, the items above are important, but doing them right is really table-stakes for any reliable IT Operations department. You can choose to spend time getting these right, or delegate that responsibility to a service provider whose main job is to get that stuff right (and recoups that cost across a much larger customer base).

3 comments

What seems to often go unsaid in these discussions is that the choice isn't between cloud and colo. There's a third, hugely popular and mature option: dedicated providers - which address all of your issues.

It's convenient for cloud vendors to have people believe the choice is between them or having to deal with hardware.

But isn't dedicated providers a subset of cloud providers? I can see how having a focused provider with a narrow mission might be beneficial in some cases, but I can't say it's that much of an advantage compared to the ecosystem & convenience of a cloud provider.
what's an example of a dedicated provider?

I also worked in ITOps at a medium-ish company and we were moving our colo to Azure, when I left.

There are thousands (tens of thousands?). OVH is probably the biggest by server count. Softlayer arguably had the most potential (prior to its IBM acquisition). Hivelocity, ReliableSite, WebNX, Hetzner, LeaseWeb, Online.net, DataPacket, QuadraNet, PhoenixNap, ...
Hetzner, scaleway and packet.net come to mind
i3d.net will give you a machine, with as hands-on support as you want up to even patching the OS.
Rackspace
The guys that are selling managed services on AWS?
They sell all of those those things. RS has their fingers in many pies, even though some of them appear to conflict at first glance.
Yeah, I think the other factor that seems to be missed here is access to security patches for the hardware/frmware and OS. If you look at recent history with even the CPU attacks over the last few years Amazon and MS had access to the issue and vender workarounds months before even other large cloud players did. Digital ocean and other very large players were left holding the bag when the announcements were made with very short windows to get their systems up to speed. Consumer level onprem were waiting sometimes months for the patches/firmware and software to be available.

Not saying at all that is how it SHOULD BE, but if you are planning on pulling back to onprem (or colo) it should be a concern as it is a hard to mitigate risk.

correct me if i'm wrong, but I thought basically all recent exploits (including spectre/meltdown) were only really viable on shared hypervisors?

so while yes, there weren't any fixes for your onprem virtualizers -- there also wasn't any immediate danger as the attacker had to compromise one of your nodes before actually using these attack vectors...

What is missing from this discussion is level of control and tradeoffs.

First, having a full level of control can be desirable.

Second, you trade off maintaining firmware levels on hardware and software levels on hardware to managing the way cloud providers build networking and servers themselves (and the cost control as well).

Maintaining your own hardware and keeping it up to date really isn't as bad as people make it out to be. Its not hard to get right either, assuming you can hire any sort of decent system engineer.