At KubeCon EU 2026, Tigera’s message was not simply that Kubernetes networking remains difficult. It was that networking has become the layer where several of the market’s biggest infrastructure problems now converge.
That is what made this conversation with Ratan notable.
The discussion started with AI workloads, but it quickly expanded into something broader: hybrid deployment models, multi-platform Kubernetes estates, VMware migration, tool sprawl, and the growing cost of stitching together fragmented networking, security, and observability stacks. Tigera’s argument is that these are no longer separate operational issues. They are increasingly the same problem showing up in different forms.
That is an important shift.
For years, networking was often treated as one technical domain among many in Kubernetes. Now it is becoming a control point for portability, consolidation, security, and modernization. If that framing is right, then networking is no longer just infrastructure plumbing. It is becoming the operational layer that determines whether platform strategies stay manageable at scale.
AI is pushing compute toward the data, not just data toward the cloud
One of the strongest observations in the conversation was Tigera’s view of how AI is changing deployment patterns.
Rather than moving all sensitive data into centralized cloud environments, many organizations are doing the opposite. They are bringing models and compute closer to the data, especially when that data is sensitive, regulated, or operationally difficult to relocate. The result is a more fragmented but more realistic architecture: cloud for some workloads, on-premises infrastructure for others, and eventually edge environments for inference.
That matters because AI is often discussed as if it naturally drives centralization. In practice, it may accelerate hybrid complexity.
If organizations end up running AI across cloud, data center, and edge environments, then they need more than raw compute capacity. They need a networking and security model that works consistently across those planes. Tigera’s pitch is that a single stack across those environments reduces both operational fragmentation and the risk of policy inconsistency.
The integration tax is becoming harder to justify
The second major theme was consolidation.
Ratan described a pattern that will sound familiar to most enterprise platform teams: networking, network security, observability, ingress, egress, encryption, service mesh, and cluster-to-cluster connectivity are often assembled from multiple components and vendors. That may work initially, but it creates a recurring integration burden every time platforms or dependencies change.
That burden is no longer trivial.
According to Tigera, some customers were spending 75% of their time re-stitching infrastructure components and only 25% serving internal users. Whether that exact ratio generalizes broadly or not, the underlying point is credible. The operational cost of maintaining fragmented platform stacks is becoming more visible, especially as release cycles continue and teams remain understaffed.
This is where Tigera’s unified-platform message lands well. The company is arguing that customers increasingly want one management plane, one operator, and one integrated solution spanning load balancing, gateway functions, ingress and egress controls, encryption, observability, service mesh, and policy enforcement.
That is not just a product packaging story. It is a response to a market that is becoming less tolerant of integration overhead.
Multi-platform Kubernetes is now the default enterprise condition
Another useful point in the conversation was the acknowledgment that most enterprises did not choose platform diversity as a strategy. They accumulated it.
Different teams adopted different Kubernetes distributions over time, often for legitimate local reasons. But the result is that many organizations now operate heterogeneous estates across cloud, on-premises, and edge environments. That creates a staffing problem as much as a technical one.
If each platform requires different networking models, different tooling, and different operational expertise, then complexity compounds quickly. Tigera’s argument is that a consistent networking stack across multiple Kubernetes platforms reduces the need for separate teams and lowers the learning burden.
That aligns with a broader market reality. Enterprises are increasingly trying to simplify around the layers they can standardize, even if they cannot standardize every platform underneath.
VMware migration is exposing how much modernization is really a networking journey
The VMware migration theme was also one of the most practical parts of the discussion.
Tigera described a three-step customer journey:
- Lift and shift virtual machines without changing hardcoded networking dependencies
- Decouple workloads from legacy network infrastructure
- Refactor workloads into more cloud-native architectures over time
That sequence is analytically useful because it reflects how modernization actually happens in large enterprises. Most organizations do not jump directly from legacy virtual machines to fully refactored microservices. They move in stages, often under time pressure, and usually with limited appetite for changing fragile networking assumptions too early.
This is where networking becomes strategic again. If vendors can help customers preserve continuity during migration while gradually increasing programmability and portability, they become more than a point solution. They become part of the modernization path.
Portability is becoming a hedge against pricing pressure
Ratan also tied networking abstraction directly to vendor lock-in and pricing pressure.
That is worth paying attention to.
In the current market, portability is no longer just an architectural ideal. It is a negotiating position. Enterprises are increasingly aware that platform concentration can lead to pricing exposure, especially when workloads are deeply coupled to one vendor’s operational model.
Tigera’s claim is that abstracting networking across platforms makes workloads easier to move and gives customers more leverage. That is a strong message in a market where cost optimization and optionality are now core buying criteria.
Bottom line
Tigera’s positioning at KubeCon EU 2026 was that Kubernetes networking is no longer just about connectivity. It is becoming the layer where AI deployment models, platform sprawl, migration pressure, cost control, and modernization strategy all intersect.
That makes networking a much bigger strategic issue than many enterprises have historically treated it.
If the next phase of Kubernetes is defined by hybrid AI, multi-platform operations, and converged VM-container environments, then the winners may be the vendors that reduce integration tax, preserve portability, and simplify the path from legacy infrastructure to programmable platforms.
Tigera is betting that networking is where that battle will be won.
