Playtika started their Kubernetes journey when most companies were still Googling what a container was. But for those who are unfamiliar, it’s worthwhile to introduce who Playtika is.
Playtika builds and operates some of the most widely played mobile games on the planet, and behind that consumer experience sits an infrastructure operation of a scale most engineers will never encounter. They run a platform that spans multiple global data centers, thousands of bare metal servers, hundreds of Kubernetes clusters, and tens of thousands of containers in continuous operation.
The upside of early adoption is real—you are able to build expertise before the market catches up, you get a seat at the table when vendors are still shaping their roadmaps, and you reach production capabilities years ahead of your peers.
But the tax is that you’re paving the road while driving it. Projects are still evolving, peripheral tooling is either nonexistent or not yet production-grade, and you end up building, duct-taping, and maintaining what the ecosystem hasn’t yet built.
For Playtika, that was the story for nearly a decade. When the CNCF tooling finally matured enough to support their scale, the gap between where the ecosystem had arrived and where Playtika’s infrastructure was sitting became impossible to ignore. In a recent talk at KubeCon, Scott Rosenberg and Shemer Mashiach walked through the whole arc and evolution of what it really takes to run platforms at scale. From the early days of Kubernetes 1.6 to a modern, GitOps-driven platform running across multiple global data centers to tear off that duct tape and wire it all together natively.
This post will dive into all the lessons they learned along the way.
The Early Adopter Tax
Playtika was running Kubernetes before most of the ecosystem existed. That meant building things that simply had no off-the-shelf equivalent at the time, not because they wanted to, but because there was no other choice (as Martin Fowler has long argued, deploying the code is the easy part – maintaining it is where the real work begins).
Three separate etcd clusters just to keep Kubernetes events, Calico, and the control plane from stomping on each other. Custom CoreDNS configurations with route reflectors living on random machines doing BGP. Headless services as a makeshift load balancer substitute because service type LoadBalancer on-prem simply wasn’t a thing yet. Forked Helm charts. Tailored Jenkins pipelines. A homegrown installation layer built on top of kubespray. Routable pods that worked fine until Playtika ran out of IPv4 addresses – the entire IPv4 space, exhausted.
This was not a single team making bad decisions. It was what responsible engineering looked like when you were operating at Playtika’s scale – when the industry hadn’t caught up yet. The problem is that technical debt from early adoption doesn’t stay contained. It compounds.
Kubernetes version upgrades that should take days stretched to months, sometimes falling two or three versions behind, because every upgrade needed to be validated against a stack of custom solutions that no vendor had ever tested. A feature was deprecated in Spring Cloud Config because the Spring team genuinely never imagined anyone would use it the way Playtika had, so Playtika had to fork and maintain their own version of it. The custom solutions that had been life-saving workarounds became the walls of a box that got progressively smaller.
What Happened When They Tried to Modernize
The first round of modernization attempts didn’t go well, and it’s worth being honest about why.
The initial instinct was to solve problems one at a time with products. PKS (Pivotal Container Services, now TKGI) had a compelling value proposition until they went through double digits of internal versions specifically named after Playtika trying to make it work at their scale.
(Spoiler: It didn’t.)
Cluster API for vSphere came next, and ran into similar walls. Each time, the approach was reactive: identify a pain point, find a product that addresses it, discover the product doesn’t handle the actual scale, watch the engineering teams retreat back into their homegrown solutions.
The cultural dimension made it worse. When external solutions keep failing, teams naturally conclude they know their environment better than anyone else and stop expecting outside tooling to help. That’s a reasonable conclusion to reach, and it becomes a self-fulfilling one. Playtika’s engineering teams started locking in around their own stack not out of stubbornness but out of accumulated evidence that nothing else would work.
The real failure wasn’t vendor selection. It was framing. Approaching modernization as a series of product problems rather than a platform problem meant the team was always optimizing locally, solving for a specific pain point, while missing the broader picture of what a coherent platform play would actually unlock.
The Platform-First Mindset that Finally Worked
The shift that broke the cycle was moving from a product-first to a platform-first mindset, and backing it with two organizational prerequisites: genuine management commitment, and active buy-in from the engineering teams who would live with the results. Neither alone would have been sufficient.
The new platform has several load-bearing components worth examining:
- Cluster lifecycle management via Spectro Cloud.
Rather than trying to build a fleet management capability from scratch or force an enterprise product to bend to their scale, Playtika found that Spectro Cloud, built on top of Cluster API, gave them the standardization they needed while bringing along open-source projects they could actually rely on: External Secrets Operator, External DNS, monitoring, observability. The key was that it wrapped these into something consumable without locking Playtika into a vendor-specific implementation. Everything underneath is open source.
- CloudStack and Crossplane as the infrastructure foundation.
A deliberate separation between infrastructure provisioning and application provisioning. Crossplane’s provider model gives Playtika a transparent abstraction layer. If they need to provision against a different infrastructure tomorrow, the interface stays consistent. This is the kind of architectural decision that looks conservative in the short term and pays dividends for years.
- GitOps via Flux.
The guiding principle is that Git serves as the single source of truth for everything running in the cluster. No one deploys directly to a cluster, every change is version-controlled, pushed through Git, and picked up by Flux from there. This matters beyond process hygiene. This way, the architecture is designed so that even if the management (brain) clusters go down, workloads keep running because they’re connected directly to Flux. The only capability lost in that scenario is upgrades and patching, an acceptable tradeoff.
- Linstor for local storage.
Databases running inside Kubernetes required a serious solution for local disk provisioning and the IOPS demands that come with it. Linstor solved the storage layer that had previously required significant custom work.
- ScaleOps for automated pod sizing.
Worth noting, the only autosizing solution that understood Java heap memory, which matters when roughly 90% of your workloads are Java and Spring Boot was ScaleOps (albeit a commercial product). Getting right-sizing wrong in that context means leaving significant compute spend on the table.
Finally, Kyverno for policy management, Backstage for the internal developer portal, and vCluster for staging and development environments round out the picture, each solving a specific part of the developer experience without adding bespoke complexity.
The Numbers That Actually Matter
Data-driven decision making isn’t a platitude here, it’s what justified the investment and is tracking the outcome.
A few concrete results:
- Failover between data centers dropped from roughly 60 seconds to 13-14 seconds.
- Cluster provisioning time fell from a day and a half to approximately one hour.
- The team is 60% migrated to the new platform in under a year at Playtika’s scale, which is a meaningful pace.
The platform choices weren’t just theoretically sound, the numbers validated them in practice. The architectural decisions proved their worth when translated from theory to practice, yet while the numbers speak for themselves, 60% migrated also means 40% still to go.
The Lessons Worth Carrying
A few things stand out from this particular journey that apply beyond Playtika’s specific context.
Early adoption creates technical debt by definition. That’s not an argument against being an early adopter, the teams who build deep expertise on emerging technology accumulate real competitive advantages. But the decision to adopt early should come with an explicit plan for what the eventual migration looks like. The debt isn’t avoidable. What separates the teams that manage it from the ones that don’t is whether the transition plan was baked in from day one.
The build-versus-buy default matters more than individual decisions. Playtika explicitly flipped their organizational default from build-first to buy-first. Not because buying is always right, but because the true cost of building and maintaining custom solutions – engineer-hours, cognitive load, upgrade risk, onboarding friction – is reliably and often underestimated. You should build only in the edge case when buying genuinely doesn’t solve the problem. High-scale companies should default to buying until it genuinely can’t solve the pain point.
In addition, aligning to industry standards is neither conformity nor boring, it’s what scales. Challenging the “we’re a unicorn, nothing works for us” assumption doesn’t mean abandoning the genuine constraints of operating at scale. It means being rigorous about distinguishing real constraints from accumulated institutional habits. Playtika’s scale is real. But not every custom solution they’d built was truly load-bearing.
What’s more, continuous measurement is the only way to know if it’s working. Decisions made without baseline metrics can’t be validated. The improvements above are legible because someone cared enough to measure the before state and can now benchmark those against the new system.
And finally: you will make bad decisions. We all do. That’s the nature of an evolving platform and engineering.
The goal isn’t to avoid failure but to catch it fast and cut losses without ego getting in the way. That requires the organizational culture to support it, which is where the management commitment and engineering team buy-in come back around to unlock your platform capabilities.