diff --git a/_posts/2026-05-06-quarkusinsights-EP246.adoc b/_posts/2026-05-06-quarkusinsights-EP246.adoc new file mode 100644 index 0000000000..86905f9e5c --- /dev/null +++ b/_posts/2026-05-06-quarkusinsights-EP246.adoc @@ -0,0 +1,45 @@ +--- +layout: post +title: 'Quarkus Insights Episode #246: Evolving Minecraft Into a Cloud Native Platform' +date: 2026-05-06 +tags: insights +synopsis: Summary of the Episode #246 "Evolving Minecraft Into a Cloud Native Platform" +author: jcobb + +--- + +This summary was generated using AI, reviewed by humans - https://www.youtube.com/live/0079Co1GxcY[watch the video] for the full story. + +== Leveling Up Minecraft: CubeCraft's Journey to Cloud Native Platform + +Ever wondered what it takes to scale a passion project into a globally distributed platform for over 100,000 daily users? That's the core story Jaden Walderich of Zax shared in Quarkus Insights Episode 246, detailing how CubeCraft transformed from a grassroots Minecraft server into a serious cloud native operation. + +Forget the typical enterprise cloud-native talk. This is a practical case study in platform engineering under real-world pressure. + +++++ + +++++ + +=== The Problem: Scaling a Monolith with IRC + +CubeCraft started small in 2012. Like many growing projects, its early architecture was a monolithic plugin—the kind of setup that works fine until you hit serious scale. They even used IRC as a message broker in the early days! Growth, especially securing a partnership with Microsoft, quickly exposed the limits of this architecture. + +=== Migration One: Microservices, Still Not a Platform + +Their first big move (2015-2016) was breaking the monolith into standalone Java microservices. This took four years and increased game density, but as Jaden explained, they essentially traded one complex system for another. The key realization? Just adopting microservices doesn't automatically create an *operable* platform. + +=== Migration Two: Embracing Cloud Native (The Hard Way) + +In 2020, they shifted again, moving to Kubernetes and cloud native tooling, culminating in their "Rocket" platform. They chose OKD to fast-track platform decisions and standardized on *Quarkus* for application development, finding it a more natural fit for their cloud native goals and developer experience than Spring. + +The platform now features a two-layer split: a *Game Platform* for live workloads and a *Data Platform* (powered heavily by Quarkus microservices and operators) for stats, friends, and leaderboards, tied together with GraphQL and gRPC. + +=== The Real Technical Challenge: Lag Kills + +The most compelling part? They couldn't just use vanilla Kubernetes. Minecraft is incredibly latency-sensitive. A lag spike is a failed architectural decision, no matter how clean the YAML looks. The team ruthlessly optimized for player experience, using advanced techniques like Multus-based networking and ZRAM to reduce overhead and boost node density. They adapted cloud native patterns to gaming reality, not the other way around. + +Ultimately, the Rocket platform became its own product, supporting other Minecraft ecosystems, proving they had built a true, adaptable gaming platform. The biggest takeaway for any engineer is clear: *Understand your unique problem* ***before*** *you choose your tools.* + +If you're into platform design, high-scale architecture, or just a great modernization story, this episode offers a concrete look at cloud native engineering on a demanding, real-time workload. + +Seriously… you should watch https://www.youtube.com/live/0079Co1GxcY[Quarkus Insights #246: Evolving Minecraft Into a Cloud Native Platform].