From Hours To Minutes: The Evolution of Platform Engineerin... Adrien Gillard & Christophe Furmaniak

From Hours To Minutes: The Evolution of Platform Engineering at Decathlon

Speakers: Adrien Gillard, Christophe Furmaniak

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=UVPe-rdxK7w

Overview

Adrien Gillard and Christophe Furmaniak from Decathlon presented an insightful talk at KubeCon EU, detailing the sports retailer's extensive journey in platform engineering. The presentation, titled "From Hours To Minutes," chronicles Decathlon's evolution from a highly decentralized organizational structure to a sophisticated, product-centric platform approach designed to streamline infrastructure provisioning and enhance developer experience. This transformation was driven by the need to support a vast ecosystem of 5,000 digital teammates, highlighting the critical role of a well-architected platform in achieving operational efficiency and fostering innovation at scale.

The core narrative revolves around Decathlon's iterative development of its platform, starting with an initial platform orchestrator called 3S (Self-Service Stack), then attempting a more advanced iteration with SRP (Single Region Product) and MRP (Multi-Region Product), and ultimately deciding to revert and refine the original 3S engine. This journey underscores the complexities inherent in building internal developer platforms, emphasizing the importance of user feedback, adaptability, and a pragmatic approach to technical debt and organizational change. The speakers openly shared both their successes and the significant challenges encountered, providing valuable lessons for any organization embarking on or refining its platform engineering strategy.

The talk is particularly relevant for organizations struggling with infrastructure sprawl, slow provisioning times, and a lack of standardization across development teams. Decathlon's experience demonstrates how a dedicated platform engineering team can abstract away underlying infrastructure complexities, allowing developers to focus on delivering business value rather than managing intricate cloud resources. It also highlights the strategic value of a developer portal as a critical interface for platform adoption and user engagement, a lesson learned and now being actively refined in their ongoing efforts.

Background

▶ Watch: Decathlon's initial "liberation" era challenges (2:00)

Decathlon, recognized as the world's largest sports goods retailer, operates with a substantial digital footprint, supported by approximately 5,000 digital teammates. Several years ago, the organization's digital entity was characterized by a highly decentralized model. Large domains operated with significant autonomy, each possessing its own independent operations (ops) and development (dev) teams. The prevailing motto at the time was "liberation," which championed the freedom for teams to pursue projects and create value as they saw fit, leading to a proliferation of innovative initiatives.

While this liberation fostered creativity, it also introduced significant inefficiencies and drawbacks. A prime example cited by the speakers was an internal audit revealing the use of more than 20 distinct observability tools across the digital landscape. This fragmentation led to widespread reinvention of the wheel, where each domain developed its own methods for consuming fundamental infrastructure building blocks, such as public cloud envelopes, network addressing plans, and various service providers. Furthermore, the lack of standardization created excessive room for interpretation in implementing operating models and applying crucial security practices, posing significant risks and operational overhead. Developers, in this decentralized environment, were often disconnected from the underlying infrastructure building process, leading to a disconnect between application needs and infrastructure capabilities.

To address these challenges, Decathlon initiated two key strategic efforts. First, they introduced a robust tech governance framework, loosely based on the CNCF (Cloud Native Computing Foundation) and Kubernetes models, featuring a technical oversight committee (TOC) and special interest groups (SIGs). This provided a much-needed structure for technical decision-making across the large organization. Second, and central to the talk, was the ambition to provide a standardized, streamlined method for provisioning and utilizing infrastructure. This led to the formation of a Cloud Platform Engineering (CPE) entity, which became responsible for managing core infrastructure components like networking, compute, and storage, with the goal of building a unified platform for all digital users.

The foundational work on their "golden path" began in the last quarter of 2020. Initially, the focus was not on a dedicated developer portal but rather on establishing a platform engine. This early team comprised primarily ops-focused individuals, viewing the platform orchestrator as an opportunity to standardize operations rather than an explicit choice. The concept of a platform orchestrator, as a distinct entity, gained broader recognition later, being explicitly mentioned in Volume 29 of the Salt Works TechRadar in September 2023. This background sets the stage for Decathlon's iterative journey, marked by both strategic successes and significant learning experiences in their pursuit of an efficient and developer-friendly infrastructure platform.

Key Findings

▶ Watch: Core problems the platform engine aimed to solve (4:30)

Decathlon's journey through platform engineering yielded a series of crucial findings, evolving from the initial successes and limitations of their first platform iteration to the complex challenges of its successor, culminating in a strategic pivot.

The initial platform engine, named 3S (Self-Service Stack), was designed to streamline infrastructure provisioning by providing an abstraction layer accessible to both developers and operations teams. A key finding was its ability to enable collaboration without requiring specialized infrastructure development skills from users. The 3S engine was "all-inclusive," bundling observability, security, credential management, IAM policies, and firewall rules directly into the provisioning process. It embraced Infrastructure as Code (IaC) principles, allowing users to describe desired infrastructure through YAML descriptors and manage changes via GitOps workflows using pull requests. Under the hood, Terraform was used to provision GCP projects and associated services. The adoption of 3S was notably successful in domains that did not require connectivity to Decathlon's internal private network, and it garnered positive feedback from developers for its ease of use. The core team for 3S comprised 15 individuals, with over 50 contributors from various domains, demonstrating a strong internal collaborative effort and the enforcement of high-quality standards.

However, the 3S engine also revealed significant limitations. The most critical was its inability to provide internal network connectivity, restricting its use cases. Performance issues arose due to the architecture of running everything within a single Terraform execution. The contribution process, while fostering collaboration, presented a high initial barrier for some users unfamiliar with the enforced quality standards and the broad underlying technology stack. Furthermore, release management proved challenging, largely due to the high number of complex functional tests required for the rich service catalog, which were difficult to automate effectively.

Recognizing these limitations by early 2024, Decathlon set three main objectives for the next iteration: enhance product focus to increase adoption and improve user interaction, significantly improve the developer experience beyond YAML-based infrastructure descriptions for non-infrastructure specialists, and crucially, address the internal connectivity problem. This led to a three-product strategy: SRP (Single Region Product), MRP (Multi-Region Product), and an Internal Developer Portal (IDP). SRP and MRP were re-architected versions of 3S, with MRP specifically designed for multi-region deployments. A major finding was the complete overhaul of the network for SRP and MRP, introducing new addressing plans, subnetting, and VPNs to facilitate internal network access. This was enabled by an in-house component called Platform Score (PFC), a Terraform provider and API that allowed autonomous provisioning of network and security resources, bypassing the previous reliance on manual support requests to the network team. Additional in-house APIs for provisioning and secret management further streamlined product consumption.

Despite the technical advancements, SRP and MRP faced considerable challenges. A significant finding was the "dependency hell" experienced by the PFC team, as all other components became dependent on the network changes, leading to an overwhelming influx of bug reports and feature requests. More critically, Decathlon discovered that a seamless migration from 3S to SRP/MRP was impossible due to the extensive network changes. This meant existing 3S users would have to undertake a costly, "start from scratch" migration of data and workloads. For potential new users, while internal network access was a benefit, the overall value proposition of SRP/MRP was not perceived as a "game changer" compared to 3S or direct Terraform usage, leading to continued skepticism.

These challenges forced a strategic re-evaluation in December 2024. Considering two main decision drivers—maximizing platform orchestrator usage and minimizing development costs—Decathlon made the pragmatic choice to revert to the 3S engine. This decision, while acknowledging the persistent weakness of no internal network connectivity, offered several strengths: a return to familiar ground, an opportunity to tackle accumulated technical debt, and the ability to backport valuable features developed for SRP/MRP into 3S, enhancing its capabilities. The ongoing challenge remains to identify solutions for users whose requirements cannot be met by 3S, covering its "blind spots." This iterative process of building, learning, and adapting is a central finding of Decathlon's platform engineering journey.

Technical Deep Dive

▶ Watch: Introducing 3S: the self-service stack engine (6:05)

Decathlon's platform engineering journey is deeply rooted in the technical evolution of its infrastructure provisioning capabilities, centered around the 3S (Self-Service Stack) engine and its subsequent iterations.

The initial 3S engine, launched in late 2020, was conceived as a platform orchestrator to standardize infrastructure provisioning across Decathlon's 5,000 digital teammates. At its core, 3S embraced Infrastructure as Code (IaC) principles. Users defined their desired infrastructure using YAML descriptors, which allowed for a declarative approach to resource management. This codified infrastructure was then managed through a GitOps workflow, where changes were proposed via pull requests, enabling collaboration, version control, and peer review.

Under the hood, 3S leveraged Terraform as its primary execution engine. When a pull request was merged, Terraform would automatically provision and manage resources, primarily creating GCP projects and all necessary associated services. A key technical feature of 3S was its "all-inclusive" nature, meaning that essential components like observability, security configurations, credential management, IAM policies, and firewall rules were automatically provided and configured as part of the stack. This dramatically simplified the developer experience, abstracting away complex infrastructure details and ensuring adherence to corporate standards without requiring specialized infrastructure development skills from the users. However, a significant technical limitation of 3S was its reliance on a single Terraform run for provisioning, which eventually led to performance issues as the complexity and scale of deployments grew. Furthermore, 3S was architected as an isolated environment, only allowing public internet exposure, with no direct connectivity to Decathlon's internal private network.

By early 2024, to address the critical lack of internal network connectivity and enhance the developer experience, Decathlon embarked on developing SRP (Single Region Product) and MRP (Multi-Region Product). These new offerings represented a significant technical overhaul of the 3S concept. The most substantial change was a complete re-architecture of the network layer. This involved implementing a new addressing plan, sophisticated subnetting strategies, and establishing VPNs to facilitate secure and efficient connectivity with Decathlon's internal network.

Central to this network overhaul was the introduction of an in-house component called Platform Score (PFC). PFC was designed as both a Terraform provider and an API. The PFC API was a critical innovation, allowing the platform team to autonomously provision a wide range of network and security resources. Before PFC, such provisioning often required submitting support requests to a centralized network team, leading to delays. With PFC, security, compliance, and architectural standards were built directly into the API, enabling on-demand and self-service provisioning of network components that were previously considered "heavy" and complex to manage. This represented a significant cultural and technical shift towards greater autonomy for the platform engineering team.

Beyond PFC, Decathlon also introduced other in-house APIs, including a dedicated provisioning API and a secret management API. These APIs collectively streamlined the entire lifecycle of product consumption, from initial provisioning requests to the actual deployment of workloads, further abstracting underlying complexities and standardizing interactions with the platform. This development of multiple in-house APIs marked a notable cultural change within Decathlon's engineering practices, moving towards a more API-driven internal platform.

Despite these technical advancements, the SRP/MRP iteration faced its own set of technical hurdles. The tight coupling of components with the new network architecture introduced a form of "dependency hell," particularly for the PFC team. Every other platform component became dependent on PFC for network functionality, leading to an intense period of bug fixing and feature development. Crucially, the extensive changes to the network architecture rendered a seamless migration path from the original 3S to SRP/MRP technically impossible. This meant existing users would face a daunting task of re-architecting and re-deploying their applications from scratch, a significant technical burden.

Ultimately, Decathlon's decision to revert and refactor the original 3S engine was a pragmatic response to these technical and user experience challenges. This pivot allowed them to tackle accumulated technical debt within the 4-year-old 3S codebase and to backport valuable features developed during the SRP/MRP phase into the more stable and familiar 3S environment. This ongoing work aims to refine the link between the 3S platform orchestrator and the nascent internal developer portal (IDP), recognizing the IDP as a crucial interface for driving adoption and providing a superior user experience, especially for developers who are not infrastructure specialists.

Demo / Proof of Concept

▶ Watch: Limitations and challenges of the initial 3S version (8:00)

The presentation by Adrien Gillard and Christophe Furmaniak from Decathlon primarily focused on sharing the architectural evolution, strategic decisions, and lessons learned from their multi-year journey in platform engineering. The talk delivered a comprehensive narrative of their internal platform development, including the design, implementation, and challenges of the 3S engine, SRP/MRP, and associated components like Platform Score.

While the speakers described the functionality and impact of their various platform iterations and components in detail, the presentation did not include a live demonstration or a recorded proof of concept of the 3S (Self-Service Stack), Platform Score (PFC), or any other specific technical aspect of their platform. The emphasis was on the strategic and organizational aspects of building a platform engineering capability within a large enterprise, rather than showcasing a real-time interaction with the tools or systems discussed.

Defensive Implications

▶ Watch: Future objectives: product focus, DX, internal connectivity (9:30)

While the talk "From Hours To Minutes" is primarily about platform engineering and improving developer efficiency, it inherently touches upon crucial defensive implications by standardizing and automating infrastructure provisioning. Decathlon's journey demonstrates how a well-designed platform can significantly enhance an organization's security posture by embedding defensive controls directly into the infrastructure delivery pipeline.

One of the most significant defensive implications is the shift from a decentralized "liberation" model, which led to over 20 disparate observability tools and varied security practices, to a standardized platform approach. This standardization reduces the attack surface by eliminating inconsistent configurations, unmanaged shadow IT, and the "reinvention of the wheel" that often introduces vulnerabilities. By consolidating tools and enforcing common operating models and security practices, Decathlon can achieve a more uniform and defensible infrastructure landscape.

The 3S (Self-Service Stack) engine, and its subsequent iterations, inherently promote security by design. The platform is "all-inclusive," meaning security configurations, credential management, IAM policies, and firewall rules are automatically provided and enforced. This prevents developers from inadvertently deploying insecure configurations by abstracting away the complexity of security primitives and embedding corporate security standards directly into the platform's provisioning logic. This approach ensures that baseline security requirements are met for every deployed resource, significantly reducing the risk of misconfigurations, which are a leading cause of breaches.

The introduction of Infrastructure as Code (IaC) via YAML descriptors and GitOps workflows for managing infrastructure has strong defensive benefits. All infrastructure definitions, including security rules, are version-controlled, auditable, and subject to peer review through pull requests. This provides a clear trail of changes, facilitates automated security checks (e.g., static analysis of Terraform code), and allows security teams to review proposed infrastructure changes before they are deployed to production. This proactive approach helps catch security flaws early in the development lifecycle rather than after deployment.

The Platform Score (PFC) component, developed in-house, represents a critical defensive advancement. As a Terraform provider and API, PFC enables the autonomous provisioning of network and security resources. This means that the platform engineering team can enforce security, compliance, and architectural standards directly through the API, rather than relying on manual processes or support tickets to a separate network team. This automation ensures consistency in network segmentation, VPN configurations, and other security-critical network settings, reducing human error and accelerating the deployment of secure network topologies. The built-in compliance within the PFC API means that security guardrails are automatically applied, freeing security teams from manual validation and allowing them to focus on higher-level threat intelligence and policy refinement.

Finally, the overarching goal of Decathlon's platform engineering effort is to "absorb complexity" from developers, allowing them to focus on business value. This complexity absorption extends to security. By providing secure defaults, automated guardrails, and standardized components, the platform reduces the cognitive load on developers regarding security, enabling them to build applications more securely without needing deep expertise in infrastructure security. This approach creates a more secure development environment by default, fostering a culture where security is an inherent part of the platform, not an afterthought. The continuous learning and adaptation emphasized by Decathlon also suggest an ongoing process of refining these defensive capabilities in response to new threats and evolving organizational needs.

Key Takeaways

Decathlon's extensive journey in platform engineering, from its decentralized roots to its iterative platform development, offers several crucial lessons for organizations building internal developer platforms:

• Prioritize Robust Delivery Management: Implementing a structured delivery management process, including quarterly planning and clear roadmaps, is essential. It smooths workloads, alleviates stress on teams, and ensures alignment across complex dependencies, making the platform development process more predictable and efficient.
• Embrace Flexibility and Adaptability: In the rapidly evolving tech landscape, it's vital to stay flexible, learn from failures, and adapt quickly. Decathlon's experience of trying different platform approaches, failing, and pivoting back to refine a proven solution underscores the value of knowing when to accelerate and when to step back and re-evaluate.
• Platform Engineers Serve Their Users: The core mission of platform engineering is to make developers' jobs easier by absorbing complexity and difficulties, allowing them to focus on business value. A key mistake is to offload complexity onto users, such as expecting seamless migrations that require significant effort from their side. The platform should simplify, not complicate.
• Acknowledge and Manage Resistance to Change: Resistance to change is an inevitable human factor in any organizational transformation. Recognizing this early allows platform teams to proactively strategize and deal with it more effectively, fostering smoother adoption and mitigating potential roadblocks.
• Align Platform Goals with Organizational Maturity: The design and evolution of the platform must be aligned with the current maturity level of the organization and its users. Building a platform orchestrator (the "backenders" approach) is a common starting point, and its subsequent refinement should continuously involve and cater to the needs of the target users.
• Developer Experience (DX) is Paramount: While technical capabilities are crucial, the user experience for developers is a primary driver of platform adoption. The shift towards an Internal Developer Portal (IDP) and moving beyond basic YAML for non-infrastructure specialists highlights the importance of making the platform intuitive and enjoyable to use.

About the Speaker(s)

Adrien Gillard and Christophe Furmaniak are key figures in Decathlon's digital transformation, specifically within their platform engineering initiatives. As members of Decathlon's team, they have been deeply involved in shaping the company's approach to infrastructure provisioning and developer experience. Their presentation at KubeCon EU provided an honest and detailed account of Decathlon's journey, sharing the successes, challenges, and strategic pivots experienced over several years. Their insights are drawn from hands-on experience in designing, implementing, and iterating on platforms like 3S (Self-Service Stack) and Platform Score (PFC), demonstrating their expertise in cloud infrastructure, Infrastructure as Code (IaC), and fostering a product-centric mindset in platform development. Their talk reflects a deep understanding of the complexities involved in scaling digital operations for a global retailer with 5,000 digital teammates.