Hi Daniel, I agree, at the end of the day it's all just about the apps. Also performance is much less of a factor for the two different methods than security, mobility, testability, reliability and other factors.

Would be interesting to get insights about differences of the solutions that compared on other level than just “kernel”.

Thanks for your comment. You could argue that, but there is nothing stopping you having an automated process to upgrade storage that is outside of the kernel at the same time as the hypervisor. Some companies have this today, a process to upgrade storage with one click while upgrading the hypervisor, you can do both at the same time. If you are benefitting from the built in storage capability then it could be an advantage to have it tightly coupled together.

Thanks for the comment. In a properly implemented architecture the loss of a local controller on a hypervisor host won't cause an APD. In fact the VM's won't even know anything has happened. However if the components of the hypervisor that deal with persistent local storage go funky, then you're on a path to an unhappy place. The biggest problem I see is that VMware a now bloating the kernel with this storage stack even is the vast majority of customers won't ever use it. You get the bugs without the benefits. Also implementing a storage controller in user space means it could run as a container, just as easily as it can run as a VM. Data and persistence of that data is definitely the top priority, that is why you want an architecture that protects data even if the local compute node is unavailable for whatever reason. Although I would equally argue that compute isn't disposable as it run's your VM's, the architecture is designed to recover those VM's in the case of a compute failure, and so should the persistent storage. Whether a vSwitch should run in a VM depends on the function of the VM. If the VM is a Docker Container VM, running many other containers, then yes maybe it should, if it's a load balancer or security device that support multiple virtual security domains, then maybe it should, but if it's none of those, then probably not. The hypervisor would be a better place for the vSwitch. The innovation could be done on SAN's, but that's not where it's happening, mainly due to scalability limitations. AFA's can be a good option, but there is no reason why a well run VSA can't outperform and out-scale an AFA, I see it all the time.

One question not covered here is data. e.g.:

Data is so important it is the first word in data center it is the sole reason DC’s exist and we have jobs. By running it on compute you are putting your most critical part that is entirely about persistence on top of a disposable compute layer.

Would you also say that the correct place for a vswitch is running in a VM? My view is that a hypervisor is an infrastructure visualizer providing IaaS to all consumers.

Then on scale and innovation the same can be done with modern SAN’s while AFA will scale higher than VSA.

I’m pretty sure you want to replace ‘not’ with ‘now’.

I think the isolation differences and consequences around bugs and bloat of the kernel are covered in the body of the article. By tightly coupling even if VSAN is not enabled it can still impact other parts of the operations as I have already experienced. It's not just enabling or disabling but isolation, security and the other aspects covered within the article.