Re: 1 NIC. Port
If you take my comment and simply remove the redundant PSUs then the description fits, no matter the scale: you have other storage & CPUs that processes can be run on and the job is to keep enough of the right ones of those alive to get the job done. Other parts of your description are impressive in human terms but can be compared to "how it used to be": Big example, moving your processes from one geographical region to another: in human terms, this is awfully impressive, but if you compare it to shuffling from one cabinet to another that is "only" two feet away in the days of wet string instead of multi-gigabit glass then the modern hardware will complete the data transfer faster and more reliably. Similar statements can be made about every part of the system: the "only" difference is that we all can see the massive, massive size of the hyperscaling because us humans have stayed the same size and we'll get puffed out walking from one end of the cable to the next.
> infrastructure is a commodity ... think at scale
Yes. Again, as computers have grown up, each part has gone from being a carefully curated single instance to a commodity: no longer would we consider saying that the memory bank over there ("the one we've labelled 'Nellie'") is something that needs care and attention with a hot soldering iron and can of contact cleaner - instead we rip out the DDR with a few milion Nellies on it and pop in a new one.
Everything in computing has followed the same scaling.
And each time scaling occured, we started by making it the responsibility of the application code to take advantage of it. Again, redundant PSUs are pretty much the only place where it was not dropped onto the coder: every other use of system resources was down to the application. Mirroring data over multiple platters? Those rich enough to own three platters had that right there in the application code. Making use of two or more execution units? Started in the application. And you can see all of this still happening if you look at current day tiny systems: microcontrollers still get treated that way (and very sensible that is, too).
So what happened as these scaled-up systems became commodities? Do we still expect the application writers to handle all those aspects?
Of course not.
What is handling them?
Some on specialised hardware (RAID controllers, NICs, DDR busses, SSD internals- although plenty of this 'hardware' is still software running on embedded CPUs) and all the rest is handled by - the Operating System!
To cut this short, as I have to go out, the application team should NOT be the ones coping with EC2 units dying and shifting workloads. THAT should be being provided as a commodity, on top of the pile if cabinets in the data centre. There should be an Operating System taking all the commonality away from the application level.
There ought to be no reason to discuss ins and outs of keeping EC2 instances working than there is worrying about how RAM controllers manage to use 8 channels of DDR slots.