Hardware Has Never Cost More. Is Your Architecture Built for That Reality?

At NVIDIA GTC this week, the chairman of SK Group, which controls the world's largest supplier of high-bandwidth memory, told reporters that the global chip wafer shortage will likely persist until 2030. Not this year. Not next year. 2030.

The wafer supply deficit is running above 20% industry-wide. New fabrication capacity takes four to five years to come online. The root cause is not a temporary demand spike but a structural reallocation: AI infrastructure requires high-bandwidth memory at a scale that is pulling cleanroom capacity away from the standard DRAM and NAND that conventional enterprise servers depend on.

This is the environment in which enterprise IT leaders are operating for the foreseeable future. Hardware costs more. Hardware takes longer to arrive. And the old economics of traditional procurement, buying more capacity when you need more performance, no longer hold.

None of that changes the fact that compute, storage, and networking remain the foundation of every system. You cannot run workloads without them. But when that foundation costs more and takes longer to arrive, every layer of the stack that consumes hardware inefficiently becomes a liability.

Which raises the question every CIO should be asking: where in your architecture are you still consuming hardware for something software can do better?

The Case for Virtualization Has Never Been Stronger

Virtualization has been extending the life and efficiency of hardware for over two decades. What is new is the urgency. When DRAM prices surge nearly 95% in a single year and wafer supply is projected to stay constrained through the end of the decade, the cost of inefficiency at every layer of the stack compounds rapidly.

The question is no longer whether or not to virtualize. It is whether or not you have pushed virtualization far enough up the stack.

Most enterprises have virtualized compute. Many have virtualized storage. A growing number have virtualized networking at the infrastructure layer. But one layer consistently lags: application delivery.

Load balancers. Web application firewalls. API gateways. These functions still run on dedicated hardware appliances or on virtual appliances that behave like hardware and carry hardware-level cost, in the majority of enterprise environments. In a world where every rack unit needs to justify itself, that gap is no longer defensible.

What a Software-Defined Gateway Actually Delivers

A traditional application delivery architecture places purpose-built appliances at fixed points in the traffic path. One device handles external load balancing. Another manages internal routing. A third handles API authentication. A fourth inspects traffic for threats. Each is a capital expense, a configuration boundary, a failure domain, and a refresh cycle.

A software-defined gateway collapses all of those discrete points into a single programmable control plane. Whether running inside a VM on an existing virtualization platform or natively within a container environment, traffic is handled end-to-end by software: routing, TLS termination, authentication, rate limiting, circuit breaking, and observability. Policy is expressed as code. It is version-controlled, reproducible, and auditable. No firmware update or vendor support call required.

The performance argument for dedicated hardware has been closed for years. Modern software-defined gateways running on standard infrastructure handle enterprise traffic at scale with the observability and programmability that hardware appliances were never designed to provide.

The remaining argument for hardware appliances is inertia, not capability.

Portable vs Proprietary

Not all software-defined gateway solutions are equal, and the distinction matters more today than ever.

Some virtual appliances are software in name only. They run inside a specific hypervisor, require a particular vendor's control plane, or are licensed as part of a broader virtualization platform. These tools reduce hardware costs at the margin, but they substitute one form of lock-in for another. The procurement burden shifts; the architectural constraint does not.

The value of a truly software-defined gateway comes from its portability. A gateway that is environment-agnostic, hypervisor-agnostic, and location-agnostic runs identically whether deployed as a VM on an existing virtualization platform, as a workload inside a container environment, in a private data center, in a colocation facility, or in an air-gapped deployment with no external connectivity. Configuration is portable. Policy is portable. Observability is portable. The platform beneath you can change, and in 2026, platforms do change, without requiring you to re-architect the application delivery layer on top.

The right frame is not hardware versus software. It is portable versus proprietary.

Two Forcing Functions Arriving at the Same Time

The hardware economics argument is compelling on its own. But for much of the enterprise market, it is arriving alongside two platform-level disruptions that make the application delivery decision not just strategic but immediate.

VMware Migrations

The Broadcom acquisition of VMware has triggered one of the most consequential infrastructure re-evaluation cycles in a generation. Enterprises that built their virtualization strategy around vSphere and NSX are now reassessing licensing costs, platform dependencies, and long-term roadmaps. Many are moving workloads to alternative virtualization platforms. Some are accelerating their shift to containerized environments. All of them are asking the same question: which components of our stack do we carry forward, and which do we replace with something better?

VMware-bundled load balancing and gateway capabilities are, by definition, VMware-dependent. An enterprise migrating off VMware cannot lift those components and drop them into a new environment. It needs an application gateway that is platform-independent from the ground up. That is an architectural requirement, not a preference.

Ingress NGINX End-of-Life

For enterprises running containerized workloads, a parallel forcing function is already underway. Ingress NGINX, the most widely deployed Kubernetes ingress controller in production, announced end-of-life. This is not a minor dependency update, it is an architectural decision point.

The ingress layer is where external traffic enters, TLS terminates, routing decisions are made, and API governance begins. Replacing it isn’t a migration task, it means deciding what the next architecture looks like. Organizations that take the opportunity to rearchitect will  come out with a gateway layer that is more capable, more portable, and substantially less expensive than what they are replacing.

Both forcing functions are active simultaneously. Each, on its own, is a sufficient reason to revisit the application delivery layer. Together, they represent a generational consolidation opportunity.

Migrate. Modernize. Transform.

Enterprises are currently in all three phases of infrastructure evolution simultaneously:

• They are migrating: off VMware, off Ingress NGINX, off legacy appliances that cannot follow workloads to new environments.
• They are modernizing: replacing hardware-dependent components with software-defined alternatives that are portable, programmable, and environment-agnostic.
• They are transforming: deploying AI-powered applications, agent workflows, and model inference infrastructure that require governance capabilities hardware appliances were never designed to provide.

The risk in navigating all three individually is fragmentation. Each transition, approached in isolation, produces a new policy boundary, a new configuration silo, and a new governance gap. Audit risk compounds. Policy drift accumulates. Operational drag becomes structural.

The answer is a single software-defined gateway that follows workloads through migration, enforces consistent policy through modernization, and extends to govern AI traffic through transformation. One control plane. Consistent policy. No hardware in the critical path.

That control plane also serves as the enforcement point for AI governance: inspecting model requests before they reach an endpoint, enforcing authentication on agent calls, rate-limiting inference traffic by identity, and routing to different model versions based on policy. None of this requires a new appliance. It is a configuration change on the same gateway already managing the rest of your application traffic.

See It in Production

At KubeCon EU in Amsterdam next week, the Traefik Labs team will demonstrate exactly how this architecture operates in practice: software-defined ingress, API governance, and AI traffic management running on a single, environment-agnostic, hypervisor-agnostic, and location-agnostic control plane, with no hardware appliances in the critical path.

If you are working through a VMware migration, an ingress modernization, or the infrastructure layer for AI applications, we would welcome the conversation. Our team will be at Booth #981.

The hardware constraint is not going away before 2030. The enterprises that use this moment to unify their migration, modernization, and transformation onto a single portable gateway will carry a structural advantage that outlasts the current supply cycle.