This Document has limited distribution rights. It may not be distributed to the general public or shared beyond the employees of the licensee company. Upon the termination of an employee, whether voluntary or involuntary, access to this document must immediately cease. If the licensee company wishes to utilize this information in outward facing communications, please contact [email protected].

Neuralytix has been presenting around the world on datacenter architectures (including converged, hyperconverged, and composable), and the most common question asked by audiences is whether modern and future datacenter architectures will result in vendor lock-in.

While the question of whether there would be vendor lock-in is quite broad in nature, Neuralytix interpreted the question as one of hardware vendor lock-in. Of course, the answer is no. Although, we hasten to advise the audience that keeping datacenters as homogenous as possible is incredibly positive.

However, from a software perspective, we advised the audience that regretfully, there were multiple points of lock-in. In fact, at each level of the software defined datacenter (SDDC) stack – i.e. compute/hypervisor, network, and storage, there would likely to be lock-in, and not just for one refresh cycle. In our opinion, lock-in is likely to be in the period of 10 years. While this seems a long time, it is essential to remember that in the lifespan of a datacenter, it is not that long. Many datacenters keep the same hardware/software combinations for much longer periods of time.

At the compute or hypervisor level, there is, perhaps, the least amount of lock-in. Nowadays, hypervisors can be easily exchanged and through hybrid cloud and other migration techniques, virtual machines (VMs) can be moved from, say, ESXi to Hyper-V with relative ease, and a high degree of confidence in compatibility. Nonetheless, many enterprises that have implemented a VMware environment are more than likely to keep that environment, since it is not just the hypervisor that locks enterprises in, it includes the management, the enterprise-specific processes that are built around the automation, provisioning, deployment, and overall management (think vCenter and vSphere) that are more likely to “lock-in” an enterprise than the hypervisor itself.

On the network level, there are relatively few large-scale software defined networking (SDN) deployments, as most enterprises rely on traditional core and edge switches, so the “lock-in” is relatively low. Even for large-scale SDN deployments, the fact that network standards are very well engrained, ultimately, the protocols used should be compatible with whatever SDN software used.

However, when it comes to software-defined storage (SDS), this is where the “lock-in” is both inevitable, and arguably necessary. Whether it is VMware’s vSAN or another vendor’s SDDC or SDS software, in order to enable the scale-out nature of the virtual storage system, it is necessary to lay down a proprietary file system of some sort. It is this file system that really results in software “lock-in.”

Luckily, given the many new ways of VM migration, it is possible for enterprises to change SDS software – but the likelihood is very low. It would be the equivalent of changing cloud providers, the risk involved would be significant, and the rewards are unlikely to outweigh them.