#heiseonline25: Software für heise online - vom Webserver zum komplexen CMS
Hinter jeder Website steht ... Software. Und Entwickler, die sich um die Programmierung kümmern: Ein Software-Blick hinter die Kulissen von heise online.
(Bild: Michkasova Elena / Shutterstock.com)
25 Jahre sind in der IT und im Internet eine recht lange Zeit. So verwundert es wohl nicht, dass sich, als heise online vor 25 Jahren startete, niemand so recht vorstellen konnte, wie groß und komplex die Site einmal werden würde. Es begann als recht einfacher Webserver - 1994, zwei Jahre vor dem Start von heise.de, unter ix.de.
Zu diesem Zeitpunkt, gut drei Jahre nach der Vorstellung des World Wide Web durch Tim Berners Lee, war das für viele sehr neues "Neuland". Mit dem Start des Newstickers und von heise.de im April 1996 begann auch eine Geschichte von Software-Entwicklung und eines Software-Systems, das ständige Änderungen und Neustarts mit sich brachte. Und viel Arbeit für unsere Web-Entwickler ...
Erinnerungen aus der Zukunft: Etwas Vor- und Frühgeschichte
Das früheste Eingabe- und Auslieferungssystem, das in der heise online-Webentwicklung in "lebender Erinnerung" ist (also das von noch aktiven Mitarbeitern der Webentwicklung persönlich erlebt wurde), ist der NTicker. Das heißt, der eigentliche Name ist "NTicker NT", denn wie bei vielen alten Bauwerken steht es auf einem Fundament, das noch älter ist. Über die vorigen Systeme ist nicht mehr viel bekannt außer Mythen und Legenden. So gibt es die Geschichte, dass eine Weihnachtsfeier fluchtartig unterbrochen werden musste, da heise online "stecken geblieben" war. Jemand hatte die 1000ste Meldung freigeschaltet, und das System war schlicht nicht auf vierstellige Nummern vorbereitet. Wer hätte auch ahnen können, dass es auf heise online mal mehr als 999 Meldungen geben würde? Ein frühes Beispiel für ein Success Disaster.
Eigentlich ist es ja schon 27 Jahre her, dass heise online mit ix.de startete. Redakteure von iX hatten den ersten Web-Server des Verlags auf dem Redaktions-Server installiert und zeigten ihn auf dem CeBIT-Messestand. Am 17. April vor 25 Jahren aber ging es auf heise online mit Newsticker und einer ersten, noch recht rudimentären News-Meldung so richtig los. Gleichzeitig wurde mit www.heise.de ein gemeinsames Dach für alle Magazine des Verlags geschaffen.
Wenn uns auch viele Themen bereits der ersten Tage auf heise online immer wieder beschäftigten, so hat sich mittlerweile das Universum von heise online, was Meldungen, Themenspektrum und Angebote angeht, stark ausgedehnt. Bis hin zu neuen Video- und Podcast-Formaten und dem Abo-Angebot heise+ für alle Artikel aus den Magazinen von heise Medien und exklusive Hintergrund- und Know-how-Artikel.
Zum Jubiläum starten wir eine Reihe von Artikeln und Aktionen, die die Geschichte von heise online (und der Foren) beleuchten und Einblicke in hard- und softwaretechnische Hintergründe sowie die Arbeit der Redaktion ermöglichen. Nicht zu vergessen das eine oder andere Quiz zu wichtigen Geschehnissen und Meilensteinen, und[ [...], und ... – leider angesichts der Corona-Pandemie im Unterschied zum 20-Jahre-Jubiläum dieses Mal ohne User-Party. Zur Erinnerung bietet sich die Spotify-Playlist für die Party an.
Jedenfalls: Es wird auch aus Anlass des 25-Jährigen einiges los sein. Stay tuned!
Aber zurück zum NTicker. Dieser bestand aus einem selbstentwickelten Content Management System namens nt.meldung , einem Distributionssystem namens nt.transfer und einer Auslieferungsschicht namens nt.deliver. Alles monolithische Perl-Gebilde in (damals) moderner FastCGI-Architektur. nt.deliver lieferte Seiten aus, indem es mit Hilfe einer riesigen Liste von regulären Ausdrücken den dazugehörigen Seitentypen ermittelte (liebevoll "Schnippsel" [sic] genannt). Zu diesem Schnippsel wurden aus der dazu konfigurierten Datenbank-Tabelle die entsprechenden Zeilen extrahiert, diese Daten umgewandelt und an ein Template-System übergeben.
Ein Template-System übrigens, das so puristisch war, dass es (wohlgemerkt als Feature!) weder mit verschachtelten Daten noch mit boole'schen Ausdrücken umgehen konnte. Daten, die nicht in der Datenbank standen, blieben außen vor. Es gab hunderte solcher Schnippsel, jedes mit seiner eigenen Konfiguration, und zentrale Methoden wie das beliebte doSchnippsel mit mehreren tausend Zeilen. Um einem neuen Entwickler eine eigene Instanz zum Arbeiten einzurichten, mussten mehrere Bildschirmseiten von Pro-User-Konfiguration erst dupliziert und dann akribisch angepasst werden.
Kompliziert ist einfach: nt.deliver
Die Templates mussten damals alles beinhalten, also nicht nur den Inhalt der Seite (zum Beispiel den Text der Meldung), sondern auch die Kopf- und Fußzeilen, die Navigation, und die rechte sowie (damals noch anzutreffende) linke Spalte. Um zu gewährleisten, dass alle Templates immer die aktuelle Version dieser Elemente beinhalteten, wurden sie via SSI (Server Side Includes) in einem Apache-Server zusammengestellt. Aber nicht on demand, stattdessen gab es einen Server namens "wwwedit", der diese Umwandlung vornahm. Die einzelnen Bestandteile der Templates, die Includes, wurden in das pub-Verzeichnis von wwwedit gelegt. Dann wurde das Haupttemplate jedes Seitentyps via wget abgefragt und das resultierende, zusammengesetzte Template im Template-Ordner der Anwendungen abgelegt. Von dort wurde es in den Auslieferungscluster transferiert.
Beim Programmstart des nt.deliver-Systems wurden erst einmal sämtliche Templates von sämtlichen Seitentypen geladen und geparst. Was als Schutz vor tickenden Zeitbomben in Form von Template-Fehlern begann, wurde letztlich zu einem Hindernis, denn je mehr verschiedene Seiten- und Artikeltypen es gab, desto länger dauerte es, den Prozess neu zu starten, um beispielsweise neuen Code zu aktivieren. Das konnte mehrere Minuten dauern, weshalb nie der ganze Cluster auf einmal neu gestartet werden durfte, sondern immer nur ein Rechner auf einmal; der Load Balancer musste die Requests solange umlenken.
Zeitreise: heise online im Lauf der Jahre (22 Bilder)
(Bild: heise online / Wayback Machine)
Als größte Schwäche erwies sich jedoch der Umstand, dass das komplette System in-house erstellt und angepasst wurde, einschließlich des CMS zur Meldungseingabe. Alles von ein bis zwei Handvoll Mitarbeitern, die auch noch andere Baustellen des Webauftrittes zu betreuen hatten, wie etwa das Forum. Wenn jetzt neue Anforderungen kamen (wie die futuristische Idee, Bytes im Internet könnten nicht nur Buchstaben darstellen, sondern Farbwerte von Bildpunkten!), konnte die Umsetzung Wochen bis Monate dauern.
Ist ja alles so schön rot hier: InterRed
Als Konsequenz wurde heise online 2009 auf das InterRed-CMS umgestellt. Dahinter steht eine ganze Firma, die sich ausschließlich um die Weiterentwicklung des CMS kümmerte, und zwar für viele Kunden gleichzeitig. Moderne Features wie Bilderstrecken oder Datei-Downloads gab es mal einfach nebenbei im Basispaket.
Im Unterschied zum nt.deliver wurden die Seiten nun nicht bei Abruf spontan aus der Datenbank erzeugt, sondern als feste Datei in einem Dateibaum gebrannt, wie bei einem Static Site Generator. Um dennoch die gewünschte Dynamik eines modernen Webauftrittes leisten zu können, wurde aber nicht das fertige HTML gebrannt, sondern (dank eines sehr mächtigen Template-Systems) als ausführbares CGI-Skript – pro Seite! Das Apache-Modul mod_perl sorgte dabei für die nötige Performance. Das hatte den großen Vorteil, das eben nicht ein Prozess sämtliche Seitentypen von Anfang an ausliefern können musste, sondern jede Seite quasi nur sich selbst. Der Dateibaum ersparte auch die riesige Regex-Liste zum Parsen der URLs; sowohl Struktur als auch Inhalt der Seite wurden jetzt direkt vom Dateibaum selbst diktiert.
Ein großer Nachteil an dieser Konstruktion war jedoch, dass die kompletten Daten der Seite im Prinzip nur noch bei der eigenen Auslieferung zugänglich waren. Für Konstrukte wie eine Newsroll auf der Startseite, von der ein Newsticker nun mal lebt, wurden nur die nötigsten Daten in eine andere Datenbank zwischengespeichert. Jede ausliefernde Stelle musste selbst wissen, wie alle solche einbettbaren Daten zu verarbeiten waren.
Und dass der ausgeführte Code einer Seite letztlich per Code-Generation erstellt wurde, wenn die Seite live ging, machte auch das Entwickeln schwierig und das Testen unmöglich. Denn es gab nur das eine, eigenständige CMS – das konnte man nicht eben so für CI verwenden oder die Template-Engine heraustrennen.
