IT has to factor the cost of the VMware Tax into its infrastructure planning. Where does this tax come from? It is the extra expense in hardware needed, to compensate for the overhead of VMware’s inefficient virtualization code. Adding additional components like vSAN for storage, or NSX for networking only makes the tax more severe. These components will adversely impact applications and users if IT doesn’t work around the overhead. These workarounds cost money, increase complexity and create a more brittle infrastructure that struggles to adapt to the organization’s future needs.
There are three primary effects of the VMware Tax:
- A lower-than-possible VM Density.
- The continued need for stand-alone bare-metal workloads.
- A proliferation of the three-tier architecture.
To compensate, organizations are forced to:
- Buy more or more powerful physical servers than what should be necessary.
- Buy high-performance dedicated all-flash arrays.
- Face a never-ending future of premature server and storage refreshes.
The Cost of the VMware Tax is one of the hidden costs of VMware. Learn about the rest of them in our on-demand webinar, “The 4 Hidden Costs of VMware.”
The Cost of VMware Tax on Server Planning
The first cost of the VMware Tax is that meeting the organization’s demands requires using either fewer virtual machines (VMs) per server and more physical servers or more powerful physical servers to support more VMs per server. As we discuss in our article, “HCI isn’t Infrastructure,” using more servers highlights the scaling issues common in Hyperconverged Infrastructure (HCI) and leads most customers to purchase more powerful servers to reduce cluster node count.
Using more powerful servers with more CPUs, cores, and RAM increases those servers’ costs. This approach also increases VMware licensing costs since the company charges by the physical CPU installed in its nodes, and the expectation is that after the Broadcom acquisition is complete, the company will switch to a per-core licensing strategy and is expected to raise costs even further.
Overcoming the VMware Tax with Powerful Servers
Overcoming the cost of the VMware Tax by using more powerful servers exposes the lack of flexibility when scaling, the typical VMware architecture has. More powerful servers will likely be used longer before organizational growth requires IT to add another server to the cluster. When it comes time to add additional servers to the cluster, two or three years later, that exact server type may no longer be available, or a better option may be available using a different CPU vendor. Managing nodes of different types within a VMware environment is convoluted, leading many customers to establish an entirely separate cluster, further increasing costs and complexity.
There is also the challenge of, after three or four years, the hypervisor or storage vendor may upgrade its software to the point that it no longer supports the original servers. At that point, IT is faced with refreshing its entire server infrastructure to maintain compatibility with the updated software.
The Cost of the VMware Tax on Scale
Hyperconverged Infrastructure (HCI) solutions expect a “balanced scale,” where the organization adds equal amounts of computing, storage, and networking. This requirement exposes another cost of the VMware Tax. No organization always needs to scale these three components at the same time. Especially when purchasing more powerful servers, the organization will likely need more storage performance or capacity before requiring additional computing resources.
Again, legacy HCI designs like those from VMware (vSAN, vSphere, NSX) or Nutanix expect almost identical nodes to be added to the cluster. To meet capacity demand, customers are adding servers similar to their original installation, and they end up paying for and wasting a massive amount of CPU and memory that come with those servers. Although a few vendors have evolved to allow more storage-centric nodes, these are complex band-aids with many compromises and increasing complexity. Most customers choose not to use them.
The enforcement of balanced scaling forces most customers considering HCI solutions to disqualify them later. As a result, the VMware Tax indirectly proliferates the more complex and expensive three-tier architecture.
VergeOS Enables High VM Density and Imbalanced Scale
VergeOS is a highly efficient data center operating system (DCOS) that enables high per-physical server VM populations. It does this by integrating the three standard data center tiers (networking, computing, and storage) into a single code base that is a fraction of the size in terms of lines of code without sacrificing features. This effort is the foundation of Ultraconverged Infrastructure (UCI) which moves beyond the flawed HCI model to deliver the full promise of a truly converged infrastructure.
A more compact code base means faster execution on the same hardware. Integrating the traditional data center tiers means that efficiency carries throughout the entire solution. Our typical customer can support 25 to 30% more VMs per physical server with VergeOS than their prior solution (Hyper-V, VMware, Nutanix) while running on the very same, existing hardware.
As the organization’s demands grow, VergeOS provides flexible and intelligent scaling. An optimized internal-node communication protocol ensures near-linear performance increments as IT adds nodes to the environment. VergeOS’ flexibility means that IT can add nodes of almost any type, including storage or compute-centric nodes. VergeIO has never forced the retirement of old servers to support a new version of VergeOS.
VMware Tax Encourages Bare Metal
Despite all the advantages and flexibility of virtualization, the cost of the VMware Tax means that many customers still view some applications as bare-metal only. The performance demands of these servers are just too strenuous for the virtual environment. They either starve other VMs on the same node of resources or can’t continually guarantee access to the performance these applications demand. They also tend to be certain hardware types, like GPUs, that specific applications need, which legacy solutions don’t adequately virtualize.
The result is IT must purchase and stand up dedicated silos of computing and storage for these applications, which increases costs and complexity. Additionally, these bare-metal environments don’t benefit from core virtualization capabilities like seamless VM migration.
VergeOS Delivers Near Bare Metal Performance
VergeOS’ compute efficiency also helps formerly bare-metal-only workloads to be able to realize the benefits of virtualization. Historically, many bare-metal workloads remained bare-metal because of the storage I/O demands. VergeOS integration of storage, coupled with the performance of its file system, delivers near-bare-metal performance for these workloads. The VergeOS storage component, VergeFS, ensures all reads are local to the virtual machine. Finally, VergeOS supports nodes of various CPU classes within the same instance. Our customers can and do mix Intel, AMD, and GPU-based nodes, even of different generations. They repeatedly tell us that they were able to virtualize formerly bare-metal workloads without any degradation of performance.
Conclusion
With its inefficiencies and subsequent costs, the VMware Tax represents a significant concern for IT infrastructure planning. Its impact on VM density and the push toward bare-metal workloads signifies the increased expenses and complexities organizations face. As the technology landscape continues evolving, solutions like VergeOS emerge as viable alternatives, offering enhanced VM densities and near bare-metal performance.
By merging the conventional data center tiers and focusing on efficient operation, VergeOS addresses the challenges posed by VMware’s model and presents a forward-thinking solution that adapts to an organization’s dynamic needs. As organizations strive for agility, cost-effectiveness, and scalability, transitioning to platforms prioritizing these attributes will be paramount. VergeOS makes that transition seamless thanks to our IOmigrate capability.
