The high availability feature's resilience is not bad, but it could be better. For example, whenever you lose any hardware, you will have interruptions on the services, and it reboots again on the other hardware host which is available at the crash time. That's good, but we would prefer to have zero downtime instead of the rebooting on the other server. We would prefer to have a zero downtime always-on configuration. VMware vSphere has a built-in feature called Fault Tolerance, but it's very limited for very limited VMs or very limited core count or CPU count, so it's not so useful for all the environment because of the limitations. The Fault Tolerance (FT) feature is very limited to very little core counts or very little VM counts, so you can't run the Fault Tolerance for all the servers or all the VMs, and that's very bad. If VMware vSphere could have any kind of built-in patch management environment with a repository, offline repository option, with test, non-production, and production environment separated, this would be perfect. Management of patch management with operating systems and including third-party applications which are running on the servers would enhance the VMware vSphere environment. VMware vSphere is very expensive. The worst aspect of VMware vSphere is the price. I can't tell you the exact cost at this time because the other team members in my teams are working on it, but I remember that the prices are very high. VMware vSphere is easy to scale, but it could be better, similar to a Kubernetes environment. It should have an automatic scale-out feature when the load gets high; if it gets some scale out automatically, it would be better than this, similar to Kubernetes or OpenShift.
