Lebenslauf/Projekte/Nun Pirat

Nun Pirat: die Plattform unter einer Arabisch-Lern-App

Mit Nun Pirat lernen Kinder, Familien und Schulklassen Arabisch lesen und schreiben. Ich entwickle die App und habe die Plattform entworfen und gebaut, auf der sie läuft: Infrastruktur, Auslieferung und Monitoring. Um die Plattform geht es hier.

Meine Rolle

Plattform entworfen, gebaut, betrieben

Zeitraum

App seit 2024, Plattform 2026

Umgebungen

Staging und Produktion

Code

15 Plattform-Repositories, eine Pipeline

Was sie können musste

Familien lernen abends, Schulen vormittags. Die App muss also zu beiden Spitzenzeiten schnell sein und sollte dazwischen nicht ausfallen. Die Zahl der Lernenden sollte wachsen, und die Plattform musste mitwachsen, ohne neu gebaut zu werden. Ein Betriebsteam gibt es nicht, also musste die Routinearbeit von selbst laufen. An eine Cloud gebunden sein sollte sie nicht. Und eine Änderung auszuliefern musste so sicher sein, dass man es an einem gewöhnlichen Dienstagnachmittag tun kann.

Der Stack

Die Plattform besteht aus vier Schichten. Jede verlässt sich nur auf die darunter: Der App ist egal, auf welchen Servern sie läuft, und nur die unterste Schicht weiß, welche Cloud darunter liegt.

Alles läuft aus Code

Kein Server dieser Plattform wurde von Hand eingerichtet. Cluster, Netze, DNS-Einträge, Zertifikate, Datenbanken und Zugriffsrechte sind in Terraform festgehalten und werden von der Pipeline angewendet. Eine neue Umgebung ist derselbe Code noch einmal, deshalb unterscheiden sich Staging und Produktion nur in der Größe. Eine Änderung an der Infrastruktur geht wie jede App-Änderung durch ein Review, mit einer Vorschau, was sich genau ändert. Und weil der Code die Beschreibung der Plattform ist, veraltet er nicht wie eine Wiki-Seite.

Automatisiert vom Commit bis zur Produktion

Alle Repositories, App wie Plattform, teilen sich einen Satz Pipeline-Vorlagen. Eine Änderung nimmt deshalb überall dieselben fünf Schritte. Einer davon braucht einen Menschen, an dreien laufen Tests; welche, zeigt der Abschnitt zu den Tests weiter unten.

Was sonst von allein läuft

Updates der Komponenten, auf die die Plattform baut, kommen als Merge Requests und durchlaufen dasselbe Review und dieselben Tests wie jede andere Änderung. Die Betriebssystem-Schicht unter der App wird jede Nacht neu gebaut, Sicherheitsupdates erreichen die Produktion also mit dem nächsten Release. Und die Testumgebung hält Bürozeiten ein:

Automatisierte Tests

Die Tests sind Teil der Pipeline. Ein Release muss drei Ebenen davon bestehen, bevor überhaupt jemand um eine Freigabe gebeten wird, und nach dem Livegang wird die Produktion noch einmal geprüft.

360°-Monitoring

Eine Verfügbarkeitsprüfung sagt nur, ob die Seite antwortet. Auf dieser Plattform meldet jeder Teil, was er tut. Man sieht also auch, wie gut es läuft, was passiert ist, wohin eine Anfrage ging und wo die Zeit geblieben ist.

Vom Alarm zur Ursache

Weil die Signale verknüpft sind und jedes das Release trägt, aus dem es stammt, ist der Weg zur Ursache einer Verlangsamung kurz, statt einer Suche in mehreren Werkzeugen:

Wenn etwas schiefgeht

• Eine Änderung macht die Registrierung kaputt. Die End-to-End-Tests auf Staging schlagen fehl, das Release wird nie zur Freigabe angeboten, und die Produktion läuft weiter wie bisher.
• Ein Release enthält eine Datenbankänderung, die fehlschlägt. Sie scheitert, bevor die neue Version startet, das Release stoppt, und die Nutzer bleiben auf der vorigen Version, während die Pipeline zeigt, was schiefging.
• Seiten werden nach einem Release langsamer. Das Dashboard zeigt den Anstieg, die Traces zeigen, welcher Schritt langsamer wurde, und das Release an jedem Signal zeigt auf die Änderung dahinter.

Warum es so gebaut ist

Damit ein kleines Team es betreiben kann. Niemand muss sich an einen Handgriff erinnern, ein fehlgeschlagenes Release erreicht die Nutzer nicht, und wenn doch etwas schiefgeht, liegen die Daten zur Erklärung schon bereit.

Zurück zum Lebenslauf