I love you, GIGA!
OMFG, wir werden „GIGA“!
Es kommt mir vor, als sei es gestern gewesen. April 2011 war es, die Sonne schien und 4 Vögel flogen am Fenster vorbei. Ich war neu dazu gekommen um das neueste Projekt mit aufzubauen: funload.de. Noch bevor ich mir die Namen aller merken konnte, die dicht gedrängt an einem meterlangen Tisch arbeiteten, kam die unglaubliche Meldung die die Erfüllung eines schon vergessenen Wunsches bedeuten sollte. Zuerst fiel nur der Name „GIGA“ und es war so, als würde eine Schulband von den Rolling Stones was hören – ikonisches Ziel und unerreichbarer Wunsch nach Teilnahme an diesen Namen und Ruhm. Allein die Möglichkeit, etwas mit der Marke zu tun zu haben mit der man als Jugendlicher aufgewachsen war und an so vielen Tagen die einzige zeitgemäße Fernsehsendung zu sein schien, sprengte alle Vorstellungen. Was wäre, wenn ich tatsächlich bald bei GIGA arbeite, so wie ich es vor einem Jahrzehnt gedacht aber nie für möglich gehalten habe…?!
Und dann geschah es. Als es Gewissheit wurde, dass „GIGA“ zu uns kommen würde, zu unserem keinen aber pathosbeladenen Team, blühten wohl nicht nur in meinem Kopf Sträucher an Möglichkeiten, wie die Zukunft in Zusammenhang mit diesem großen Namen aussehen könnte. Wenig später wurde es Ernst und Nägel mit Köpfen mussten gemacht werden: Studioeinrichtung wurde mit einem Transporter Stück für Stück nach Berlin gebracht, voll bepackte Serverracks wurden in unser Rechenzentrum geschafft, die Redaktion bereitete sich auf die neuen Dimensionen der Berichterstattung vor und auf eine altehrwürdige Community, die – nicht ohne etwas Zweifel, wieder einmal – auf die Neuen setzte.
Die Technik, wie sie uns überlassen wurde, war ein heftiger Klopper – noch aus der Fernsehzeit von GIGA entsprungen, war sie etwas alt doch vor allem extrem komplex. Streamingserver noch und nöcher, redundante Server fürs Frontend und Datenbanken, mehrere Load Balancer die mit all dem Equipment eingestellt waren und wo wir erst nicht durchblickten, was sie alles machen sollen. Vor allem der Overload: denn Streaming machten wir nicht und die Redundanz stellte sich als eher fehleranfällig und pflegeaufwändig heraus als dass sie von Nutzen gewesen wäre. Und dann die Codebasis – „Smarty“ sei Dank, blieb wenigstens bei den Views etwas Klarheit erhalten. Der Rest war in Teilen ein solide gewachsenes selbstgemachtes PHP-Framework aber ebenso Unmengen an Altlasten. Ich entsinne mich nicht mehr genau wie viele hunderte Tabellen auf mehreren Datenbanken verteilt waren. JOINS über diese Datenbanken hinweg waren manchmal notwendig um den Inhalt darzustellen. Wir standen vor der Entscheidung, eine Grundreinigung durchzuführen oder das System komplett neu aufzusetzen. Wie man weiss, setzen wir Ende 2011 dabei auf WordPress – und bauten alles neu.
Der Relaunch 2012 – 5 Portale zu 1 Portal
Welch monströse Aktion! Für 2 Wochen waren Stefan und ich in einem hinteren Raum im Büro eingeschlossen und legten die Datenstruktur des neuen GIGA fest. Im Hinterkopf der Plan zur Migration von hundert tausenden alten GIGA Beiträgen nach WordPress – dazu die Einverleibung zehntausender Artikel von funload.de, freeload.de, macnews.de und androidnews.de. Zum Glück waren diese schon WordPress-Systeme denn das bedeutete zumindest, dass die Datenquellen definiert sind. Doch auch hier waren spezielle Daten noch in extra-Tabellen gespeichert worden, Usernamen waren mehrfach vorhanden, das Encoding des alten GIGA-Systems war im laufe der Zeit mal ISO mal UTF8 gewesen. Dann das Erstellen neuer URLs, die Weiterleitung der Alten zu den Neuen, Übernahme historischer Weiterleitungen aller Portale (die mal als PHP Code, mal in .htaccess mal in der Apache Config drin standen) – eine Mamutaufgabe, die zuletzt von komplexen Skripten in tagelanger Arbeit automatisiert umgesetzt wurde. Dabei wurden Schwachstellen des WordPress-Systems sichtbar, denn alleine das URL-Routing für hundert tausende URLs braucht eine Eigenentwicklung – WordPress wäre mit seinen RegExps schon bei weniger als 100000 Artikel nicht mehr verwendbar gewesen. Ach ja, während dessen liefen alle einzelnen Portale weiter und neue Daten häuften sich parallel an – yeah!! Und dann wurde ich auf dem Fahrrad von einem Auto umgebrettert und war erst einmal eine Weile außer Gefecht gesetzt… Nun saß die Entwicklung mit einem Mann weniger da – es folgten lange Tage und Nächte für die gesunden 5 Entwickler, die Front- und Backend für eine Millionen-PI-Seite vom Grund auf erstellen mussten. Und doch startete die neue Webseite nach Plan 2012 in hellen und bunten Farben – alle Themen der einzelnen Spezialportale auf eine Seite, bewusst nicht länger getrennt sondern als Synergie. Der Rest ist Geschichte – bis 2013.
Der Relaunch 2013 – Ihr kennt die Probleme?! Die darf es ab jetzt nicht mehr geben!
Die Synergie fruchtete nicht sondern vergraulte alte User. Die Server ächzten unter den neuen hungrigen interaktiven Komponenten der Seite. Irgendwann wurde deutlich, dass Frontend und Systemkern mit einem Konzeptwechsel auf die Werkbank müssen. Und so wurde die Datenbasis wieder getrennt – diesmal nur logisch. Wir behielten das, was sich bewährt hatte: das Backend von WordPress leistet eine hervorragende Arbeit und ist für neue Redakteure leicht verständlich. Hier musste im Workflow einiges besser gemacht werden und so setzte sich Florian daran eine bis dahin unerreichte Workflow-Logik den Meta-Boxen von WordPress beizubringen. Eine aufgeräumte Oberfläche entstand, die Fehler bei der Abarbeitung des Workflows gut nachvollziehbar darstellte und der Redaktion nun aktiv half.
Das Design der Webseite sollte diesmal für jede einzelne Themenwelt komplett anders gestaltet werden können – mobile Webseite inklusive. Das bedeutete: wenn die GAMES Redaktion eine runde Webseite haben will, dann soll es gehen! Das ist mit WordPress leider ziemlicher „pain“, auch mit den netten Child Themes: ein eigenes System musste her. WordPress werkelt dabei wie gewohnt, Hooks sorgen dafür, dass das Template je nach Client, Themenwelt und vieles Andere Parameter aus einer anders geordneten Hierarchie geladen wird. So lässt sich heute blitzschnell eine neue Themenwelt erstellen, dazu eine mobile Version, und beide müssen nicht das Geringste mit den anderen Themenwelten gemein haben.
Die Geschwindigkeit der Seite war 2012 ein quälendes Problem. Die üblichen Cache-WordPress-Plugins und der Einsatz von „memcache“ konnten ein grundsätzliches Problem nicht lösen: bei hundert tausenden Seiten sind immer genug da, die nicht im Cache liegen oder deren Caches schon abgelaufen sind und frisch generiert werden müssen. Oder wenn gerade 50 Tausend User sich eine Livesendung anschauen und zeitgleich ein Cache abläuft, dann verlangen einfach zu viele User gleichzeitig eine ungecachte Version vom Server, der dann die Grätsche macht. Wie löst man dieses Problem, ohne dauernd eine Serverfarm für jedes Apple-Event und Livesendung zu unterhalten? Es wurde deutlich, dass der statische Teil der Webseite vom dynamischen entkoppelt werden muss und dass der dynamische Teil besser Ereignis-Getrieben funktionieren sollte und nicht On-User-Demand. Es stellte sich heraus, dass bei den hundert tausenden Artikelseiten die meisten eher alt sind und sich ihr Inhalt nicht mehr ändert – mit Ausnahmen. Warum also diese Artikel nicht statisch ablegen und nur bei Änderung neu rendern? Die Prozedur ist allerdings ein komplexes Stück Code, denn wenn das Design der Seite sich ändert muss diese Änderung sichtbar werden – einfach nur als HTML ablegen geht bei hundert tausenden Seiten nicht denn es würde viel zu lange dauern dauern. Unterm Strich musste also WordPress wieder um eine bisher nicht vorhandene Lösung für intelligente statische Caches erweitert werden, ähnlich wie sie bei anderen CMS durchaus üblich ist. Dann die dynamischen Bestandteile der Seite wie die Kommentare – sie sind immer eine beträchtliche Last, denn viele User drücken F5 mehrmals einfach nur um zu prüfen ob jemand ein Kommentar geschrieben hat. Was man nicht machen darf ist On-User-Demand die Kommentare zu holen und zu rendern denn das geht bei 10 Mio Views pro Monat garantiert in die Hose oder aber es kostet Unmengen für die Serverbereitstellung. So mussten auch hier eine Event-Driven-Architektur neu aufgebaut werden, die die Kommentare so lange statisch vorhält, bis Änderungen eintreten. Da auch die gesamte Datenhaltung in WordPress neu designed wurde und es nun eine GIGA-native Syndication API gab, war es anschließend auch unproblematisch endlich eine neue und performante App für iOS und Android erstellen zu lassen – die Alte basierte noch auf die XML Feeds, die aber darum sehr anfällig bei Contentänderungen geworden waren.
The Happy End 2013
Und so werkelt jetzt ein unvergleichbar ge-pimpt-es WordPress-System und treibt solide eines der größten Gaming- und Techportale Deutschlands an – nur noch übertroffen durch die Leistung ihrer Redaktion die der Grund ist, dass monatlich Millionen Menschen die Seite besuchen, sowie technisch für die Zukunft gewappnet mit einem hervorragenden Entwicklungsteam. Und angesichts dieses Erfolges und der nun nachweislich soliden Systembasis kann ich jetzt alle ihre Arbeit machen lassen – und verlasse im Guten meinen Posten als Leiter der Softwareentwicklung bei GIGA.de. Meine Zukunft ist dabei nicht unklar – Markus, Andre und Maik von AKM3 haben Großes vor und ich werde künftig als CTO von AKM3 dafür Sorge tragen, dass es gut wird! ;)
GIGA.de ist für mich weiterhin die erste Informationsquelle wenn es um Gadgets, Games und – neuerdings – Film und Fotografie geht. Und vermutlich werde ich nun auch mein Communityaccount öfter nutzen – jetzt, da ich mich den Reihen der Ehrwürdigen anschließe.
