About page is pretty impressive. I understand how memory and storage can be clustered this way, I guess it's just like virtual memory and you have another layer of indirection via their hypervisor. What I don't understand is how you can partition computation the same way and not have performance tank.
Something like MOSIX (os-level ability to ship processes, their IO, etc. across the network), being less indirect, should theoretically outperform this sort of thing, but people don't even deploy those very often.
It's almost always harder, but still not harder enough to write apps that decompose explicitly to being distributed.
Implicitly, you take on risks where either your whole VM dies if any physical member dies, or you eat the performance penalty of some kind of application-naive consensus, or yet some other hideous compromise. There's no good answers and you get what you pay for.
Computing's RAID0 with worse performance and worse reliability.
With traditional enterprise hypervisors, boxes are sized for least TCO and to be large enough to comfortably hold the largest VM... and then the farm is usually sized to have at least N+k (k >= 1) capacity to avoid killing off VMs in order to perform maintenance or be trapped without some spare capacity for new VMs. Critical VMs use lock-stepped mirroring on multiple physical boxes to avoid downtime from hardware failure. Furthermore, most enterprise hypervisors allow migrating both storage (disk images) and computing (the running VM's state) resources to different hw (hw failure notwithstanding).
If folks are trying to vertically scale one app or one system to become a giant box without using explicit parallelism, it's going to be slow and painful.
(As a teenager, I once ran an actual Fortran nuclear reactor simulator on Windows beige box and later played with making code using OFED performant over Infiniband... don't ever inherit two brands of gear and expect it to work)
