Some high end servers have hot-swappable CPU's, RAM etc. (using mirroring in the case of RAM [1]). Of course you need to keep enough installed at any one time to keep the system running. Couple it with a suitable dual-ported storage array, and almost any system component can be replaced without taking down the server.
The main reason it's not more common is that few people are willing to pay for it vs. getting redundancy via multiple cheaper servers, especially once you've got enough load that you need to scale out anyway.
Not really a computer but some distributed systems already work that way. I've read somewhere that Netflix (might have been Amazon?) is designed in such a way that it's capable of satisfying certain requirements even when services are down.
Are we talking about a "fallback db servers take over when the main ones drop", or "static assets server morphs into temporary db server if the main one drops"? Because there is a massive difference.
With virtualization/containerization that's not an unreasonable scenario. One of VMWare's selling points is that a sufficiently expensive vSphere cloud can expand and contract over its available hardware depending on load/time-of-day. With iLO integration, it can even power off the hardware it's not using and power it on when needed. If one server goes down, its VMs can be distributed over the remaining hypervisor, leading to potential resource contention but maintaining availability.
There are crazy cases of plasticity like that, this is more of "massive nosql caching infrastructure is down, everything else works overdrive to still mostly function correctly".
So when your legs stop working and you start crawling around the floor with your hands pulling the rest of your body, is that plasticity too?
It's easy to continue working at increased costs when you don't have a cache. That's.. that's what a cache is for; it's not critical to the infrastructure, it's here to reduce the costs.
Not to rain on any parade of course, I'm just pointing out I'd like to see more cases of actual plasticity of an email server that puts all jobs on hold while it temporarily takes over for a database server that just stopped responding.
I'm not saying servers can be plastic worth anything, I'm saying that the role of the cerebellum is to assist functions that exist elsewhere, so missing it is not the same as missing a primary functional unit.
The motor cortex is still doing its original job, it just has to work harder.
Caching can be critical if the volume is high enough. There are physical limitations of computing appliances that make sites like Google or Facebook actually impossible to run without extensive caching and indexing layers, not just prohibitively expensive.
I thought that was obvious. OP was making a point about things running without cache at the cost of increased load... I'm sure Google Search couldn't reliably achieve that right now, but we were not talking about Google Search.
If one designed their down-scaling properly, the caching layer would be shut off as the system contracted, not being part of solving the domain problem.
The brain doesn't seem to be like a single CPU - more like a cluster of millions of CPU. It wouldn't be surprising that the system could work very well even if you disconnected a few thousand of those CPUs here and there.
(NOTE: disconnected, not destroyed; the woman's cerebellum didn't develop; things would be much different if you tried to surgically remove it)
Not really; riak is composed entirely of nodes that are more or less identical. Losing your cerebellum would be like losing a component on every one of your nodes because you only have one cerebellum.
Losing the cerebellum would be like losing a DC for which you have no backup, which then would require you to attempt to duplicate the original functionality in other DCs.
The main reason it's not more common is that few people are willing to pay for it vs. getting redundancy via multiple cheaper servers, especially once you've got enough load that you need to scale out anyway.
[1] http://www.redbooks.ibm.com/abstracts/tips0259.html