Heute wurde das Proxer-Stream Backend auf ein neues Backend migriert. Das Proxer-Stream-Backend ist einer unserer wichtigsten Dienste und war ursprünglich zugekauft. Diese Software bestand aus hunderten von Dateien mit Quellcode in Perl und binären verschlüsselten Dateien. Das Upgraden des Betriebssystems war nicht mehr möglich, weil Fehler in verschlüsselten Bereichen geworfen wurden. Es musste daher entweder die neue Version der Software zugekauft oder ein neues Backend entwickelt werden. Diese Feststellung hatte ich vor 4 Jahren gemacht.
Das Aufgabe ist, ein neues Backend für den Proxer Stream zu entwickeln, um unsere Streaming-Infrastuktur modernisieren und warten zu können. Als ich dieses Projekt angegangen bin, hatte ich nicht erwartet, dass es solche Ausmaße einnehmen wird… Erst heute hat diese Aufgabe ein Happy End gefunden. Hier ist meine kleine Geschichte vom aufwändigsten Migrationsprojekt, das ich bislang durchführen durfte.
Hintergrund
Die Proxer-Infrastuktur läuft überwiegend aus dedizierten Servern, die mit Debian betrieben werden. Unser Stream-Backend war jedoch seit langer Zeit ein Problemkind. Anfangs lief die zugekaufte Software sehr gut und war nicht sonderlich wartungsintensiv. Doch mit der Zeit und mit neueren Upgrades des Betriebssystems, war immer mehr hier und da manuelle Anpassungen nötig, damit die Software weiterhin lief.
Zuletzt lief im alten Backend Debian 7.11. Diese Version bekam zuletzt 2018 ein Upgrade. Die letzte Perl Version, die wir im alten Backend genutzt hatten, war 5.14, welches eine Version von 2011 war. Mit neueren Perl Versionen konnte die Anwendung ebenfalls nicht mehr funktionieren. Das Streaming-Backend lief bis heute tatsächlich mit seit 11 Jahre veralteter Software! Entsprechend instabil war unser Stream-Backend.
Aber ein Upgrade auf Debian 8 und neuerer Perl Version war aufgrund des verschlüsselten Bereiches nicht möglich. Ich bekomme bereits kalten Schweiß, wenn ich nur darüber schreibe. Veraltete Software ist absolut kein Zustand, den man behalten sollte. Mein Mittel gegen diesen Zustand war lange Zeit nur eine zuverlässige Backup-Infrastruktur und das Inkaufnehmen von Serverausfällen. Eine Neuentwicklung des Stream-Backends musste her, war aber gar nicht so einfach.
Software Stack
Ich will möglichst keine Frameworks nutzen, die potenzielle Angriffsflächen liefern. Daher habe ich überlegt, es zweierlei zu betrachten. Es gibt den öffentlichen Teil der Infrastruktur, was von allen zugänglich ist (z.B. das schauen von Episoden), und es gibt einen nicht-öffentlichen Teil (z.B. das Admin-UI).
Für die öffentlich zugänglichen Bereiche wird kein Framework gebraucht. Hier habe ich eine nette Lösung gefunden, um die Einbettungsseite umzusetzen. Kurzum gibt es mit dem neuen Setup kaum eine Angriffsfläche.
Für den internen Teil habe ich beschlossen F3 zu nutzen. F3 steht für Fatfree Framework und ist ein PHP Framework. Ich bin mir nicht sicher, ob das permanent sein wird, aber mit F3 kann man robuste APIs und Anwendungen bauen. Ich mags, weil ich damit relativ schnell an mein Ziel komme. F3 bringt auch ein einfaches Template-System mit. Für das Admin Web-UI nutze ich Bootstrap. In der Web-UI werden einfache Überwachungs- und Verwaltungsaufgaben durchgeführt.
Reverse Engineering
Bei der Migration ist der zeitintensivste Teil das Reverse Engineeren der alten Software. Beim Reverse Engineering schaue ich mir die alte Software an und beurteile, welche Teile davon für unsere Prozesse relevant sind und welche nicht.
Diese Teile entwickle ich dann von neu. Ich muss hierbei selbstverständlich auf die neuen Sicherheitsaspekte in meiner neuen Umgebung achten und auch die Belegung der Variablen verstehen, damit ich sie in ausreichendem Maße überprüfen kann.
Durch das Customizing im alten Backend gibt es sehr viele Möglichkeiten, die alte Software zu nutzen und dementsprechend auch Code, der für uns nicht (mehr) relevant ist. Der größte Teil des Codes ist für uns nicht relevant und stellt potenzielle Angriffsflächen dar. Diese Teile entferne ich.
Testen
Der Übergang vom alten Backend ins neue Backend muss reibungslos laufen. Daher habe ich viel Wert auf das Testen der existierenden Lösung gegeben. Ich habe manuelle Ende-Zu-Ende Tests geschrieben, die meine Erfolgskriterien dargestellt haben und die ich durchgeführt habe.
Das Testen war zeitintensiv. Im Nachhinein hat es sich aber absolut gelohnt. Ich hatte stets ein gutes Verständnis dafür, wie weit die Entwicklung ist, und welche Aspekte noch weiterer Arbeit bedürfen.
Migration
Nach dem ganzen Testen und sicherstellen, dass alles funktioniert, war die eigentliche Migration war am Ende einfach. Das alte Backend auf Read-Only stellen, Backup erstellen, Backup im neuen Backend einspielen, DNS umstellen. Fertig! Niemand hat etwas gemerkt.
Ergebnis
Nach etwa drei Jahren (unregelmäßiger) Entwicklung ist das Projekt abgeschlossen. Das neue Backend hat das über 10 Jahre alte Stream-Backend ersetzt. Das neue Backend entspricht von der Menge an Code einem Bruchteil des ursprünglichen Backends, obwohl es ebenfalls alle essentiellen Funktionen abdeckt. Der Migrationsprozess verlief reibungslos und ohne Downtime. Der Übergang war fließend.
Dieses Update war ein erster, aber herausfordernder Schritt, die Proxer-Stream Infrastruktur wartbar zu machen. Dies war aufgrund des proprietären Codes des alten Systems bislang nicht möglich. Damit ist die Proxer-Stream Infrastruktur nun auf einem besseren Fundament.
Fazit
Wartung von Software ist so viel teurer als die Anschaffung von Software. Es ist wichtig, dass man Software entwickelt, die möglichst wartungsarm ist. Besonders im Kontext von Proxer, wo wir nur eingeschränkte Ressourcen und Mittel haben, ist das essentiell.