Warum ich ein Nahverkehr-Dashboard baue
Oh Mann, gestern ist es schon wieder passiert. Anstatt einer Stunde habe ich fast zwei gebraucht, um nach Hause zu kommen. Erst hatte die Bahn Verspätung und dann fiel der Zug komplett aus. Der anschließende Zug war dann natürlich so voll, dass nicht mehr alle hineinkonnten und ich auf den nächsten warten musste.
Passiert das eigentlich nur mir ständig und ich habe einfach nur Pech, oder ist das ein grundsätzliches Problem?
Hmmm … lässt sich das nicht analysieren und auswerten?
Man könnte da doch ein wunderbares Dashboard bauen, das die Zuverlässigkeit bestimmter Verbindungen zeigt und vielleicht sogar ein Muster findet, oder nicht?
Und vielleicht wäre das ja sogar noch für andere interessant?
Wie so oft bei solchen Ideen wurde lange Zeit daraus nichts und es blieb bei einer bloßen Vorstellung.
Bis jetzt. Jetzt ist es an der Zeit, und ich werde von der Idee endlich in die Umsetzung gehen. Ich werde aus meinem Verdacht eine datengestützte Gewissheit machen. Ich baue ein Nahverkehr-Zuverlässigkeits-Dashboard (der Name ist noch Work in Progress 😅).
Das Konzept: Enterprise im Kleinen
Ok, die Motivation ist da. Auch das Ziel ist einigermaßen klar. ✅
Doch wie will ich es umsetzen?
Was ich definitiv nicht will, ist eine Sammlung von Skripten, die dann irgendwie am Ende mit einem Cron-Job oder Ähnlichem in einer BI-Auswertung landen.
Mein Wunsch ist es, etwas zu schaffen, das auf meinem bisherigen Wissen aufbaut, dieses testet und mich neue Erfahrungen machen lässt.
Da ich inzwischen schon Datenplattformen aufgebaut habe, soll eine solche hier ebenfalls mein Fundament sein. Dabei ist mir eine gute Developer Experience genauso wichtig wie eine nachhaltige, sichere, vertrauensvolle und wartbare Plattform.
Womit ich bisher noch keine Berührungspunkte hatte, was mich aber stark reizt, sind „Echtzeit“-Daten. Bisher habe ich nur Pipelines geschaffen, die höchstens stündlich verarbeitet wurden. Ich möchte diese Pipeline aber so aufbauen, dass sie im Minutentakt durchlaufen kann.
Gleichzeitig möchte ich sicherstellen, dass die Plattform im Kleinen läuft und nicht bei den Kosten explodiert. Schließlich muss ich das Ganze ja auch irgendwie bezahlen können.
Das klingt im ersten Moment nach einer ziemlich komplexen Lösung für etwas, das mir einfach nur ein Bauchgefühl bestätigen soll. Und ja, um ausschließlich dieses Ziel zu erreichen, ist mein beschriebener Ansatz sehr wahrscheinlich ein klarer Fall von „Overengineering“. Aber genau das ist ein weiteres Ziel dieses Projekts. Ich will besser verstehen, wann Komplexität notwendig ist, um ein klares Ziel zu erfüllen, und wann man darauf verzichten sollte. So etwas kann man meiner Meinung nach nur lernen, wenn man „hands-on“ entsprechende Entscheidungen treffen muss.
Somit sollte der Scope des Projekts geklärt sein.
Eine „Enterprise-Lösung im Kleinen“, um die Zuverlässigkeit des Nahverkehrs auf bestimmten Strecken in einem coolen Dashboard sichtbar zu machen.
Die Lösung soll Prinzipien und Anforderungen von Enterprise-Lösungen wie Zuverlässigkeit, Sicherheit, Nachvollziehbarkeit, Wartbarkeit, Monitoring & Alerting usw. enthalten, dabei gleichzeitig auch kostengünstig und durch mich allein wartbar sein.
Also ein besonders effizientes und kostengünstiges Projekt, das so oder so ähnlich auch in einem professionellen Umfeld zum Einsatz kommen könnte.
Wie geht es jetzt weiter?
In den kommenden Tagen und Wochen werde ich in diesem Blog immer wieder den Projektfortschritt dokumentieren. Auch werden Artikel erscheinen, die bestimmte Entscheidungen von mir näher beleuchten und erklären.
Einer der nächsten Artikel wird genau das tun. Er beschreibt, welche Tools und Technologien zum Einsatz kommen und warum ich mich für diese und gegen andere entschieden habe.
Hier findest du heraus, welche Tools beim Nahverkehrs-Dashboard zum Einsatz kommen.