Das Projekt
Goldschmidt leistet bei der Instandhaltung, Inspektion und Digitalisierung der Bahninfrastruktur Pionierarbeit. Auf der digitalen Plattform Data acquisition for rail infrastructure (Dari®) werden die Produkte und Dienstleistungen von Goldschmidt smart miteinander vernetzt, indem Mess- und Kontrolldaten zentral und in Echtzeit zur Analyse und Weiterverarbeitung zusammengeführt werden. Dies ermöglicht Eisenbahninstandhaltungsunternehmen, das Gerätemanagement sowie die Freigabe von Wartungsaufträgen und die Rechnungsstellung zu vereinfachen. Für Bahnnetzbetreiber können diese Daten für das Qualitätsmanagement und eine vorausschauende Instandhaltung genutzt werden, z.B. für die Ermittlung des Zustands von Schienenwegen, um abschätzen zu können, wann eine Wartung fällig wird.
Die Herausforderung
Bereits in der Anfangsphase hatte Goldschmidt gemeinsam mit einer Partnerfirma eine digitale Plattform bereitgestellt, die in ihrem Funktionsumfang gegenüber den Lösungen der Konkurrenz hervorstach. Aber nach einiger Zeit verlangsamte sich das Entwicklungstempo und Produktionsdeployments wurden zunehmend komplizierter.
Der Application-Stack enthielt ein Angular-Frontend mit einem Serverless Backend mit etwa 100 AWS-Lambda-Funktionen sowie DynamoDB und MariaDB als Datenbanken.
An dieser Stelle sollen kurz die Vor- und Nachteile von Serverless Anwendungen diskutiert werden.
Ein Vorteil von Serverless Anwendungen besteht darin, dass sich Entwickler’innen keine Gedanken um Serverprovisionierung machen müssen und sich ganz auf die Implementierung konzentrieren können. Das macht es zu Beginn leicht und erlaubt es, schnell Code in Produktion zu bringen. Bei den meisten Cloud-Anbietern zahlt man nur für die tatsächlich verbrauchte Rechenzeit, muss also nicht für überdimensionierte Infrastruktur aufkommen. Zudem können Entwickler’innen (oder Teams) die Programmiersprache jeder Funktion selbst wählen (wenn der Cloud-Anbieter sie unterstützt) – ein großer Vorteil, besonders, wenn man mit großen bzw. mehreren Teams an einem Projekt arbeitet. Außerdem läuft die horizontale Skalierung vollständig automatisch und wird vom Cloud-Anbieter verwaltet. Weitere Vorteile sind das integrierte Logging und Sicherheitsfunktionen (z. B. funktionsspezifische Rollen nach dem Least-Privilege-Prinzip), die von der Plattform bereitgestellt werden.
Ein Nachteil von Serverless Anwendungen ist, dass ein konsistentes Datenmodell mitunter schwer zu verwalten ist. So müssen in einer Backend-Anwendung möglicherweise verschiedene Teile der Funktionalität auf dieselben Datenbank-Entitäten zugreifen und somit Code gemeinsam nutzen. Zwar hat sich die gemeinsame Nutzung von Code auf AWS mit der Einführung von Lambda-Layers sehr verbessert, aber trotzdem sollte dies bei der Architektur berücksichtigt werden. Zudem sind Serverless Funktionen noch recht neu und die Implementierungen von Cloud-Anbietern ändern sich - wie auch die Frameworks - ständig. Das Serverless Application Framework ist zwar ein sehr effektives Werkzeug, hat sich aber zum Teil als unausgereift und unzuverlässig erwiesen – besonders bei der Einbettung und Integration von Funktionen in die sie umgebende Infrastruktur, etwa API-Gateways, S3-Buckets etc. Ein weiterer Nachteil von Serverless Anwendungen besteht, wie bei jedem verteilten System, in der erhöhten Komplexität in Bezug auf Observability. Monitoring, Tracing, Alerting und Debugging sind im Vergleich zum monolithischen Ansatz schwieriger zu realisieren, da mehr “bewegliche Teile” vorhanden sind. Auch das Testen von Serverless Architektur kann ziemlich aufwändig sein. Dies gilt zwar nicht für Unit Tests, da bei diesen nur sehr kleine Code-Fragmente isoliert getestet werden sollten. Die Durchführung von Integrationstests bei Serverless Funktionen ist dagegen komplexer, weil alles von Anfang an verteilt ist und die Integration von Funktionen auf Cloud-Anbieter spezifischen Diensten beruht, die zum Testen simuliert werden müssen.
Die Lösung
kreuzwerkers Ansatz, die Hauptprobleme der Dari®-Plattform in Angriff zu nehmen, bestand darin, eine neue Architektur zu entwerfen. Unserer Meinung nach, überwogen in diesem Fall die Nachteile der Serverless Architektur gegenüber ihren Vorteilen. Deshalb könnte man unsere Strategie von Serverless zum Monolithen betiteln (bei den meisten Artikeln im Web, ist es genau andersherum).
Zu Beginn migrierten wir die gesamte Infrastruktur nach dem Well Architected Framework, um gängige Best Practices in Bezug auf Sicherheit, Account-Trennung und Backup-Strategien zu realisieren. Dann erstellten wir eine neue, monolithische Backend-Anwendung, die wir kontinuierlich erweiterten. Dabei wurden die Kernfunktionen, etwa die Daten- und Benutzerverwaltung, aufrechterhalten, während Schritt für Schritt die Funktionalitäten der Serverless Funktionen vom Monolithen übernommen wurden. Dadurch konnten wir logische Funktionsblöcke testen und gleichzeitig das Deployment vereinfachen, indem wir bei jeder Migration eine Reihe von Deployables und Storages entfernten. Codesharing und Integrationstests sind in einer monolitischen Umgebung „natürlicher” und weniger aufwändig, als dies bei verteilten Serverless Anwendungen der Fall ist. Wir wählten für diese Anwendung eine hexagonale Architektur, um sauber zwischen Domänen-, Anwendungs-, Persistenz- und API-Schichten trennen zu können. Dies erleichterte den Austausch von Persistenzprovidern ohne Änderung der Domänenlogik und verbesserte die Testbarkeit jeder einzelnen Schicht. Mit Testcontainers konnten wir Funktionen schnell entwickeln und ihre Integration mit externen Diensten wie Datenbanken und AWS Services (LocalStack) testen. Darüber hinaus erhöhten wir anhand von End-to-End-Tests mit Cypress die Zuverlässigkeit des Systems und spürten Fehler auf, bevor sie in die Produktion kamen.
Wir bei kreuzwerker haben CI/CD für alle Deployables und Infrastructure as Code als Best Practice etabliert und übernahmen diese Praxis natürlich auch für die Dari®-Plattform. Zu Beginn unserer Zusammenarbeit hatte die Konsolidierung der Code Repositories gerade erst begonnen. Wir fassten die zunächst über 100 Code Repositories zu etwa 20 zusammen und erstellten entsprechende Build-Jobs und Deployment-Pipelines. So konnten wir jede Codeänderung automatisch deployen und innerhalb von 20 Minuten ein vollständiges Produktionsdeployment durchführen.
Zusätzlich etablierten wir ein Monitoring technischer und geschäftlicher Leistungskennzahlen (Key Performance Indicator - KPI) anhand von Metriken und Logs und führten informative Dashboards und Alerts ein.
All dies wurde parallel zur Featureentwicklung umgesetzt, so wurden z.B. gleichzeitig neue Geräte in die Dari®-Plattform integriert.
Das Ergebnis
Dari® ist eine spezialisierte Plattform, die keine hohen Skalierungsanforderungen stellt und an der auch nicht mehrere Engineering-Teams gleichzeitig arbeiten. Aus diesen Gründen kamen hier die Vorteile der Serverless Architektur nicht wirklich zum Tragen.
Deshalb haben sich die Einführung automatisierter CI/CD-Pipelines und die schrittweise Migration von einer Serverless zu einer monolithischen Architektur als gute Investition erwiesen. kreuzwerker konnte somit Entwicklungszyklen und Produktionsdeployments beschleunigen und das Testen optimieren, während gleichzeitig neue Funktionen implementiert wurden. So gab es am Ende große Zufriedenheit auf beiden Seiten – bei den kreuzwerkern und bei unserem Kunden.
Goldschmidt bietet weltweit eine breite Palette an Produkten und Dienstleistungen rund um Bau, Instandhaltung, Inspektion und Überwachung von Schienennetzen. Mit den Verbesserungen, die an der Dari®-Plattform vorgenommen wurden, ist eine solide Grundlage für die Digitalisierung dieser Produkte und Dienstleistungen geschaffen worden. Im Ergebnis wird dies zu smarteren, wirkungsvolleren und zukunftsfähigeren Produkten führen – und zu mehr Kundenzufriedenheit.
kreuzwerkers technische Expertise sowie die Infrastruktur und Managed Services von AWS werden diese Vision auch weiterhin befördern.