I Was Building Virtual Networks in 2008. Now AI Is Changing the Rules Again.

In 2008, I was already asking businesses a question that made some IT decision-makers uncomfortable:

Why are we buying another physical server every time we need to run another application?

Think about what that meant back then.

A company needed an application server? Buy a server. File storage? Another server. Database? Another box. Before long, the server room was filled with machines running at a fraction of their potential, each consuming electricity, generating heat, and requiring maintenance.

And when one of those aging machines failed, the problem wasn't theoretical. Somebody's business operations could come to a halt.

I was working on a virtualization proposal for a company we'll call Westbridge Industrial Services. The objective was to consolidate aging infrastructure using VMware and Dell hardware while improving the way the organization provisioned systems and planned for recovery.

But here's the interesting part: the company's project documentation shows that several applications were already operating as virtual servers in production testing in May 2008.

We weren't simply discussing what virtualization might do someday. We were documenting how it was beginning to change the way that business operated.

The Real Revolution Wasn't VMware. It Was Separating Software From Hardware.

VMware was one of the technologies enabling the transition, but the bigger shift was architectural.

Once applications no longer depended on a dedicated physical machine, you could begin treating computing capacity as something to allocate rather than something you had to purchase one server at a time.

That opened the door to a different way of thinking:

• Create standardized virtual machines.
• Test configurations before putting production applications at risk.
• Consolidate workloads onto fewer physical servers.
• Improve resource allocation and operational flexibility.
• Build more consistent backup and recovery procedures.

Of course, there was a catch.

When several critical systems share physical infrastructure, a failure can affect more than one application. Your storage architecture, backup systems, network connectivity, and recovery planning become even more important.

A virtualization project was never just about installing a hypervisor.

By 2015, the Challenge Had Changed

Seven years later, a migration plan for Westbridge documented another familiar situation: the virtualization environment itself was getting old.

The proposed upgrade involved moving workloads from aging Dell servers running an earlier version of VMware ESXi onto a Dell PowerEdge VRTX converged infrastructure platform.

Now we weren't asking whether virtualization made sense.

We were asking how to modernize an existing virtual environment without disrupting the business.

The migration strategy included:

• Moving lower-risk virtual machines first.
• Testing and validating each migration phase.
• Identifying dependencies between infrastructure services.
• Scheduling mission-critical migrations during lower-impact windows.
• Establishing rollback and recovery procedures.

The project scope documents the intended migration strategy, rather than proving that every migration was completed.

But the engineering problem was real.

Virtualization solved the problem of having too many individual physical servers. It didn't eliminate the challenge of managing the infrastructure underneath them.

Now Comes the AI Infrastructure Question

Fast-forward to today's AI computing environment.

Instead of asking how many Windows servers we can consolidate onto a VMware host, infrastructure architects are considering different questions:

• Do AI inference workloads require dedicated GPUs?
• Should workloads run in containers rather than traditional virtual machines?
• Does a hypervisor provide valuable isolation for the intended workload?
• How should GPU memory, storage bandwidth, and network performance be allocated?
• Can existing enterprise infrastructure support AI applications?
• What is the most practical architecture for security, reliability, and cost?

And perhaps the biggest question:

Does the next generation of AI data centers need VMware at all?

The answer isn't a simple yes or no.

VMware, KVM, Kubernetes, and Bare Metal: Different Tools for Different Jobs

Traditional enterprise applications may continue to benefit from virtualized infrastructure.

GPU-intensive AI workloads may instead use Kubernetes-managed containers, dedicated bare-metal servers, or hybrid architectures.

Here's the distinction:

• VMware: An established virtualization platform for managing enterprise virtual machines, shared resources, availability, and infrastructure operations.
• KVM: A Linux-based virtualization technology that supports virtual machines and various hardware acceleration approaches.
• Kubernetes: A container orchestration platform for deploying, scheduling, and scaling applications, including GPU-enabled AI workloads when properly configured.
• Bare metal: Direct execution on physical servers, often useful for demanding AI workloads where dedicated hardware resources are important.
• Hybrid infrastructure: Combining virtual machines, containers, physical GPU servers, and cloud resources according to actual business requirements.

These technologies aren't always direct competitors.

Kubernetes, for example, doesn't replace every function of a hypervisor. And using VMware doesn't automatically make an AI deployment more reliable or cost-effective.

The right infrastructure depends on the workload, not the popularity of the platform.

What AI Data Centers Can Learn From the Virtualization Era

Some of the most important lessons from early virtualization projects remain relevant.

1. Consolidation introduces shared dependencies.

When multiple systems depend on common infrastructure, a hardware, storage, or network failure can affect many workloads.

2. Infrastructure must be designed around applications.

Hardware specifications matter, but application requirements and dependencies should drive architectural decisions.

3. Recovery capabilities must be tested.

A backup is not proof that an application can be restored successfully. Recovery testing remains essential.

4. Standardization improves operational consistency.

Templates, repeatable configurations, infrastructure automation, and documented processes can reduce avoidable mistakes.

5. Security must evolve with the architecture.

Moving applications into virtual machines, containers, or GPU clusters does not remove the need for network segmentation, identity controls, patching, and monitoring.

Is VMware Going Away?

I wouldn't make that prediction.

Organizations have substantial investments in VMware infrastructure, and many still depend on virtual machines for critical applications.

But the emergence of AI-focused infrastructure is changing how businesses evaluate their technology stacks.

The discussion is no longer simply about choosing a hypervisor.

It's about deciding which workloads belong on:

• Traditional enterprise virtualization platforms.
• Containerized application environments.
• Dedicated GPU servers.
• Public cloud infrastructure.
• Hybrid architectures that combine several approaches.

Organizations should also examine licensing, migration costs, workforce expertise, security requirements, and operational complexity before changing platforms.

The Technology Changed. The Engineering Questions Didn't Disappear.

One lesson from working with virtualization over the years is that the newest platform isn't automatically the right platform.

Back in 2008, businesses needed to understand why software didn't always require its own physical server.

Today, businesses need to understand why AI doesn't always require a particular hypervisor, cloud provider, or infrastructure stack.

We spent years learning how to virtualize servers.

Now we have to decide which workloads should be virtualized, containerized, or run directly on accelerated hardware.

And that decision will shape how organizations build and operate AI infrastructure for years to come.

What's Next?

In the next installment of From Virtual Networks to AI Factories, we'll take a closer look at:

VMware vs. KVM vs. Kubernetes: What Does an AI Data Center Really Need?

We'll examine GPU access, performance, workload isolation, licensing, operational complexity, and the architectural decisions businesses should understand before making expensive infrastructure investments.

References and Further Reading

• NIST SP 800-125: Guide to Security for Full Virtualization Technologies
• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• Linux KVM Project
• Kubernetes Documentation
• NVIDIA AI Infrastructure Documentation

Related NEXXIS Services

• [Virtualization & Cloud](/services/virtualization)
• [Network Setup & Management](/services/network-setup)
• [AI & Automation](/services/ai-automation)
• [MSP Consulting](/services/msp-consulting)

---

*Client names are pseudonyms. Certain identifying details have been generalized to protect confidentiality. Historical project descriptions are based on documented consulting records.*