Practice & Reference · Case File · adidas & Zalando

Case File: adidas & Zalando

Two European retailers, two separate platform teams, one shared problem: hundreds of developer teams needed cloud infrastructure, and no ticket queue in the world scales to serve them all — especially not in the six weeks a year when traffic multiplies and nothing is allowed to break. adidas and Zalando are both real, named companies who have told this story themselves — on their engineering blogs, at KubeCon, and in published case studies with Kubernetes.io and the CNCF. This file sticks to what they’ve actually said in public.

The starting situation: two versions of the same bottleneck

☺ Like you’re 10: Before the vending machine, everyone had to ask one busy person for everything — and that person became the traffic jam.

adidas: a form, a cost center, and a week of waiting

In its published case study with Kubernetes.io, adidas describes the pre-platform world in blunt terms: getting a developer a virtual machine meant submitting a request form with project details and cost-center information, and turnaround ran anywhere from 30 minutes in the best case to a full week in the worst. Engineers had access to plenty of infrastructure — they just couldn’t get to it quickly, and every request routed through people, not APIs. One adidas engineer described the feeling, in the same case study, as being "like an artist with your hands tied behind your back."

Zalando: from a PHP monolith to 200-plus isolated AWS accounts

Zalando's version of the same problem arrived from the opposite direction. Founded in 2008 and growing from roughly 180 employees in 2010 to more than 14,000 by 2016, Zalando's original PHP e-commerce platform stopped scaling with the business long before the company did. The first fix — moving off on-premises data centers onto AWS, with each of 200-plus autonomous engineering teams given its own AWS account for genuine isolation — solved the monolith problem but created a new one, as Zalando's own Kubernetes.io case study explains: CloudFormation and infrastructure overhead turned the central operations team into the new bottleneck, EC2 instances were slow to spin up, and compliance violations had to be found and fixed after the fact rather than prevented at admission time. Two different roads, one destination: a central team standing between hundreds of developers and the infrastructure they needed.

Why retail-scale seasonal traffic raises the stakes

☺ Like you’re 10: A school cafeteria can wing it on a normal day. On the one day the whole school shows up at once, winging it isn't good enough — you need a real plan.

Retail e-commerce has a traffic shape almost no other industry deals with quite the same way: months of comparatively steady load, followed by a handful of days — Black Friday, Cyber Monday, the run-up to Christmas — where demand multiplies and a single hour of downtime is measured in lost revenue and press coverage. That shape is exactly why "self-service" can't just mean "fast for developers on a quiet Tuesday." It has to mean a platform whose capacity, observability, and safety rails hold up when load itself becomes the adversary.

adidas's Cyber Week fire drill

adidas's own account, told at KubeCon by platform engineer Daniel Eichten and recorded in the CNCF case study, is refreshingly honest about a near-miss: during Cyber Week, the custom metrics adidas's e-commerce team needed filled up their Prometheus database faster than expected, and the existing retention period wasn't built for that spike. Rather than ride it out, five platform engineers and five e-commerce engineers built a federated Prometheus solution together — during the change freeze, in two days — and adidas's e-commerce site held 100% uptime through the peak week. It's a useful detail precisely because it isn't a triumphant "we planned everything perfectly" story; it's a "our monitoring nearly became the outage, and cross-team platform muscle fixed it under pressure" story.

Zalando's Cyber Week, by the numbers

Zalando's engineering blog is the more data-rich of the two on this specific point. A 2020 post, "How Zalando prepares for Cyber Week," and a 2019 post on end-to-end load testing put real numbers on the peak: Zalando's peak orders-per-minute grew from roughly 4,200 in 2018 to about 7,200 in 2019 — a 71% year-over-year jump — with 2019's Cyber Week bringing in 840,000 new customers and 32% higher sales than the year before, across more than 1,100 applications that needed to be individually prepared. Zalando treats Cyber Week as a standing engineering program, not a one-off scramble: distributed tracing (built on OpenTracing) to spot latency and error-rate problems fast, synthetic load tests that place real, clearly-tagged test orders through actual production user journeys rather than relying on theoretical capacity math, and a live "Situation Room" staffed by SRE and incident commanders for the event itself. The on-call org grew right along with the traffic — from two dedicated on-call teams in Zalando's early cloud-native days to roughly 100 teams carrying pagers by the time of these posts.

Architecture: buy the boring layer, build the differentiated one

☺ Like you’re 10: Neither factory built its own electricity plant. They bought power from the grid and spent their engineers on better toys instead.

adidas + Giant Swarm: outsourcing "boring" Kubernetes

adidas made an explicit build-versus-buy call, and its platform team was candid about the reasoning in the Kubernetes.io case study: running a Kubernetes cluster well is table stakes, not a competitive advantage. As the case study puts it, there's no edge over a competitor like Puma or Nike in operating a cluster — the edge is in how fast and resilient the e-commerce experience built on top of it is. So in early 2017 adidas brought in Giant Swarm to install, configure, and operate Kubernetes clusters across AWS and on-premises infrastructure, freeing the internal platform team to spend its effort on developer experience, CI/CD, and observability rather than kubelets and control-plane upgrades.

Zalando's Cluster Lifecycle Manager: provisioning as a product

Zalando went the opposite way on this particular decision and built its own cluster-provisioning system in-house, starting during a 2016 Hack Week pilot and formalized from January 2017 as the Cluster Lifecycle Manager (CLM). In the widely-cited engineering write-up on Zalando's cluster fleet (corroborated by Zalando's own open-source kubernetes-on-aws documentation and the cluster-lifecycle-manager repository on GitHub), clusters are provisioned in pairs — one production, one non-production — per business domain, each pinned to its own isolated AWS account and stood up from CloudFormation templates covering at minimum an etcd cluster, the main cluster, and master and worker node pools. A central, Postgres-backed Cluster Registry tracks every cluster's identity, environment, and configuration channel, and changes roll out gradually through dev → beta → stable channels with 35–59 minutes of automated end-to-end testing at each step before touching production. By the time that write-up was published, Zalando was running 140-plus clusters this way — up from roughly 40 in the platform's early days — without hand-tuned "pet" clusters anywhere in the fleet.

Neither choice is "more correct" than the other — it's the same lesson Argo CD vs. Flux teaches in GitOps Workflows: pick the shape that matches your team's appetite for owning infrastructure, and don't confuse "we run our own control plane" with "we're more serious about platform engineering." adidas decided cluster operations weren't worth owning; Zalando decided the opposite, and both decisions freed their platform teams to spend effort where developers actually felt it.

Self-service as the organizing principle

☺ Like you’re 10: The whole point of the vending machine is that nobody has to ask a person for a toy anymore — the machine is the answer, day or night.

This is the through-line the brief for this file is really asking about: why does self-service — a platform API a developer can call without a human in the loop — matter more, not less, once you're serving hundreds of teams? Because at adidas's and Zalando's scale, a single central team simply cannot be the approver for every request without becoming exactly the bottleneck both companies were trying to escape. The fix in both stories isn't "hire a bigger central team" — it's turning infrastructure into a self-service API and investing in the people who use it, which is precisely the territory covered in Self-Service & Developer Portals and Platform APIs, CRDs & Operators.

adidas: a 35-person platform team, and 50% of their time embedded

adidas's platform team — about 35 engineers, supporting roughly 300 engineers company-wide per the Kubernetes.io case study — didn't just ship a self-service API and walk away. Every engineer with code access went through a full week of platform onboarding, and the platform team reported spending roughly half its time embedded directly with product teams, both to build trust and to learn real usage patterns before automating around them. adidas even ran an internal "DevOps Cup" competition, drawing 600-plus attendees, to make platform adoption a cultural event rather than a mandate. The self-service API mattered, but the case study is just as insistent that the human onboarding around it is what made adoption stick.

Zalando: "you build it, you run it" for 200-plus teams

Zalando's model leans harder on team autonomy: in Henning Jacobs's words from the Kubernetes.io case study (Jacobs led developer productivity at Zalando), the platform team's job was to provide "Kubernetes as a Service" so that Zalando's delivery teams could run their own containerized applications on a shared, reliable cluster substrate — while keeping full 24/7 ownership and on-call responsibility for what they ship. A platform team that started at roughly seven people scaled that promise to 200-plus autonomous teams and 1,000-plus developers, precisely because the API — "here's how you get a namespace, a cluster, a database" — didn't require a person on the other end of every request.

Zalando's public open-source Kubernetes history

☺ Like you’re 10: Zalando didn't just use these tools quietly — they published their homework so other schools could copy it.

This is one place where Zalando's story is unusually well-documented, because the company open-sourced a meaningful slice of its own platform tooling rather than keeping it internal.

postgres-operator: teaching Kubernetes the word "Database"

In a June 2017 post on the Zalando Engineering Blog, "PostgreSQL in a time of Kubernetes," Zalando described building and open-sourcing its postgres-operator — a Kubernetes operator, powered by Patroni underneath, that manages the full lifecycle of PostgreSQL clusters as a custom resource. A developer writes a small CRD manifest for the Postgres cluster they want; the operator's reconcile loop handles provisioning, failover, and — with the operator's later metrics integration — attaches monitoring sidecars automatically. It's the same operator pattern taught in Platform APIs, CRDs & Operators, published years before "platform engineering" was a common industry term, and it remains one of the most widely adopted community Postgres operators today, packaged and referenced by third parties well beyond Zalando itself.

The rest of the toolbox: external-dns, and the fleet-management pattern

Alongside postgres-operator, Zalando's cluster-management write-ups and its own kubernetes-on-aws documentation reference a handful of other pieces it built or helped popularize for running many clusters as a fleet: external-dns for keeping DNS records in sync with ingress objects across every cluster, a Vertical Pod Autoscaler pattern for right-sizing system components like Prometheus as clusters grow, and multi-cluster observability tools such as kube-resource-report and kube-web-view for seeing across the whole 140-cluster estate rather than one cluster at a time. None of that is a single flashy donation — it's the unglamorous tooling that turns "we operate a lot of clusters" into something a team of a few dozen people can actually sustain, which is exactly the fleet-operations discipline covered in Scaling, Scheduling & Performance.

What changed — the outcomes, where they're public

☺ Like you’re 10: Did the vending machine actually work? Here's the report card, in the numbers both companies were willing to publish.

adidas: cadence, then cost

The headline numbers from adidas's Kubernetes.io case study: within six months of the project starting, 100% of adidas's e-commerce site ran on Kubernetes, release cadence moved from every four-to-six weeks to three-to-four times a day, e-commerce load times were cut roughly in half, and — as of the case study — 40% of adidas's most critical systems ran on the cloud-native platform, at a scale of about 4,000 pods, 200 nodes, and 80,000 builds a month. A separate, more recent story rounds out the picture: an InfoQ report from July 2024 describes the adidas platform team applying Karpenter for demand-driven, spot-aware node provisioning, Vertical Pod Autoscaler rollout automated through Kyverno policy, and scheduled scale-down via kube-downscaler for non-business hours — cutting CPU and memory consumption in development and staging by roughly 30%, and total non-production cluster costs by up to 50%, with production adopting the same techniques on an opt-in basis. Read together, the two stories show a platform team's job shifting over time from "get developers unblocked" to "make the unblocked platform cheaper to run" — which is exactly the FinOps discipline in FinOps & Cost Optimization.

Zalando: scale that kept multiplying, and mostly held

Zalando's public numbers are more about sustained scale than a single before/after delta: a platform that grew from a handful of clusters in 2016 to 140-plus by the time of its published cluster-management retrospective, serving 200-plus autonomous teams and 1,000-plus developers, while migrating through multiple major Kubernetes versions without downtime to the fleet. On the traffic side, the clearest public signal is Cyber Week's own growth — 71% more peak orders-per-minute in a single year (2018 to 2019) — landing on a platform that, by Zalando's own account, held up well enough to keep treating Cyber Week as a plannable annual program rather than a recurring crisis.

Check your answers

1. adidas: release cadence went from every 4–6 weeks to 3–4 times a day (Kubernetes.io case study). Zalando: peak Cyber Week orders-per-minute grew 71% from 2018 to 2019 (Zalando engineering blog) — a proxy for how much more load the self-service platform had to absorb without adding developer-facing friction.
2. Running Kubernetes clusters themselves — adidas brought in Giant Swarm because operating a cluster well isn't a competitive differentiator versus other retailers; the differentiator is what's built on top of it.
3. The postgres-operator, a Patroni-powered Kubernetes operator for managing PostgreSQL clusters as custom resources, first described on Zalando's engineering blog in 2017 and still widely used in the community today.
4. Because a central approval team simply cannot scale linearly with the number of requesting teams — past a certain size it becomes the exact bottleneck self-service was meant to remove, so infrastructure has to become a callable API instead of a queue.

What to actually steal for your own platform

☺ Like you’re 10: If you only remember three things from this whole file, remember these.

• Decide, explicitly, what's worth owning. adidas outsourced cluster operations to Giant Swarm; Zalando built its own Cluster Lifecycle Manager. Neither is universally right — but both made the call on purpose, rather than defaulting to "we'll just run it ourselves" out of inertia.
• Treat provisioning as an API, not a form. The common thread across both stories — and the one this course keeps returning to in Self-Service & Developer Portals — is that "fill out a request" became "call an API" or "write a small CRD," with a reconciler doing the repetitive work behind it.
• Rehearse for your worst day before it arrives. Zalando's synthetic load tests placing real (tagged) orders through production, and adidas's federated-Prometheus fire drill, both say the same thing: don't discover your scaling limits during the one week a year you can't afford to.
• Publish the boring tooling. Zalando's postgres-operator and external-dns weren't glamorous announcements — they were the unglamorous automation a lean platform team needed to run 140-plus clusters, shared because it helped the wider community too.

Honest caveats — what doesn't transfer

☺ Like you’re 10: Every story has parts that only make sense because of exactly who's telling it. Here's what not to copy blindly.

Both companies' public accounts are genuinely informative, but they're also, unavoidably, told by the companies about themselves — case studies and conference talks are marketing as well as engineering history, and neither company publishes its failure rate or the requests that didn't get resolved as tidily as the highlight reel suggests. A few specific gaps and scale mismatches worth naming:

• Era matters. Zalando's Cluster Lifecycle Manager was built starting in 2016–2017, years before the CNCF's own Cluster API project existed as a mature standard — it's a bespoke tool, not an implementation of today's Cluster API, and a team starting today has more off-the-shelf options for cluster lifecycle than Zalando did.
• Scale is not incidental. A 35-person platform team makes sense at adidas's few-hundred-engineer scale; it isn't the right number for a 20-engineer startup or a 5,000-engineer bank, and neither company's staffing ratio should be treated as a universal rule of thumb.
• Retail seasonality is a specific shape. Not every industry has a predictable, calendar-fixed peak like Cyber Week — a platform built around "we know exactly which six days are dangerous" doesn't automatically transfer to workloads with unpredictable spikes (see CERN for a very different scaling shape).
• The public record thins out on failure modes. Neither company's blog or case study discusses outages, incidents, or platform decisions that didn't pan out with anything close to the detail given to the successes — treat the absence of that detail as a gap in the record, not as evidence nothing ever went wrong.

Both files point at the same underlying architecture — a platform team, a golden path, and a reconciler doing the repetitive work — laid out in full in the reference architecture. Next in this evidence set: Mercedes-Benz, on keeping a large GitOps cluster fleet reconciled and auditable, or back to the case studies index for the rest of the board.