Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
In dieser Folge setzt Eberhard Wolff die Reihe “Wir bauen eine Software-Architektur” fort. Nach Kontext, Qualitätsszenarien und fachlicher Aufteilung aus den ersten beiden Folgen geht es jetzt darum, wie das Reparatursystem für einen Fahrradladen die Qualitätsszenarien tatsächlich erfüllt. Das Thema Benutzerfreundlichkeit folgt in der nächsten Folge mit seiner Kollegin Aminata.
Kein Server im Laden
Ausgangspunkt ist das Szenario, dass im Shop keine IT-Experten arbeiten und das System trotzdem betrieben werden muss. Zusammen mit der Forderung, dass das System nach einem Ausfall in 30 Minuten wieder läuft, schließt Wolff einen Server in der Werkstatt aus. Seine Lösungsstrategie heißt Cloud. Ein Zuschauer wendet ein, dass das System bei einem Router-Ausfall im Laden nicht erreichbar ist. Wolff nimmt das ernst: Ein mobiler LTE- oder 5G-Router als Fallback ist günstig, ein lokaler Server dagegen teuer und schwer zu warten. Diese Abwägung gehört offen mit dem Kunden diskutiert. Bei einem Fahrradladen ist das Restrisiko vermutlich akzeptabel.
Die Deployment-Sicht als neues Artefakt
Wolff ergänzt die arc42-Dokumentation um eine Deployment-Sicht mit eigener Legende. Zwei Varianten stehen nebeneinander: ein Deployment-Monolith auf EC2-Instanzen oder je ein Container pro fachlichem Baustein auf EKS. Für die Qualitätsszenarien macht das kaum einen Unterschied, die Frage Microservices oder nicht ist hier zweitrangig. Wertvoller ist ein anderer Fund: Die Cloud muss mit dem Kassensystem und dem Rechnungswesen im Laden kommunizieren. Ob das geht, ist offen und damit ein Risiko, das die ganze Strategie kippen kann. Ein Kassenproxy im Laden wäre eine mögliche Antwort.
Was die SLAs von Amazon wirklich zusagen
Das Szenario mit 99 Prozent Verfügbarkeit zwischen 9 und 18 Uhr klingt harmlos, bis man die SLAs liest. EC2 und EKS versprechen 99,99 Prozent im Monat, aber ein Ausfall zählt erst, wenn mehr als eine Availability Zone ausfällt. Daraus folgt etwas Konkretes: mindestens zwei EC2-Instanzen hinter einem Elastic Load Balancer oder mehrere Container-Instanzen im Kubernetes-Cluster. Und selbst bei einem Verstoß gibt es nur eine Dienstgutschrift, keinen Schadensersatz. Für die Daten setzt Wolff auf RDS mit einer relationalen Datenbank. Der geforderte Support zwischen 7 und 24 Uhr verlangt allerdings Rufbereitschaft, und das wird keine Entwicklerin übernehmen.
Mandantenfähigkeit gegen You Ain’t Gonna Need It
Das System soll später als SaaS-Lösung anderen Fahrradläden angeboten werden, und der Umbau darf höchstens zwei Monate und 20 Personentage kosten. Wolff hält das ohne Vorbereitung für unrealistisch und baut Mandantenfähigkeit von Anfang an ein. Flexibilität für absehbare Änderungen ist für ihn richtig, das reflexhafte “You ain’t gonna need it” der XP-Fraktion hält er für nahezu Gehirnwäsche. Aus dem Chat kommt der Gegenvorschlag, je Shop eine eigene Instanz zu betreiben. Wolff nennt das einen echten Trade-off: mehr Entwicklungskosten heute gegen niedrigere Betriebskosten später. Offen bleibt zudem, wie fremde Kassen- und Rechnungssysteme angebunden werden.
Fazit
Die Kernbotschaft ist einfach: Für jedes Qualitätsszenario braucht die Architektur eine Antwort, die man geben kann, ohne rot zu werden. Programmiersprache und Cloud-Anbieter sind dagegen beinahe beliebig. Wolff schließt die Architektur für diesen Fall ab und setzt für neue Anforderungen auf ein iteratives Vorgehen statt auf eine in Stein gegossene Lösung.
Weiterführend
Die Architektur aus dieser Folgenreihe ist als arc42-Dokumentation mit Architekturentscheidungen (ADRs) aufbereitet: https://llm-coding.github.io/fahrrad-reparatur-architektur/. Die Dokumentation wurde automatisch aus den Transkripten der Folgen 111 bis 113 erstellt und kann Fehler enthalten.