Cloud-Monolith – Wie Serverless-Architektur in der Realität scheitert

Ein zentraler Grund für schlechte Architektur ist das Fehlen regelmäßiger Refactorings. Refactoring bedeutet, Code kontinuierlich zu überarbeiten und zu optimieren, ohne dabei das äußere Verhalten der Software zu verändern. Ohne diesen Prozess sammeln sich mit der Zeit sogenannte technische Schulden an: Der Code wird zunehmend komplex, schwer verständlich und fehleranfällig. Kleine Workarounds und kurzfristige Lösungen häufen sich, was letztlich zu einem unübersichtlichen und instabilen System führt.

Warum passiert das?

• Zeit- und Kostendruck: In vielen Projekten liegt der Fokus auf schnellen, kurzfristigen Lösungen, um Deadlines einzuhalten. Langfristige Maßnahmen wie Refactoring werden als „später zu lösen“ betrachtet – ein Zeitpunkt, der häufig nie kommt.
• Fehlende Architekturvision: Ohne eine klare Strategie für die Systemarchitektur werden Entscheidungen oft ad hoc und situationsbedingt getroffen. Dies führt zu inkonsistentem Design und einer schwer wartbaren Struktur.
• Unzureichende Ressourcenplanung: Refactoring wird häufig nicht als fester Bestandteil des Entwicklungszyklus eingeplant. Entwickler haben dadurch keine Zeit, bestehenden Code zu verbessern und konzentrieren sich ausschließlich auf neue Features.

Keine systemübergreifende Konsistenz

Ein weiteres Symptom schlechter Architektur ist das Fehlen einer systemübergreifenden Konsistenz. Dies tritt auf, wenn verschiedene Systeme oder Komponenten nicht harmonisch zusammenarbeiten und unterschiedliche Standards, Datenformate oder Schnittstellen verwenden.

• Unterschiedliche Technologien und Frameworks: Wenn mehrere Teams an einem Projekt arbeiten, kann es vorkommen, dass sie unterschiedliche Technologien verwenden. Ohne eine übergeordnete Richtlinie für die Architektur führt dies zu Problemen bei der Integration.
• Inkonsistente Schnittstellen: Wenn API-Designs und Datenformate nicht einheitlich gestaltet werden, entstehen Schwierigkeiten bei der Kommunikation zwischen den Komponenten. Jeder Dienst hat eigene Regeln, was zu einem schwer zu wartenden System führt.
• Fehlende Standardisierung: Systeme entwickeln sich zu einer "Patchwork"-Lösung, wenn es keine Standards gibt, die alle Teams einhalten müssen. Änderungen in einem System haben dann unvorhersehbare Auswirkungen auf andere.

Fazit: Die langfristigen Folgen

Fehlendes Refactoring und mangelnde Konsistenz führen dazu, dass ein System unübersichtlich, ineffizient und anfällig für Fehler wird. Die Architektur leidet darunter, dass Komponenten nicht klar definiert oder sinnvoll entkoppelt sind. Dies erschwert die Wartung, erschwert Erweiterungen und führt letztlich dazu, dass das System teuer und riskant zu betreiben ist. Regelmäßiges Refactoring und eine klare, systemübergreifende Architekturstrategie sind entscheidend, um diese Probleme zu vermeiden. Doch wie können solche Schwächen erkannt und behoben werden?

Das Nanoservice-Beispiel

Werfen wir einen Blick auf ein konkretes Beispiel. In diesem Fall geht es um einen Konnektor, der durch viele kleine Services auf Basis von AWS-Lambda-Zeitreihen zwischen zwei Systemen austauscht. Wir wollen uns ansehen, wieso das in diesem Fall zu kleinteilig gewählt wurde und welche Probleme daraus entstehen.

IST-Architektur

• AWS Lambda (Java)
  • Lambda-Funktion als zentrale Verarbeitungseinheit für die Datentransformation und den Datenfluss zwischen Systemen
• Feed-Service
  • ruft minütlich verschiedene Zeitreihen-Daten von einem externen System ab (Polling-Mechanismus)
  • führt die Abfragen regelmäßig aus, um aktuelle Daten zu erhalten.
• DynamoDB
  • Cache-Funktion: verwendet, um zu prüfen, ob dieselben Daten bereits verarbeitet wurden
  • Queue-Funktion: nutzt DynamoDB als Zwischenablage für neue Daten, um sie an nachgelagerte Systeme weiterzuleiten
• Publisher-Service
  • reagiert auf Events, die von DynamoDB ausgelöst werden, wenn neue Daten vorliegen
  • transformiert die Daten in das gewünschte Format
  • sendet die transformierten Daten an das Zielsystem

Auf den ersten Blick wirkt diese Architektur wie eine typische Umsetzung, die den Grundsätzen der Separation of Concerns (SoC) folgt. Ein genauerer Blick offenbart jedoch folgende Schwächen:

Hohe Kosten durch DynamoDB

• Problem: Die Nutzung von DynamoDB als Cache und Queue führte zu erheblichen Kosten durch zahlreiche Lese- und Schreibvorgänge, besonders bei großen Datenmengen.
• Auswirkung: Die Kosten stiegen mit wachsender Datenmenge, wodurch die Lösung auf lange Sicht unwirtschaftlich wurde.

Limitierung der Objektgröße in DynamoDB

• Problem: DynamoDB schränkt die Objektgröße ein, was bei großen Zeitreihen-Daten zu erheblichen Engpässen führte.
• Auswirkung: Es kam zu Datenverlusten und verlangsamter Verarbeitung, da das System nicht in der Lage war, große Datensätze effizient zu verarbeiten.

Hohe Anfragerate in System A durch unabhängige Lambda-Funktionen

• Problem: Für jede Art von Zeitreihe wurde eine separate Lambda-Funktion verwendet, die minütlich Daten abrief, was zu hoher Belastung auf der Schnittstelle führte.
• Auswirkung: Die Schnittstellenlast war schwer zu begrenzen, ohne Verzögerungen bei der Datenverarbeitung zu verursachen, da die Daten sofort verarbeitet werden mussten.

Solche Probleme bleiben oft in der Planungsphase unbemerkt, sollten jedoch spätestens während der Implementierung erkannt und durch gezieltes Refactoring behoben werden.

Herangehensweise an Redesign

In solchen Fällen ist es wichtig zu überlegen, wieso diese Probleme auftauchen und wie diese gelöst werden können.
 
Problematische Aufteilung in Nanoservices

• Zu kleinteilige Services: Die Architektur wurde in sehr kleine, spezialisierte Services aufgeteilt. Diese Nanoservices führen zu einer hohen Anzahl von unabhängigen Lambda-Funktionen, die jeweils nur für eine spezielle Aufgabe zuständig sind.
• Negative Auswirkungen: Die Vielzahl an einzelnen Services führt zu erhöhter Komplexität, erhöhtem Verwaltungsaufwand und redundanten Prozessen. Statt einer effizienten Nutzung werden Ressourcen für Verwaltung und Orchestrierung aufgewendet.

Einsatz von DynamoDB zur Trennung von Services

• DynamoDB als ungeeigneter Vermittler: DynamoDB wurde als Cache und Queue zwischen den Services verwendet, obwohl es eigentlich keine zentrale Rolle in der Architektur spielen sollte.
• Problematik: Der Einsatz von DynamoDB an dieser Stelle verursacht hohe Kosten und unnötige Abhängigkeiten. DynamoDB führt zudem zu erhöhten Latenzen und bringt Limitierungen, die die Effizienz und Flexibilität des Systems beeinträchtigen.

Zusammenfassend zeigt sich, dass der übermäßige Einsatz von Nanoservices und die ungeeignete Verwendung von DynamoDB sowohl die Wartbarkeit erschwert als auch die Betriebskosten erhöht haben. Hier wurde unnötig getrennt, was fachlich zusammengehört. Die Analyse machte deutlich, dass eine restrukturierte, lose gekoppelte Architektur mit klar definierten Verantwortlichkeiten erforderlich ist – jedoch ohne zwingende physische Trennung.

In der überarbeiteten Architektur wurde der Connector durch einen konsolidierten Microservice in einem ECS Container ersetzt, um die vorherige Fragmentierung und die damit verbundenen Probleme zu beheben.
Ziel des Redesigns: "Wir bringen zusammen, was zusammen gehört." Die zuvor in mehrere Nanoservices aufgeteilten Funktionen wurden zu einem einzigen Microservice zusammengeführt, der alle notwendigen Aufgaben zentral durchführt.

ECS Container als zentraler Microservice:

• Der gesamte Connector läuft nun in einem ECS Container (Elastic Container Service), der die Daten von System A abruft, verarbeitet und an System B weiterleitet.
• Durch die Zentralisierung im ECS Container werden die zuvor verteilten Funktionen (Polling und Publishing) zusammengefasst, was eine bessere Effizienz und Kontrolle über die Datenflüsse ermöglicht.

Vorteile des Redesigns:

• Reduzierte Abhängigkeiten und niedrigere Kosten: Die Notwendigkeit, DynamoDB als Queue und Cache zu verwenden, entfällt. Dies senkt die laufenden Kosten und verringert die Komplexität.
• Bessere Wartbarkeit und Skalierbarkeit: Durch die Zusammenführung der Funktionen in einem Microservice ist das System weniger fragmentiert und einfacher zu warten. Bei Bedarf kann der ECS Container skaliert werden, ohne dass mehrere Lambda-Funktionen orchestriert werden müssen.
• Vermeidung von Nanoservice-Overhead: Anstatt viele kleine Lambda-Funktionen für spezifische Aufgaben zu verwenden, bietet der Microservice eine klarere, kohärentere Lösung mit geringerer Latenz und einem geringeren Verwaltungsaufwand.

Feed-Komponente:

• Funktion: Die Feed-Komponente übernimmt das regelmäßige Abrufen der Daten aus System A. Sie fungiert als Einstiegspunkt, der die Rohdaten sammelt und sie für die weitere Verarbeitung vorbereitet.
• Keine Trennung der Zeitreihen. Alle werden als Paket abgeholt (da sie fachlich auch zusammengehören).
• Queue: Nach der Erfassung der Daten werden diese in eine interne Queue (z. B. eine In-Memory-Queue) gestellt. Diese Queue sorgt für eine entkoppelte Verarbeitung der Daten in der nächsten Phase.

Transformer-Komponente:

• Funktion: Der Transformer transformiert die Daten, um sie für das Zielsystem B kompatibel zu machen. Hier wird die eigentliche Datenlogik angewendet, etwa durch Datenformatumwandlungen, Aggregationen oder Filterungen.
• In-Memory-Cache: Der Transformer verwendet einen  In-Memory-Cache, um Daten zu speichern, die für die Transformation relevant sind, z. B. zur Vermeidung von doppelter Verarbeitung oder um Ergebnisse temporär vorzuhalten. Dieser Cache ersetzt die vorherige DynamoDB-basierte Cache-Lösung, wodurch die Kosten und Latenzzeiten reduziert werden.

Sender-Komponente:

• Funktion: Die Sender-Komponente ist verantwortlich für das Versenden der transformierten Daten an System B. Sie wartet auf die Daten aus der zweiten Queue und gewährleistet, dass die Daten sicher und in der richtigen Reihenfolge bei System B ankommen.
• Queue: Die Queue zwischen Transformer und Sender dient zur weiteren Entkopplung und sorgt dafür, dass der Sender asynchron arbeiten kann, wodurch die Systemstabilität erhöht wird.

Die Auswirkungen des Redesigns spiegeln sich deutlich in den Cloud-Kosten wider und verdeutlichen, warum die Umstrukturierung nicht nur technisch, sondern auch wirtschaftlich notwendig war. Vor der Anpassung führten die fragmentierte Architektur und der ineffiziente Einsatz von Ressourcen, wie DynamoDB als Cache und Queue, zu einer enormen Kostenexplosion. Jeder zusätzliche Schreib- oder Lesevorgang trieb die Betriebskosten in die Höhe, insbesondere bei wachsendem Datenvolumen.

Durch das Redesign konnte dieser Kostentreiber erheblich reduziert werden. Der Wechsel zu einem zentralisierten Microservice und die Nutzung effizienter Datenstrukturen eliminierten viele der vorherigen Engpässe. Kostenintensive Workarounds, wie das Skalieren einzelner Nanoservices oder unnötig häufige Datenabfragen, wurden überflüssig. Die optimierte Architektur reduzierte nicht nur die direkten Betriebskosten, sondern schuf auch langfristig eine stabilere und skalierbare Grundlage, die zukünftige Erweiterungen und Anpassungen erleichtert, ohne die Kosten erneut in die Höhe zu treiben.

Diese Optimierungen zeigen exemplarisch, warum technische Entscheidungen nicht isoliert betrachtet werden sollten, sondern immer auch im Kontext der Wirtschaftlichkeit und Skalierbarkeit eines Systems stehen müssen.

Betrachten wir nun das zweite Beispiel – das genaue Gegenteil des vorherigen. Während im ersten Fall eine übermäßige Fragmentierung das Problem darstellte, wurde hier auf eine Trennung vollständig verzichtet.

Die Struktur ist im Kern simpel: Eine zentrale AWS Lambda-Funktion übernimmt sämtliche Aufgaben. Sie empfängt die Daten, transformiert sie entsprechend den Anforderungen des Zielsystems und leitet sie weiter. Dabei erfüllt diese Lambda-Funktion folgende Aufgaben:

• Herkunft der Daten: Identifizierung der Quelle
• Ziel der Daten: Bestimmung, wohin die Daten gesendet werden sollen
• Datenformat: Anpassung an das erforderliche Format.

Zusätzlich wird in der Lambda-Funktion Business-Logik implementiert, die bestimmte Daten filtert oder modifiziert. Diese zentrale Ansammlung von Verantwortlichkeiten führt zu einer starken Kopplung und einer hohen Komplexität, die wir im weiteren Verlauf genauer betrachten werden.

Die aktuelle Lambda-Funktion weist eine hohe Komplexität auf, da sie mehrere Verantwortlichkeiten gleichzeitig erfüllt. Diese Überladung führt zu schwer verständlichem Code und erhöht die Fehlerrate.

Transformation Lambda:

• Split-und-Filter-Logik: 24 verschiedene Message Types werden aufgeteilt und gefiltert, bevor sie in den Inbound Bucket gelangen.
• Transformation je Nachricht und Zielsystem: 18 weitere Message Types, die transformiert werden, basierend auf Nachrichtentyp und Zielsystem
• Sende-Logik je nach Zielsystem: Die transformierten Daten werden an die jeweiligen Systeme (System A, B oder C) weitergeleitet.
• Ruft sich immer wieder selbst auf. Hohe Komplexität durch viele MessageTypes: Die Vielzahl an Message Types führt zu komplexem und schwer verständlichem Code.

Schon hier ist zu erkennen, wie kompliziert der Aufbau ist. Wir haben uns dazu entschieden, die Komponenten schrittweise zu entkoppeln.

Schritt 1

Die Lambda-Funktion fokussiert sich jetzt nur noch auf Split-, Filter- und Transformationsaufgaben. Die Sende-Logik wurde ausgelagert und wird nun von einem ECS-Container übernommen.

Vorteil:

• Lastreduktion: Die Lambda-Funktion wird entlastet, was ihre Komplexität und Ausführungsdauer erheblich reduziert.
• Spezialisierung: Jede Komponente hat klar definierte Verantwortlichkeiten, was die Wartbarkeit und Erweiterbarkeit erleichtert.

Entkopplung der Sende-Logik:

• Vorher: Die Lambda-Funktion führte die gesamte Logik aus, einschließlich Split, Filter, Transformation und Versand an die Zielsysteme (System A, B, C).
• Jetzt: Die Lambda-Funktion übernimmt nur noch die Split-, Filter- und Transformationslogik. Die Sende-Logik wird an den ECS-Container ausgelagert, was die Last auf die Lambda reduziert.

SQS-Queue als Puffer:

• Neu hinzugefügt: Die SQS-Queue dient als Puffer zwischen der Transformation Lambda und dem Sender-Container, um die Datenübertragung zu entkoppeln. Dies erhöht die Zuverlässigkeit und Skalierbarkeit, da die Daten in der Queue zwischengespeichert und vom Sender asynchron abgearbeitet werden können.

Bessere Skalierbarkeit und Wartbarkeit:

• Vorher: Die Lambda-Funktion war für alle Schritte zuständig, was sie komplex und schwer wartbar machte.
• Jetzt: Die Entkopplung durch die Queue und die Verlagerung der Sendelogik in den ECS-Container reduziert die Komplexität der Lambda-Funktion und vereinfacht zukünftige Wartungen und Erweiterungen.

Im zweiten Schritt sind wir von der anderen Seite herangegangen.

Einführung von Kafka:

• Neu hinzugefügt: Kafka wird als verlässlicher Daten-Stream für die Aufnahme von Nachrichten eingeführt. Dies ermöglicht eine skalierbare und robuste Verarbeitung großer Datenmengen, die kontinuierlich in das System gelangen. Keine synchronen Aufrufe mehr.
• Ein Consumer im ECS Container liest die Daten aus Kafka und übergibt sie an die nächste SQS-Queue zur weiteren Verarbeitung (SoC).

Aufteilung der Split-und-Filter-Logik:

• Die Split-und-Filter-Logik wird jetzt von einer eigenen Lambda-Funktion ausgeführt, die die Daten aus der SQS-Queue nach dem Kafka-Consumer empfängt.
• Dadurch wird die Verarbeitung der 24 verschiedenen Message Types klar getrennt und modularisiert, was die Wartbarkeit erhöht.

Transformation-Logik verbleibt erstmal:

• Wieder ein kleiner überschaubarer Schritt nach dem anderen.
• Dadurch sinkt das Risiko auf Produktion.

Zusammenlegung von Transformation und Splitting:

• Die Transformation und das Splitting der Daten wurden in eine gemeinsame Lambda-Funktion integriert. Dies vereinfacht den Datenfluss und reduziert die Anzahl der separaten Verarbeitungsschritte.
• Vorteil: Durch die Zusammenführung wird die Architektur schlanker, da weniger separate Komponenten verwaltet werden müssen. Die Transformationslogik wurde vereinfacht, sodass die Funktion sowohl das Aufteilen der Daten als auch die Umwandlung in einem einzigen Schritt erledigen kann. Generell waren das einfache und zusammengehörige Prozesse, die nicht getrennt werden mussten.

Reduzierung der Zielsysteme:

• System C liest jetzt direkt aus Kafka. Dadurch entfällt die Notwendigkeit, System C durch den Connector zu bedienen, was die Komplexität und Datenverarbeitungslast weiter reduziert.

Prüfung der Konsistenz von Input und Output:

• Bei jeder Änderung wurde geprüft, dass Input und Output gleich bleiben.
• Keine generischen Klassen, die durch DynamoDB-Konfigurationen angepasst werden, sorgen für bessere Unit und Integration Tests.