Eugenia Bergman and Hagen Tonnies offered how they shifted from project- to product-thinking after their platform outgrew single-team use at KubeCon & CloudNativeCon Europe. The restrictions that they felt with their platform have been one-off deliveries, lack of product imaginative and prescient, and weak suggestions loops. They’ve moved towards a self-service, API-driven, multi-tenant infrastructure with clearer possession and higher abstractions.
Bergman talked about that their platform growth cycle was organized round yearly venture planning. Work sometimes began with upfront scoping, funds allocation, and outlined supply milestones. Every initiative was handled as a venture with a transparent begin and finish, and success was measured by whether or not they delivered on scope, time, and milestones:
This labored properly when the platform supported a single service to the organisation that delivered the Recreation Streaming product. Over time, our platform developed to help a number of inside groups with totally different wants. That essentially modified the character of the system.
Bergman talked about a number of limitations that they felt with their platform:
- Every enchancment was handled as a one-off supply
- This resulted in amassed capabilities that have been competing in precedence with the subsequent supply merchandise
- The platform had no clear product definition
They have been constantly delivering, however not at all times enhancing the usability or coherence of the platform as a complete, Bergman stated. Suggestions loops have been primarily inside, centered on dash efficiency (velocity, completion, high quality), with little to no validation from precise platform customers. The system optimized for completion moderately than for long-term worth.
Impressed by a mixture of exterior affect and inside reflection, they shifted from a venture to a product method, Tonnies defined:
We had early friends introducing programs considering and product considering—drawing from ecosystems like Prometheus and Grafana—and internally we began participating with materials like Undertaking to Product and The Phoenix Undertaking, the place we acknowledged lots of our personal ache factors.
This led to a small group of follow amongst architects and senior engineers, the place they debated these concepts and explored options to our present mannequin, Tonnies stated.
Over time, their developer platform has developed considerably. It was by no means a single, unified platform however moderately a set of capabilities that grew organically round Kubernetes and GitOps practices, Tonnies defined:
Early on, the platform centered round Helm-based deployments, namespace-scoped assets, and a GitLab-driven workflow, the place groups onboarded by an inside IDP mannequin and operated largely inside shared clusters. This labored properly for standardizing utility supply, but it surely was primarily optimized for single-service groups and didn’t absolutely tackle broader multi-tenancy or extra complicated infrastructure wants.
As their ecosystem expanded, particularly with the introduction of public cloud companies like AWS, they noticed a pure shift in expectations, the place groups grew to become extra accustomed to self-service infrastructure and clearer possession fashions. This highlighted alternatives for them to enhance the inner platform expertise, significantly in abstraction, documentation, and in enabling a stronger separation of issues between platform and client obligations, Tonnies defined:
We’ve been evolving towards a extra product-oriented platform mannequin, with clearer tenancy boundaries, improved self-service capabilities, and better-defined interfaces for provisioning and managing infrastructure.
Right now, they’re investing in higher-level abstractions, resembling setting and venture constructs, and API-driven workflows that align extra intently with cloud service supplier paradigms. That is an ongoing journey, however the route is evident: shifting towards a extra scalable, user-centric, and decoupled platform that empowers groups whereas sustaining consistency and governance throughout the group, Tonnies concluded.
InfoQ interviewed Eugenia Bergman and Hagen Tonnies about altering to a product method for his or her platform.
InfoQ: What impressed you to alter from a venture to a product method?
Eugenia Bergman: The shift was not pushed by a single resolution, however by a set of alerts we may not ignore. We noticed that:
- Backlogs stored rising regardless of steady supply
- Groups have been working across the platform as a substitute of utilizing it
- We couldn’t clearly reply whether or not what we constructed was truly getting used
- We couldn’t at all times reply whether or not we supported sure capabilities or whether or not they have been even a part of our platform providing
On the similar time, we realized that we have been not simply delivering infrastructure, however as a substitute we have been offering capabilities to inside clients. That required a distinct method:
- From delivering options → to fixing consumer issues
- From fastened scope → to hypothesis-driven roadmaps
- From output metrics → to adoption and value alerts
In that sense, the transfer to a product method was much less a change initiative and extra a needed adaptation to scale.
Hagen Tonnies: The shift additionally got here from long-standing skepticism towards Scrum. Whereas I valued its construction, it typically didn’t seize actual outcomes or create the appropriate setting for groups. Product considering felt like a path towards higher alignment between engineering work, consumer worth, and workforce expertise.
InfoQ: How does your developer platform look?
Bergman: At a excessive stage, our developer platform behaves like an inside cloud supplier.
It exposes infrastructure capabilities resembling Kubernetes clusters, storage, networking, and supporting platform companies. These capabilities are made obtainable by self-service interfaces, primarily utilizing Kubernetes-native patterns resembling APIs and customized assets.
From a developer’s perspective, the aim is to:
- provision infrastructure as code
- combine platform capabilities straight into workflows
- and keep away from guide coordination or ticket-based processes
Internally, the platform is structured round a separation of issues between service, management, and administration planes, with composable constructing blocks that summary underlying infrastructure, and contracts that outline steady interfaces between layers.