In my previous article, I reflected on what I would design differently if I were building an NSX platform today. That piece focused on architectural choices — fewer abstractions, clearer boundaries, stronger defaults.
But design decisions are only part of the story. What ultimately matters is who carries responsibility for how the platform behaves over time.
Much of my current work revolves around VMware Cloud Foundation and NSX. That hasn’t changed. What has changed is the altitude at which I tend to operate. The conversations are less about individual features and more about responsibility boundaries, lifecycle, and what the platform should enforce by default. VCF 9 simply makes those questions harder to ignore.
Deploying a platform is one thing. Owning it is something else entirely. And on a VCF 9 platform, that distinction becomes very visible.
Defaults and Guardrails
On a VCF 9 platform, one of the primary responsibilities of a platform engineer is defining the defaults that everything else inherits. This sounds simple, but it rarely is.
Defaults determine how namespaces are structured, how VPCs are segmented, what network isolation patterns are applied automatically, and which policies are enforced without anyone having to request them explicitly. They define what “normal” looks like.
In many organizations, the tendency is to focus on flexibility first. Every team wants options. Every application is treated as unique. Over time, this leads to exception-driven design, where the platform becomes a collection of special cases. A platform engineer has to resist that.
The goal isn’t to maximize flexibility. It’s to maximize safe autonomy. Application teams should be able to move quickly — within boundaries that are intentional and well understood. If every new workload requires new networking decisions or repeated security debates, the platform isn’t providing enough guidance.
In a VCF 9 world, constructs like VPCs and integrated lifecycle management make it easier to encode these decisions directly into the platform. That doesn’t remove responsibility. It concentrates it. The platform engineer must decide which choices are available, which are restricted, and which shouldn’t be visible at all. Those decisions shape the operational behavior of the platform far more than any single feature configuration.
Lifecycle Over Provisioning
Provisioning is visible. Lifecycle is not.
On a VCF 9 platform, provisioning a workload — whether a VM or a Kubernetes cluster — is increasingly straightforward. Templates exist. Policies are predefined. The automation layer does most of the work. That part isn’t where the platform engineer earns their keep.
The real responsibility sits in lifecycle.
Clusters need to be upgraded. Supervisor versions change. NSX components evolve. Dependencies shift. Policies that made sense six months ago may conflict with new operating models — all without breaking what already runs on the platform.
A platform engineer has to think in terms of failure domains and blast radius. What happens when a management domain upgrade introduces a behavioral change? How isolated are tenant VPCs during an incident? What is the rollback strategy if a network policy update has unintended side effects?
These aren’t provisioning questions. They’re lifecycle questions.
In many environments, the temptation is to optimize for day-one deployment. The real complexity shows up in year two and year three, when the platform has grown, ownership has shifted, and the original architects are no longer deeply involved.
On VCF 9, lifecycle is integrated across compute, storage, networking, and automation. That integration is powerful, but at the same time it also means that changes ripple across layers. The platform engineer needs to understand those relationships and design with change in mind from the beginning.
Provisioning makes something exist. Lifecycle ensures it continues to operate safely over time.
What the Platform Engineer Is Not Responsible For
Clear responsibility boundaries are just as important as defined ownership.
In many organizations, “platform engineering” becomes a catch-all term. Anything that sits somewhere between infrastructure and applications tends to fall under it, and that ambiguity creates friction quickly.
On a VCF 9 platform, the platform engineer isn’t responsible for writing application code, designing CI/CD pipelines, tuning individual microservices, or debugging application-level issues. Those are different domains, owned by different teams.
The platform engineer also isn’t responsible for designing bespoke networking patterns for every workload. If each new application triggers a new NSX policy design session, the platform engineer has drifted into application ownership. The goal is to define patterns once and let teams consume them safely.
Nor is the platform engineer a ticket router between compute, storage, and networking teams. One of the reasons VCF exists is to reduce fragmentation between those domains. The responsibility is to ensure they behave coherently — not to manually coordinate every interaction.
In practice, this means saying “no” at the right time. It means pushing back when flexibility undermines operability. It means protecting the platform from well-intentioned customization that introduces long-term fragility.
Platform engineering isn’t about controlling everything. It’s about deciding what must be controlled — and leaving the rest to the teams that own it.
Closing Thoughts
On a VCF 9 platform, the role of the platform engineer is less about configuring components and more about defining how they work together over time.
The technology stack is mature. The automation layers are capable. Provisioning is no longer the hard part.
Responsibility is.
Defining defaults, designing for lifecycle, setting boundaries, and protecting coherence across compute, storage, networking, and automation aren’t glamorous tasks — but they determine whether the platform remains stable and operable years after its initial deployment.
In that sense, platform engineering on VCF 9 isn’t a new discipline. It’s a shift in focus — less about building things and more about owning how they behave over time. And that shift changes what the role is really about.
rutgerblom.com 
Leave a comment