The following post is entirely my opinion and does not reflect the opinions of my employer.
VMware Cloud Foundation is the latest iteration of what started as EVO:Rack and became EVO SDDC. With another big emphasis at VMworld 2016, VMware Cloud Foundation (VCF) saw the product become generally available to external customers. In my role at VMware, I have been able to see the sausage made and been heavily involved in the VCF product. As such, I thought it the product going GA, now would be a good time to talk about some of the products strengths and weaknesses. If you are unfamiliar with the VCF product, I encourage you to read the publicly available white paper published in August 2016.
VMware Cloud Foundation started out as an entirely hardware-based platform for private cloud, but has now evolved to also include a software-based platform that can be used to provide a hybrid cloud offering (public + private). In the interest of full disclosure, my experience has been entirely with the hardware-based platform running on several Dell hardware platforms. The most interesting piece of the VCF platform was the initial discussion of VMware trying to solve the holy grail of running a private cloud — updating the entire VMware software stack. I believe every vSphere administrator has seen how difficult it is to upgrade all of the vSphere components running inside the software stack — and has only gotten more difficult when new technologies like NSX have been added. The VCF platform has worked to solve the complexities by including a SDDC software lifecycle management component.
The hardware stack includes several options for hardware vendors, the common thread being the use of hyper-converged infrastructure (HCI) with the nodes being listed on the vSphere and Virtual SAN HCLs. The network stack includes a leaf-spine topology with some minor modifications to allow Virtual SAN clusters to span multiple racks.
The software stack includes what I would consider the full vSphere SDDC stack — vSphere (ESXi & vCenter), Virtual SAN, NSX, vRealize Operations and vRealize Log Insight. The SDDC Manager is a new component, unique to the VCF platform, that provides a unified interface for executing the workflows for deployment, installation and upgrades of the SDDC components. The SDDC Manager will become an interface for the vSphere administrator during the deployment of new hardware and upgrades of the VMware software.
So lets talk about the strengths, everyone likes those right?
- Deployment of a full rack of servers 16-32 servers takes less than 3 hours. We are talking the installation of ESXi on every node, plus the SDDC stack deployed entirely on both the management (control) and workload (data) domains. It also includes vRealize Operations and vRealize Log Insight deployed and configured for the management and workload domains.
- Automated upgrades, with certified VCF builds, of vSphere and NSX. Depending on the cluster sizes and the storage policies for Virtual SAN, these upgrades complete within a limited number of hours. The holy grail seems to have been solved by the SDDC Manager software lifecycle piece.
- Extensive logging that is automated uploaded to the vRealize Log Insight instance running, so that if/when issues occur they can be searched and correlated with relative ease.
No product, from any company, is ever perfect. So what weaknesses have I seen?
- Every physical rack includes a requirement for management domain, wasting nodes on subsequent racks added to the environment. These management clusters, because of Virtual SAN should be sized to include 4 nodes, are very underutilized and leave a lot of capacity on the table.
- NSX is included in the hardware stack, but no configuration beyond the deployment of the NSX Manager and a set of NSX Controller nodes is performed. It will be left up to a customer to understand and implement NSX themselves post-deployment.
- Related to the above point, no uplink configuration is performed within the physical network. The environment will need to be manually connected to a customers existing network infrastructure.
- ESXi nodes are registered in vCenter using a DHCP-assigned IP address, not a FQDN that corresponds to the physical rack location of the server. This becomes important when hardware failures occur and a vSphere administrator has to log into the remote access module.
- An external jump host is required to perform much of the initial deployment and post-operation control of the environment. Each rack has a management switch that re-uses the same out-of-band (OOB) IP addresses for every ESXi node instead of unique IPs across racks.
The above points do not merely cross one another off. The fact that the VCF team solved the problems of deployment and upgrades of the main SDDC components is a HUGE WIN for VMware! I think the hardest challenge is going to be convincing existing enterprise customers to incorporate existing VMware infrastructure with the VCF platform. I also do not think any of the current weaknesses are issues that cannot or will not be solved in future iterations of the platform.
I am looking to see how the VCF platform continues to evolve.