When I started designing large NSX platforms, most of the hard problems were technical.
How far could we push microsegmentation?
How much overlay networking could we introduce?
How flexible could we make the design so it would survive future requirements?
At the time, that made a lot of sense.
Today, the situation is different. NSX is mature, stable, and extremely capable. But the environment around it has changed quite a lot. VMware Cloud Foundation 9, platform thinking, GitOps, and new operating models have shifted where things like responsibility, security, and control should live.
Looking back, I don’t think we designed things wrong. The designs were actually pretty good given the context. But if I were to design an NSX platform today, there are several choices I would make differently — not because NSX matters less, but because it needs to matter in a different way.
I would design for fewer abstractions, not more
Early NSX designs often aimed for maximum flexibility.
We built layers of abstractions: segments, groups, policies, nested constructs. The thinking was usually sound — future-proofing, reuse, and separation of concerns. And technically, this worked.
Operationally, it often didn’t.
Every abstraction adds cognitive load. Someone has to understand it, maintain it, debug it, and eventually explain it to the next team. Over time, that cost adds up faster than most people expect.
If I were designing today, I would be more conservative. I would introduce abstractions only when there is a clear need — not just because “we might need it later”.
I would stop treating microsegmentation as the primary security control
This is not an argument against microsegmentation. It is still one of the strongest features NSX offers.
But in the past, microsegmentation was often treated as the foundation of security — something every workload would eventually get, almost by default.
What has changed here is that there are now more layers that contribute meaningfully to blast-radius reduction:
- Identity-aware workloads
- Stronger application-level security controls
- Kubernetes-native isolation mechanisms
- Platform-level guardrails
In many environments, I’ve seen microsegmentation applied too early and too broadly. The result is usually slower adoption, more fragile policy sets, and eventually, a security posture that is hard to reason about during incidents.
Today, I would treat microsegmentation as a precision tool, not a baseline requirement. Extremely valuable in the right places — but not something that needs to be everywhere from day one.
The goal remains the same: reduce blast radius.
There are now simply more ways to get there.
What NSX is (and is not) meant to be today
This is something I myself underestimated early on.
NSX is very powerful, and that sometimes creates pressure to use it as a solution for problems it was never meant to solve.
NSX is not:
- A developer-facing API
- A CI/CD system
- An application security framework
- A replacement for platform governance
With Supervisor, namespaces, and Kubernetes in the picture, there is often pressure to surface NSX concepts upwards into application design. In many cases, that is a mistake.
NSX works best when it is treated as foundational infrastructure — something that provides strong defaults and guardrails, but stays largely invisible to application teams.
NSX is becoming part of the platform, not a separate design exercise
If I were designing an NSX platform today, I would lean heavily into the fact that NSX is no longer a separate layer that needs to be engineered and exposed on its own.
With the VPC construct and the VCF Automation All Apps model, NSX becomes an integrated part of the platform’s native application model. Lifecycle, isolation, and consumption patterns are defined up front, rather than stitched together through project-specific designs.
From an architectural perspective, this is an important shift. It reduces the need to surface NSX concepts upward, while still preserving strong isolation and governance underneath. It also enforces some of the discipline that previously depended entirely on human restraint.
This does not remove the need for NSX expertise — but it does change where that expertise should be applied. The focus moves away from per-application engineering and toward designing the platform’s default behavior correctly from the start.
I would align NSX more with platform lifecycle, not projects
One reason lifecycle thinking matters so much is organizational reality. Platforms rarely live in stable conditions. Teams change, people leave, responsibilities shift, and platforms get handed over.
Designs that assume long-term ownership by the same small group tend to fail quietly over time. When I design NSX platforms today, I try to assume that I won’t be there in a few years — and that the people operating it will have different constraints and priorities than I did.
This pushes me toward standardization, clearer boundaries, and designs that are easier to reason about under pressure.
Closing Thoughts
NSX still matters. A lot.
But its value today is less about how much it can do, and more about how deliberately it is used. Platform-centric and cloud-native operating models don’t make NSX irrelevant — they make its role clearer and more focused.
If I were designing an NSX platform today, I would aim for fewer concepts, clearer boundaries, and designs that survive not just technical change, but organizational change as well.
The best NSX platforms I see today are often the ones nobody talks about — because they just work, and nobody is afraid to touch them.
rutgerblom.com 
Leave a comment