Id rather think its a failure in planning.From AWSs playbook the conventional wisdom is that things fail all the time and you have to plan for these eventualities.See the Netflix models and Googles multihoming approach to spreading the service offering.Its always going to be the case that a cloud provider can fall over however if you are simultaneously running on different providers , all you have to worry about is the speed of rerouting traffic to your still operational site.Short of the entire internet keeling over from a backhoe incident you should be sitting pretty.
True for cloudformation , when spinning up multicloud systems it pays to invest in a tool like terraform.Currently we are running a hybrid Google Cloud AWS deployment and it helps to keep the infrastructure consistent.
Would depend on the choice of unikernel and how theyr doing their stuff osv.io for example basically run the app in kernel space on top of a hypervisor and inherently as hardware agnostic as possible.
Id point you to osv.io havent really played arounf with iy much though the concept is pretty intriguing .Being able to run the kernel directly on the hypervisor , and containing only your app and whats needed to run , thus obviatibg the need for device drivers with everything running in the kernel address space.Also check out LING for the erlangVM
If done right can really be awesome , set up stack using hasicorp's consul(consul.io) and theres the option to change the TTLs and cache limits.If using the DNS interface the updates are relatively painless and nodes are almost instantly available when provisioned.
