This article is based on reporting originally published by devclass.com, drawing on an interview with Cornelia Davis, then CTO of Pivotal, conducted at DevOps Enterprise Summit in June 2019.
Kubernetes as a Paradigm Shift, Not Just a Tool
Kubernetes is widely discussed as a container orchestration platform, but Cornelia Davis, who served as CTO of Pivotal, argued in 2019 that its impact runs much deeper. In her view, Kubernetes is changing not only how software is deployed, but how developers fundamentally think about systems — and, by extension, how engineering organisations should structure themselves.
Speaking at DevOps Enterprise Summit, Davis framed her argument around an unexpected discipline: functional programming. Her thesis was not about a specific language or runtime, but about a shift in mental models that she believes Kubernetes is forcing on the entire industry.
Why Functional Programming Is Relevant Again
Davis described her own background as firmly imperative. “I’m a developer by background,” she said, and when she began studying computer science, “it was all imperative — I learned Pascal and C and all those languages.”
Decades later, she argued that the functional programming concepts she once set aside are now resurgent — and for a concrete reason:
“I believe it’s because we’re all distributed systems programmers now. When I started my degree 30 years ago, that was niche. Now, in the cloud, everything is distributed and it just turns out functional programming works far better in distributed systems.”
— Cornelia Davis, then-CTO, Pivotal (DevOps Enterprise Summit, June 2019)
She pointed to languages like Kotlin, Clojure, and Scala gaining mainstream traction in industry as evidence of this trend. The common thread: these languages encourage immutability, stateless transformations, and composability — properties that become critical when your application is spread across dozens or hundreds of distributed processes.
The Functional Analogue in Infrastructure: Declarative Configuration
Davis extended this reasoning from software to infrastructure. If functional programming’s defining characteristic in code is expressing what you want rather than how to achieve it, she argued that Kubernetes embodies the same philosophy at the systems level through declarative configuration.
“With Kubernetes, we say here’s what I want my topology to look like… and that’s the way the maintainers of the applications deploy their systems, which is very very different.”
— Cornelia Davis
In a traditional imperative deployment model, an operator writes scripts that execute each step in sequence — start this service, configure that port, wait for a health check. In Kubernetes, an engineer instead declares desired state in a YAML manifest. The control plane continuously reconciles actual state with that desired state. This is not just a technical convenience; Davis argued it is a fundamentally different cognitive model that frees engineers to reason at a higher level of abstraction.
Conway’s Law and Organisational Structure
Davis connected these technical shifts to Conway’s Law — the well-known observation that organisations tend to produce system designs that mirror their own communication structures. If the programming model changes, she argued, the incentives and pressures on team structure change too.
She described how Pivotal’s own platform (PAS — Pivotal Application Service) had, over six years, enabled customers to establish a clear separation between a platform team responsible for the shared runtime and an application team that consumed that platform on a self-service basis. This organisational pattern, she said, had been “the most enabling thing in our six-year history.”
In the Kubernetes world, she saw this as an unsolved problem:
“In the Kubernetes space, where those personas live and what they can do is not really being talked about… are you going to allow your app teams the access to actually change the compute infrastructure?”
— Cornelia Davis
This is a question that remains live in 2024, with the emergence of platform engineering as a discipline and tools like Backstage attempting to codify the platform-team/app-team boundary that Pivotal identified early.
Pivotal’s Late Arrival — and Its Honest Explanation
By mid-2019, Pivotal had attracted criticism from financial analysts for being slow to adopt Kubernetes, having scaled back financial targets around the same period. Davis addressed this candidly.
Pivotal’s platform had been container-based for approximately six years before the interview — predating Kubernetes’s rise to dominance. The internal reasoning was therefore: “We’re already doing this; Kubernetes is an implementation detail.” Davis acknowledged this was a strategic mistake in perception, if not in technology:
“So we perhaps could be accused of coming to the Kubernetes party a little late, and it’s because we felt we were already there.”
— Cornelia Davis
The more important factor, she argued, was ecosystem gravity. Kubernetes had captured the mindshare of hundreds or thousands of organisations independently of any single vendor. That community momentum was self-reinforcing and could not be dismissed as an implementation detail regardless of technical merit.
The Challenge: Turnkey vs. Optionality
Davis identified one of the genuine engineering tensions that Pivotal — and many platform teams since — have had to navigate: the tradeoff between a turnkey, opinionated platform and a flexible, composable one.
PAS was valuable to customers precisely because it made strong choices on their behalf. Kubernetes, by contrast, follows a Linux-influenced philosophy of small, composable components. Building something that is both immediately usable out of the box and extensible enough for enterprise optionality is, she said, “our big challenge going forward.”
This tension has not disappeared. It is visible today in the debate between managed Kubernetes services (which trade configurability for simplicity) and self-managed distributions (which do the opposite).
Reducing Cognitive Load as a Design Goal
Perhaps the most broadly applicable idea Davis articulated was about cognitive load. Her argument was that moving to a declarative, higher-abstraction model — whether in code or in infrastructure — is not just about developer convenience. It is about reclaiming mental bandwidth for harder problems.
“My whole thesis is if we change the programming model, it allows the humans to turn their cognitive load to solve problems they couldn’t solve before.”
— Cornelia Davis
This maps onto a principle that has become central to platform engineering: a good internal developer platform should eliminate accidental complexity so that teams can focus on essential complexity — the hard problems unique to their domain.
Key Takeaways for DevOps Engineers
- Distributed systems are the default now. Cloud-native development means nearly every engineer is implicitly working in a distributed context, whether or not they think of themselves that way.
- Declarative configuration is the infrastructure equivalent of functional programming. Both approaches prioritise expressing desired state over scripting procedural steps, and both reduce a class of subtle, order-dependent bugs.
- Conway’s Law applies to Kubernetes adoption. How you structure your platform team relative to application teams will shape — and be shaped by — how you use Kubernetes. This is a people and process problem, not just a technical one.
- Ecosystem momentum matters independently of technical merit. Kubernetes won partly on community gravity. Ignoring that dynamic is a strategic risk, as Pivotal’s own experience illustrated.
- The platform-team/app-team boundary is a solved problem for some, unsolved for many. Organisations adopting Kubernetes should define these roles explicitly rather than assuming they will emerge organically.
Cornelia Davis later joined Weaveworks as CTO. Pivotal was acquired by VMware in December 2019, and the Pivotal Application Service product line was subsequently integrated into the VMware Tanzu portfolio.