MagentaGaming Cloud-Gaming-Plattform

Überblick

MagentaGaming war das Cloud-Gaming-Produkt der Deutschen Telekom, das AAA-Spiele über Browser, Android, Windows, macOS und Android TV an Endkunden auslieferte, ohne lokale Spielehardware. Die Spiele liefen auf NVIDIA-Servern im Festnetz der Telekom, integriert über eine C-Library auf Basis von Qt durch einen polnischen Lieferpartner. Mein Team baute die WebView-basierte Anwendungsschicht und die gesamte Cloud-Plattform für Account-Management, Frontend, Abrechnung, Freundeslisten und Leaderboards.

Ich war von Februar 2020 bis Oktober 2021 für das Projekt verantwortlich, organisatorisch als Deutsche-Telekom-Mitarbeiter aus dem Bereich Product Innovation. Zum Launch zählte mein Team 25 Personen, zu 90 % rumänische Externe der Firma Endava: Frontend, Backend, Test-Automation, DevOps und SREs. Wir arbeiteten nach SAFe.

Herausforderung

Die bestimmende Größe war die Gamescom-Deadline. Die Telekom hatte sich öffentlich auf einen Launch zur (corona-bedingt digitalen) Gamescom 2020 verpflichtet, mit Presse und Partnerankündigungen im Hintergrund. Sechs Monate Bauzeit, danach live vor Kameras.

Die größere technische Hürde lag in der Integration. Telekom-IT-Landschaften gelten zu Recht als komplex, und die etablierten Kernsysteme für Account, Bestellung und Abrechnung waren nie auf Cloud-Native-Konsumenten ausgelegt. Wir mussten eine moderne Serverless-Plattform an eine teils als Legacy wahrgenommene Konzern-IT andocken, ohne die Lieferfähigkeit der Gegenseite zu blockieren.

Funktional war der Scope breit: Kontoanlage, Tarifbindung, Spielbibliothek, Freundeslisten, gemeinsames Spielen, Statistiken, Leaderboards, Abrechnung. Jedes Feature hatte eigene Stakeholder, die in einem MVP-Sprintrhythmus gehört werden wollten.

Die Server- und Latenzthemen für die eigentlichen Spiele lagen außerhalb meines Bereichs. Die Spiele-Infrastruktur betrieb die Deutsche Telekom on-premises in eigenem Netz mit Backbone-seitiger Pfadoptimierung.

Rolle

Ich war Product Owner für das Cloud-Entwicklungsteam und übernahm parallel die System-Architektur. Daneben habe ich:

• Die fachliche Ausschreibung für die externe Lieferorganisation begleitet
• Security-Reviews vor jedem Release durchgeführt
• Die Plattform-Dokumentation und Release-Notes geführt
• Die Release-Koordination zur Gamescom übernommen

Mein direkter Verantwortungsbereich umfasste damit die gesamte Cloud-Plattform unterhalb des Spiele-Streams: Account-Lifecycle, Abrechnung, Frontend, Backend-APIs, CI/CD und Observability.

Vorgehen

Ich legte die Plattform von Beginn an serverless aus. ECS Fargate für stateless Microservices, Lambda für ereignisgetriebene Logik, Aurora PostgreSQL für transaktionale Daten, DynamoDB für High-Frequency-State wie Sessions und Leaderboards, Step Functions für Workflows wie Account-Anlage und Abrechnung. API Gateway plus Application Load Balancer bildeten die Edge, CloudFront stand vor statischen Assets.

Die Sicherheits-Baseline war von Anfang an aktiv: Security Hub, GuardDuty, CloudTrail, Inspector, KMS-CMKs, VPC mit privaten Subnetzen für die ECS-Tasks. CodeBuild und CodePipeline lieferten die Container-Images an ECR, Terraform verwaltete die gesamte Infrastruktur. Die Plattform lief vollständig in eu-central-1.

Die Endgeräte-Frontends sprachen über dieselbe API-Schicht. Der polnische Lieferpartner RemoteMyApp (RMA) stellte die C-Library für die Spiele-Integration auf Qt bereit. Mein Team baute die WebViews und die Anwendungslogik so, dass Spiele-Server und Plattform unabhängig voneinander entwickelt und getestet werden konnten.

Entscheidungen

Serverless statt klassischer Telekom-IT-Stacks. Eine herkömmliche EC2- oder On-Prem-Architektur hätte die Deadline nicht gehalten. Lambda, Fargate und Managed Services lieferten die nötige Liefergeschwindigkeit und sparten Patch- und Betriebsarbeit, die das 25-köpfige Team nicht hatte.

WebView-Pattern für plattformübergreifende UI. Dieselbe UI-Codebasis lief auf Browser, Android, Windows, macOS und Android TV. Das Frontend-Team baute Features einmal statt fünfmal zu portieren.

Spiele-Server bleiben on-premises. Die Latenzanforderungen waren mit dem Telekom-Backbone und der Pfadoptimierung in einer Region besser zu lösen als mit Cloud-GPU-Instances. Diese Entscheidung lag außerhalb meines Mandats. Die Plattform war aber so geschnitten, dass beide Welten sauber kooperierten.

Ergebnisse

• MVP in sechs Monaten gebaut, vom Projektstart Ende Februar 2020 bis Live-Launch am 23. August 2020 zur digitalen Gamescom
• 100 Spieletitel zum Launch verfügbar
• Über 200 parallele Spielesitzungen zur Launch-Spitze
• Rund 40 ms Glass-to-Glass-Latenz für Endkunden
• Fünf Endgeräte-Plattformen mit gemeinsamem UI-Code: Browser, Android, Windows, macOS, Android TV
• Keine Verfügbarkeitsausfälle während des Launch-Fensters
• Cloud-Plattform vollständig in eu-central-1 unter Konzern-Datenschutz-Vorgaben betrieben

Die feste Gamescom-Deadline wirkte als Forcing Function für Scope und Architektur-Disziplin. Die Telekom stellte den Dienst Anfang 2023 nach knapp zwei Jahren ein. Bis dahin trugen die Architekturentscheidungen den Betrieb ohne strukturellen Umbau.