My 2025 market wrap...
2025 is all but done... whilst you enjoy your break, have a read of my market summary of the year wrapped..
After a year of conversations with customers, community members, and operators across a wide range of environments, a few consistent themes kept surfacing.
The first is that home users and enterprises are no longer adjacent audiences with subtly different needs; they are fundamentally different users with different goals. Home users, including NAS users and those running home automation or personal services, want something deliberately simple and low-friction. As Portainer has evolved into a fleet-wide operations and governance platform, the gap has widened. Tools built for enterprise gravity inevitably become the wrong shape for personal or home use, and pretending otherwise helps no one.
At the same time, Kubernetes has crossed the adoption chasm. It is everywhere now, at least in name. Yet outside the early innovators and cloud natives, there is still a striking lack of understanding about what Kubernetes actually entails operationally. Many teams still treat it as a drop-in replacement for earlier platforms, underestimating the breadth of tooling required to run it reliably, securely, and with genuine high availability. Spinning up a cluster or two is the easy part. The operational envelope is where most organisations find themselves navigating unfamiliar territory.
Docker’s role in all of this continues to diminish. The engine still exists, but it now sits firmly in the category of legacy technology. The ecosystem has moved on, and the capability gap between Docker and Kubernetes is so wide that direct comparison no longer makes sense. For enterprises, Docker is no longer a viable platform choice; it is only a historical stepping stone.
Yet despite Kubernetes becoming mainstream, the cultural posture around it has not fully caught up. There remains a persistent strain of elitism, often from platform engineers who mistake complexity for capability. In trying to demonstrate technical sophistication, they push operational and cognitive load “left” onto internal users who neither want nor need it. The result is friction, shadow platforms, and a gradual erosion of trust. Platforms exist to absorb complexity, not to redistribute it.
This misunderstanding feeds directly into how Internal Developer Platforms are perceived. IDPs are still widely treated as a silver bullet, a way to compensate for a poorly designed Kubernetes foundation. When the underlying platform is fragile or over-engineered, wrapping it in portals and workflows does not fix the problem. It simply obscures it. Two wrongs do not make a right.
Meanwhile, the Kubernetes tooling ecosystem continues to fragment. Each new problem spawns a new tool, often excellent in isolation but rarely designed as part of a coherent whole. Planning a Kubernetes platform now means navigating an ever-expanding constellation of narrowly scoped solutions, each with its own lifecycle, pricing model, and operational overhead. Complexity and cost creep in quietly, one “small” addition at a time.
All of this is amplified by the state of the CNCF landscape itself. It keeps growing, but without meaningful consolidation, refinement, or deprecation. What was once a map is now closer to a catalogue, impressive in scale but increasingly unmanageable for anyone outside the inner circle. For newcomers and pragmatic operators, it is less a guide and more a source of hesitation.
Taken together, what we have seen in 2025 points to a single underlying theme. The industry is still optimising for technical possibility rather than operational reality. Until we design platforms around the people who actually have to run them, rather than those who enjoy building them, the gap between promise and practice will continue to widen. Lets see if 2026 is the year this change occurs.