Ángel Barrera Sánchez, platform engineer at adidas, recently discussed how the adidas team evolved their platform configuration towards a GitOps-based setup. In a series of posts on the adidas engineering Medium account, Sánchez elaborated on the utilization of GitOps in their container platform and how they plan to introduce improvements in the management of their platform.
Adidas may not fit the mould of a startup or a tech organization, but it has technology implemented that enables various teams to work efficiently. The implementation extends from physical stores to their online platform and product design teams. With infrastructure extending from China through Singapore, across Europe, and reaching North and South America, adidas operates many ephemeral servers in the cloud, running containers around the clock to support global development teams.
When starting this journey, each container cluster had its dedicated repository with multiple branches. Each branch in these repositories had its pipeline for configuring the application. A shared configuration repository was maintained, featuring various branches to override configurations based on environmental or geographical factors.
Additionally, there were code repositories integrated with internal adidas systems. A central repository facilitated the creation of deployable packages for these internal developments. This approach had challenges, like updating a component that necessitated modifications across multiple repositories. This process ranged from four to potentially fifty repositories, each requiring separate change requests with their review and approval processes.
Adidas transitioned its strategy from a push mode, where one system pushes configuration to another, to a pull mode, where the system retrieves configuration from a configuration repository.k
With the global expansion of the container platform and the diverse internal clients operating in multiple execution environments, adidas embraced a layered approach. The initial layer encompasses settings applicable across all clusters, termed the Global configuration.
Subsequently, there's a layer specific to execution environments like Development, QA, or Production. Another layer pertains to geographical zones, addressing unique considerations such as data retrieval optimization in China due to slower image-pulling speeds from container repositories abroad. Finally, there's the cluster-specific configuration layer.
This structure provides flexibility for independently customizing details across four configuration layers. Changes can be implemented globally, per environment, per geographical region, or specifically to individual clusters, where cluster-specific configurations take precedence over geographical, environmental, and global settings.
By implementing the above approach, adidas could streamline platform cluster management. They implemented a set of alerts with a genuine impact on platform stability. Teams can now gain foresight into forthcoming platform changes through pre-execution dry-runs of configurations, providing deeper insights into potential alterations across different clusters.
Due to this transition, teams reduced the operational time by consolidating configurations into fewer repositories instead of dispersing them across multiple ones. This consolidation minimized the manual operations required to ensure the accuracy of application configurations on the platform. They can now scale the container platform without concern for cluster numbers, yet due to the volume, some manual tasks remain inevitable when establishing a new cluster.
Adidas’s approach to improving the container platform appears to resonate with what we saw during a presentation by Hazel Weakly at QCon San Francisco 2023. Weakly discussed that the initial focus on a platform often revolves around minimizing toil. This aspect, while not always the top priority for everyone else, stands out as a critical concern for Individual Contributors. However, to build an effective platform, it's essential to align the priorities of all stakeholders.
The adidas team has also introduced a mechanism to enable each cluster to autonomously schedule the application of new configurations within designated maintenance windows. Such mechanisms prove beneficial during critical adidas sales events, safeguarding against disruptions that could impact their business.
Finally, they've implemented automated change log generation directly within the configuration repository, essential for tracking the platform's evolution and understanding its historical changes.
The planned improvements in the management of the container platform include an Operations CLI to streamline operations from a centralized point. Ephemeral clusters are planned to enable automatic infrastructure deployment from within the cluster. The details of similar planned improvements are elaborated here.