From Platform Sprawl to Producer-Consumer: Lessons from Veeam’s Day Two Reality
- Daniel Bryant
- Apr 20
- 5 min read
At KubeCon, Cat Morris from Syntasso and Nitish Malhotra from Veeam Software shared a platform engineering journey that will feel familiar to many teams. Unlike the more common story of slow starts and low adoption, Veeam’s platform delivered early success. It improved speed, removed bottlenecks, and made infrastructure provisioning significantly easier.
And yet, despite that strong start, the team still hit the “day two hangover”; the point where a platform becomes harder to manage, harder to scale, and begins to drift away from its original promise. As part of the fix, Veeam incorporated tools such as Kratix to standardise how platform capabilities were defined and delivered via APIs and workflows.
What makes this story particularly valuable is that it doesn’t stand alone. Alongside Nitish’s experience, Cat shared a very different journey that ended in the same place. Together, their stories show that whether you start fast or slow, the real challenge in platform engineering begins after day one.
A Strong Start: Solving the Bottleneck in Software Delivery
Before adopting platform engineering, Veeam’s infrastructure team operated in a familiar model. Application teams relied on a small group of engineers to provision and manage infrastructure, creating friction and long lead times.
The move to platform engineering was intended to change that. The team began extracting reusable patterns from their work and turning them into modular infrastructure components. This created a catalogue that allowed engineers to assemble infrastructure quickly and consistently.
The results were immediate. Lead times dropped, consistency improved, and the infrastructure team was no longer a bottleneck. From a leadership perspective, this looked like a clear success.
This stands in stark contrast to Cat’s earlier experience, where a platform was built over six months in isolation, only to see minimal adoption. In that case, the platform never reached the point of delivering value at scale. At Veeam, the platform did deliver value, but that success introduced a different set of challenges.
When Platform Success Becomes Sprawl
As adoption at Veeam grew, so did the number of components in the catalogue. What started as a clean, reusable system began to fragment. Small variations were introduced to meet slightly different needs, and over time, these variations multiplied.
Instead of a shared, standardised platform, the system evolved into a collection of near-duplicate components. Visibility decreased, consistency broke down, and the original benefits began to erode.
This is a critical moment in many platform journeys. Early success can hide underlying issues, and without strong guardrails, growth can quickly turn into sprawl.
Cat’s story highlights the same problem from the opposite direction. In her case, the platform was so slow to evolve that teams built their own alternatives before it even launched. At Veeam, the platform evolved too quickly and without enough control. In both cases, the platform failed to stay aligned with user needs over time.
The Hidden Problem: Who Is the Platform For?
One of the most important insights from Nitish’s experience is that the platform was not truly designed for its end users. Although it improved efficiency for infrastructure engineers, it did not fully account for the needs of developers, SREs, or other stakeholders.
Developers needed simple, self-service ways to request and manage infrastructure within their workflows. Operations teams needed better support for debugging and on-call scenarios. Security and compliance teams needed consistent mechanisms to enforce and audit policies.
Instead, the platform was optimised for the people building it; it was not treated as a product for its users.
What Day Two Really Requires
Both stories point to a shift in mindset that platform teams need to make. Platforms are not static systems that can be built and handed over. They require continuous iteration, feedback, and intentional design. Without this, even well-engineered platforms will drift, either due to low adoption or uncontrolled growth.
At Veeam, this meant recognising the need for stronger standardisation and governance. Reusable components only provide value if they remain consistent. Allowing too much flexibility leads to duplication and complexity.
It also meant thinking beyond provisioning. A platform must support the full lifecycle, including observability, operations, and ongoing management. Without this, teams struggle when things go wrong, and confidence in the platform declines.
Regaining Control Without Slowing Down
To address these challenges, Nitish outlined a set of practices that help bring platforms back under control while preserving the benefits of speed.
GitOps plays a key role by establishing a clear source of truth and making it easier to track and manage changes. This helps reduce drift and improve visibility across the platform.
Standardising platform capabilities is equally important. Core elements such as clusters, databases, and pipelines should have well-defined specifications and guardrails. This reduces variation and ensures consistency as the platform scales.
These capabilities should then be exposed through APIs and workflows that make them easy to consume. Rather than interacting with underlying complexity, users can request what they need through a consistent interface.
As Nitish explained, “We use a tool called Kratix… it makes the whole API workflow thing a breeze because it’s all Kubernetes CRDs at the end of the day.” This kind of approach helps standardise how capabilities are delivered while keeping the developer experience simple.
Self-service is central to this model. Developers should be able to provision and manage resources independently, while still operating within the boundaries defined by the platform.
Finally, observability needs to be built in from the start. Platforms must provide visibility into both applications and infrastructure so that teams can understand and debug their systems effectively.
Scaling the Platform Beyond the Platform Team
A key lesson that connects both Cat’s and Nitish’s experiences is that platform teams cannot and should not build everything themselves.
As platforms grow, it becomes essential to involve other teams as contributors. Domain experts in areas like databases, security, and networking can provide capabilities that the platform team alone would struggle to deliver and maintain.
This shifts the platform team's role. Instead of being the sole builders, they become facilitators who enable others to contribute safely and effectively. They provide the standards, tooling, and experience that make this possible.
Cat framed this as a producer-consumer model, in which the platform enables a broader ecosystem of contributors while maintaining a consistent user experience. This approach not only scales the platform but also increases its value and adoption across the organisation.
Final Takeaway
Veeam’s journey shows that early success in platform engineering is only the beginning. Without careful attention to scale, governance, and user needs, that success can quickly turn into complexity.
Cat’s experience reinforces the same lesson from another angle. Whether you build too slowly or scale too quickly, the outcome is similar if you are not continuously aligned with your users.
The day two hangover is not a failure. It is a signal that the platform needs to evolve.
The teams that succeed are the ones that treat their platform as a product, design for multiple personas, and create systems that can grow beyond the team that started them.
Comments