Honestly it's probably a lot easier at that scale. When you're a single dude maintaining 10 boxes you're fucked if one dies on you. When you're 50 people maintaining tens of thousands of boxes it's not such a big deal.

Also, when you're buying that quantity you qualify the hell out of your hardware. The big boys have groups dedicated to making sure that they get what they want from their suppliers.

DO orders from Dell who has contracts in place with their hardware suppliers to supply the same part for the life of the product. Someone like Amazon or Google order enough parts that they have the same setup, just directly with the ODM.

> Speaking of which, how the fk does a startup like Digital Ocean do it?

Carefully with DevOps/Networking/Infrastructure folks.

I used to manage several thousand physical Linux servers. It can be done fairly painlessly when you control the environment.

I noticed you mentioned recording servers with analog tuner cards; today it'd be much easier with SDR hardware streaming RTMP streams to cloud servers writing the data out to network attached storage or even S3.

I'm not trying to take the piss here, but why would you use a real-time protocol to stream to an archive? And why SDR instead of a dedicated tuner/decoder?

RTMP is of course not required; you could write locally to your workers, and then push to your storage repo over http, rsync, whatever. My last gig was with video broadcast, so most of my work was with rtmp, Akamai, etc. Different ways to skin the same cat. Almost all hardware video IP encoders support rtmp though, and you can colocate with where your storage is.

As /u/akiselev mentioned, SDR is easier to extend with the hobbyist community that exists around it, especially if you have a custom application and need more control.

Why wouldn't you? RTMP is one of the most common ways to stream video and if you're already receiving live audio/video data from a tuner then you can easily package it into an RTMP stream going out to any number of archive servers running ffmpeg (which does the hard work of any transcoding or remuxing you need to do). All you have to do is package the RTMP stream, build ffmpeg yourself with nonfree and gpl options enabled, and run/monitor off-the-shelf software with an obnoxious number of command line arguments. Chances are you can package the RTMP stream straight from the source using ffmpeg too.

I don't know about the SDR vs tuner question but many SDRs are made with TV tuners and I'd bet you'd have more luck (especially long term) with the software written by the amateur radio community than whatever company makes your brand of TV tuner.

DTV decoding is really processor intensive, and is really only now possible on the fastest processor. You can do it in an FPGA, but those are expensive. ASIC are still the cheapest way to go. It's like hardware vs software H.264 decoding; night and day speed and efficiency difference.

Pew just released a study that showed people are starting to feel that they've lost control of their private data (which they have):

http://www.pewinternet.org/2014/11/12/public-privacy-percept...

Your vision of the future assumes that folks will remain complacent about how much they trust their doctors, health insurance companies, medical device companies and hospitals with their minute-to-minute activity.

Amazon and Google design their own hardware so it is much less likely to change out from under them.

Do they also design their own components? Because that's what we're talking about here.

Google is believed to assemble its SSDs, supposedly from Intel/Micron flash memory and Marvell controllers. So even though they're the same components you'd find in Intel/Crucial SSDs, Google would obviously not run in an issue due to some firmware upgrade.

They might do that, but they have also bought this SSD. Everyone large has it and/or the S3700 hanging around somewhere. It's a really solid drive and the price / performance / reliability is hard to beat (as with its predecessor, the 320).

When a giant company talks about building hardware themselves, it means that they thought they could get a better deal than their suppliers could get. At some point you're the source of your supplier's discount, rather than a beneficiary of it.

So they call up an ODM, ask for the same motherboard as always, oh but please hold the serial port to cut the BOM by $0.50. It is a custom design made for them, but it's all still built with the same commercially available stuff that everyone uses.

No one is going to design a motherboard from scratch, when they can use the Intel reference design. Likewise, that Marvell controller that Google might use on their Google-brand SSDs is going to run Marvell's standard firmware with maybe a few changes per Google's request.

I doubt Google would run into this issue in production though, because they should have an agreement that requests an exact firmware revision from their vendor. Any change to the firmware revision would require some sort of re-qualification, which should easily catch something this big.

It's still lame that Intel did this. The drive should have just been 4K when it launched, and every other drive since 2011 should be as well.

Giant companies should buy most of their hardware to reduce cost and focus on their main activity. But they should also build a small percentage of their hardware themselves to have the freedom to ditch away a supplier. This is also important to maintain good technical knowledge to negociate more wisely with suppliers.

they don't. it's the same stuff everyone else is using.

in fact, in some cases it's cheaper/shittier than the stuff everyone else is using, because individual component failure and performance matter less.

> God bless the rise of cloud computing. Seriously.

In other words, god bless that you can pay someone else to deal with it so you can make the shiny service?

Well, yes. That's the whole idea.