Program/process migration was a thing in the 1980s but was largely abandoned and ultimately replaced in the 2000s by VM migration, which solved the problem of migrating OS and network state by migrating the entire OS and network stack (though there is still some complexity regarding IP forwarding when a VM moves to a new physical network, as well as the annoying problem of data access potentially becoming non-local and therefore much slower.) But VM migration always struck me like hiring a truck to haul your entire house to the grocery store.
Now that containers are supplanting VMs, we've largely abandoned that migration capability. Instead the approach seems to be to make containers disposable, spinning up a new container and shutting down the old one. Migrating minimal, per-application VMs is still possible but not very popular.
Gate reduces OS state and cleverly moves across CPU architectures by leveraging webasm, but IP address forwarding is still a pain across networks.
It always occurred to me that something like this would be doable (even with older webasm-like systems like NaCl), but the network/IP forwarding bit and non-local storage problem still seemed like it might make it more trouble than it was worth.
Nonetheless, I would like to revive the approach of a distributed OS on a cluster of machines where you wouldn't really care which machine your code was actually running on, and could easily add more compute/memory/storage/interconnect in a modular manner. Live hardware and kernel upgrades seems like a nice feature as well.
We separate and migrate state all the time. The database is a persistent heap for many shortlived execution contexts. HPC relies heavily on check point and restart. Many on-prem and off-prem cloud environments rely heavily on migration.
The mechanics required to implement migration unlock many other architectural wins. I don't think process migration has been abandoned at all. I think for too long it was controlled by the OS, these new VM environments liberate migration by being able to run it from userland.
All of https://en.wikipedia.org/wiki/MOSIX was predicated on globally addressable resources within a cluster. In an SDN environment, connections don't even need to be _forwarded_ because they are already an abstraction for user code.
I've envisioned Gate's network resource abstractions to work at a higher level, using symbolic references (such as URLs) and message-oriented protocols rather than keeping TCP connections alive. It's not ideal, but decouples the program from the environment - which is the goal.
5 comments
[ 0.27 ms ] story [ 22.8 ms ] threadNow that containers are supplanting VMs, we've largely abandoned that migration capability. Instead the approach seems to be to make containers disposable, spinning up a new container and shutting down the old one. Migrating minimal, per-application VMs is still possible but not very popular.
Gate reduces OS state and cleverly moves across CPU architectures by leveraging webasm, but IP address forwarding is still a pain across networks.
It always occurred to me that something like this would be doable (even with older webasm-like systems like NaCl), but the network/IP forwarding bit and non-local storage problem still seemed like it might make it more trouble than it was worth.
Nonetheless, I would like to revive the approach of a distributed OS on a cluster of machines where you wouldn't really care which machine your code was actually running on, and could easily add more compute/memory/storage/interconnect in a modular manner. Live hardware and kernel upgrades seems like a nice feature as well.
The mechanics required to implement migration unlock many other architectural wins. I don't think process migration has been abandoned at all. I think for too long it was controlled by the OS, these new VM environments liberate migration by being able to run it from userland.
All of https://en.wikipedia.org/wiki/MOSIX was predicated on globally addressable resources within a cluster. In an SDN environment, connections don't even need to be _forwarded_ because they are already an abstraction for user code.