The Kubernetes conversation peaked somewhere around 2021. Conference schedules were dominated by K8s migration stories, every infrastructure vendor rebranded themselves as "Kubernetes-native," and the implicit assumption was that any company not containerizing everything was falling behind. The hype was real, and it was loud.
Three years later, the noise has died down. What is left is not disappointment or disillusionment — it is a far more useful thing. It is actual production workloads running on clusters that real engineering teams built and now have to maintain. The K8s wave crested. The interesting investment questions are downstream of that.
What Enterprises Actually Did
Our portfolio gives us a decent read across a range of enterprise infrastructure deployments, and what we see does not match the conference narrative from a few years ago. The full-stack containerization story — every workload migrated, every service decomposed into microservices, everything orchestrated via K8s — is the exception. The typical enterprise K8s story looks more like this:
A handful of net-new applications were built cloud-native from the ground up. Those are running on Kubernetes, doing well, and the teams managing them have genuine expertise. Meanwhile, the legacy monoliths that actually generate revenue are still running on the same infrastructure they have always run on. Sometimes they sit alongside the K8s cluster. Sometimes they are behind a migration project that has been "in progress" for three years with no clear end date.
In our diligence across roughly 60 infrastructure companies over the past two years, we found that fewer than 20% of enterprise production workloads at large incumbents have actually completed migration to containerized environments. The ones that have are predominantly net-new applications, not lifted-and-shifted legacy systems. That gap is where the next round of opportunity lives.
The Drift Problem Is Real
Kubernetes clusters drift. Configuration changes, resource limits get adjusted, policies get modified by different teams at different times, and over time the actual running state of the cluster diverges from whatever the declared configuration says it should be. For companies with small platform engineering teams relative to cluster size, this drift is a genuine operational problem — not a theoretical one.
We backed Driftware specifically because their team had lived this problem firsthand. The founding pair came out of platform engineering at two separate financial services firms, independently hit the same wall — production clusters in a state that did not match what any documentation said they should be in — and built tooling to fix it. Their approach to automated drift detection and remediation in Kubernetes environments addresses something that the core K8s tooling does not solve, and the adoption curve in their early customer base has been steep.
Importantly, Driftware is not solving a Kubernetes problem in the abstract. They are solving a problem that only exists because enterprises got far enough into K8s deployment to accumulate real operational debt. That is only possible because the early K8s wave actually happened and created clusters that now need managing.
Where the Opportunity Sits Now
The investment opportunities that the Kubernetes maturation cycle has created fall into a few categories:
Operational tooling for running clusters in production. The teams that built clusters are not the same teams that have to maintain them years later. Observability, cost management, drift detection, policy enforcement — these are products that did not have obvious buyers three years ago because the clusters were still new. Now they do.
Migration tooling for the workloads that were not moved. The 80% of legacy enterprise workloads that are still running on traditional infrastructure will not stay there forever. The firms building credible paths for those workloads to move — not just lift-and-shift container wrappers, but genuine replatforming tooling with safety rails — are addressing a large, under-served market.
Multi-cloud orchestration above the K8s layer. Enterprises running Kubernetes across multiple environments — different cloud providers, on-premise alongside cloud, different managed K8s services — need something that sits above the individual cluster and provides unified control. This is the market Tectrix is building for. The problem was not obvious when companies had one cluster; it is very obvious when they have forty.
The Platform Engineering Talent Gap
One thing that does not get discussed enough in the Kubernetes conversation: the talent gap in platform engineering. Companies that committed to K8s in 2019-2021 hired aggressively for the build phase. The engineers who built the initial clusters have often moved on. What remains is a cluster in production, a smaller platform team, and a pile of operational complexity that requires expertise to manage safely.
This talent constraint is not a Kubernetes criticism — it is a market reality that creates durable demand for tooling that reduces the expertise required to operate clusters reliably. Products that abstract away cluster complexity, automate the repetitive operational tasks, and provide guardrails that prevent well-intentioned engineers from making catastrophic changes — those products have a buyer at almost every enterprise we talk to.
The K8s wave is over. The companies that rode it are now sitting on infrastructure that needs managing, migrating, and in some cases, rationalizing. That is not a problem. That is a market.
