Softwaresysteme aus Microservices entwickeln

Ein Softwaresystem kann aus mehreren Microservices bestehen, die jeweils eine fachliche Aufgabe verantworten: etwa Aufträge verwalten, Einsätze planen oder Kunden über Änderungen informieren. Jeder Dienst pflegt die Daten seines Bereichs und stellt benötigte Funktionen oder Informationen über vereinbarte Schnittstellen bereit.

Ich entwickle diese Dienste und ihr Zusammenspiel zu einer nutzbaren Gesamtlösung. Dazu gehören die fachliche Aufteilung, APIs, Ereignisse und Datenverarbeitung ebenso wie Tests, Bereitstellung und der vereinbarte Betrieb. Sie arbeiten direkt mit mir als Entwickler Ihrer Lösung.

Vorhandene Anwendungen lassen sich über individuelle Schnittstellen einbinden. Für die Umsetzung in der Cloud biete ich Cloud-native Softwareentwicklung auf AWS an. Soll ein bestehendes System schrittweise modernisiert werden, können neue Dienste zunächst einzelne Aufgaben übernehmen; dazu passt der Artikel zur Ablösung von Altsystemen.

Einzelne Bereiche unabhängig weiterentwickeln

Bei klaren fachlichen Grenzen und kompatiblen Schnittstellen kann ein Dienst separat geändert und ausgeliefert werden. Ein neuer Filter im Kundenportal muss dann beispielsweise keine neue Version der Einsatzplanung erfordern. Das erleichtert überschaubare Ausbaustufen und begrenzt die Zahl der betroffenen Komponenten.

Kapazität dort erweitern, wo sie gebraucht wird

Eine aufwendige Auswertung kann mehr Verarbeitungskapazität erhalten, während Auftragsverwaltung und Portal unverändert laufen. Voraussetzung ist, dass Dienste und ihre Datenzugänge tatsächlich ausreichend unabhängig sind. Eine gemeinsame Engstelle begrenzt auch ein aufgeteiltes System.

Unterbrechungen in einem Bereich abfangen

Arbeiten Dienste über dauerhaft speichernde Nachrichtenkanäle zusammen, kann ein Empfänger vorübergehend ausfallen und später weiterarbeiten. Beispielsweise kann die Portalansicht aktualisiert werden, während eine Kundenbenachrichtigung noch wartet. Dafür müssen Rückstau, Wiederholungen und Fehler sichtbar sein; die nötige Reaktionszeit folgt dem Geschäftsprozess.

Neue Funktionen gezielt ergänzen

Ein zusätzlicher Dienst kann auf bereits veröffentlichte Ereignisse reagieren, etwa um die Zeit zwischen Auftrag und Einsatz auszuwerten. Wenn die benötigten Informationen im Ereignis vorhanden sind, muss der Auftragsdienst dafür keine neue direkte Verbindung zur Auswertung erhalten. Ereignisformate und Zugriffsrechte bleiben abgestimmt.

Diese Vorteile entstehen durch passende Grenzen und einen geeigneten Betrieb. Der Microservices-Architekturleitfaden von Microsoft beschreibt die Möglichkeiten und den damit verbundenen Aufwand.

Der folgende Ablauf ist ein entworfenes Beispiel für einen Industriebetrieb. Ein Auftragsdienst erfasst einen bestätigten Servicetermin. Disposition, Kundenportal und Benachrichtigung sind eigene Microservices und benötigen die Terminänderung für unterschiedliche Aufgaben.

Der Auftragsdienst veröffentlicht das Ereignis „Servicetermin vereinbart“. Es enthält eine eindeutige Ereignis-ID, die Auftragskennung, den Termin und eine Vorgangsversion. Die Empfänger übernehmen diese Informationen in ihre jeweils eigenen Datenbestände oder lösen die passende Folgearbeit aus.

Das Prinzip heißt Publish/Subscribe, kurz Pub/Sub: Der Auftragsdienst ist der Publisher, also der Herausgeber. Er sendet an einen Nachrichtenkanal, das Topic. Die interessierten Empfänger abonnieren diesen Kanal als Subscriber. Der Publisher muss sie nicht einzeln aufrufen.

Auf AWS lässt sich das mit einem Amazon-SNS-Topic und einer eigenen Amazon-SQS-Warteschlange je empfangendem Dienst umsetzen:

SNS verteilt eine Kopie an jede abonnierte Queue. So können alle drei Dienste dasselbe Ereignis unabhängig verarbeiten. Mehrere Worker eines Dienstes teilen sich dagegen die Verarbeitung seiner Queue. Die AWS-Dokumentation erklärt diese Kombination als SNS-/SQS-Fanout.

Ist der Benachrichtigungsdienst vorübergehend nicht verfügbar, bleiben die Nachrichten innerhalb der vereinbarten Aufbewahrungsdauer in seiner Queue. Die anderen Empfänger können weiterarbeiten. Später kann ein Auswertungsdienst mit einer weiteren Queue hinzukommen, wenn der Ereignisinhalt seinen Bedarf abdeckt.

Zum fertigen System gehören auch die Fehlerfälle: Wiederholungen dürfen keine zusätzliche identische Kundeninformation auslösen; verspätete Ereignisse dürfen keine neueren Anzeigen überschreiben. Wiederholt fehlschlagende Verarbeitung wird über eine Fehlerwarteschlange und Monitoring sichtbar. Das Outbox-Muster hilft, eine gespeicherte Terminänderung zuverlässig zur Veröffentlichung weiterzugeben.

Der Artikel zu Event-driven und Pub/Sub vertieft diese Aufgaben. Pub/Sub beschreibt den Nachrichtenaustausch; Event Sourcing ist eine gesonderte Entscheidung darüber, wie ein Dienst seinen fachlichen Zustand speichert.

1. Ablauf und Verantwortlichkeiten klären. Wir legen fest, welche Bereiche unabhängig verändert oder skaliert werden sollen und wer verbindlich über Aufträge, Termine oder Bestände entscheidet.
2. Schnittstellen und Ereignisse vereinbaren. Ich beschreibe benötigte Daten, Zugriffsrechte und Fehlerverhalten. Sofort benötigte Antworten und zeitlich entkoppelte Folgearbeit werden passend zum Ablauf umgesetzt.
3. Einen vollständigen Ablauf entwickeln. Eine erste Ausbaustufe verbindet die benötigten Dienste durchgängig. Gemeinsam prüfen wir reguläre Vorgänge, Wiederholungen, verspätete Nachrichten und Unterbrechungen.
4. Bereitstellung und Überwachung einrichten. Automatisierte Tests und Auslieferung, Protokollierung und Monitoring machen Änderungen und Fehler über Dienstgrenzen hinweg nachvollziehbar.
5. Übergeben oder weiterbetreuen. Sie erhalten Zugang zu Quellcode, Infrastrukturdefinitionen und Dokumentation. Wartung, Fehlerbehebung und Weiterentwicklung übernehme ich auf Wunsch im vereinbarten Umfang.

Welche Cloud-Bausteine dabei sinnvoll sind, erläutert der Ratgeber „Cloud-native mit AWS: Vorteile, Kosten und Grenzen“.

Bei MOIA, VTG und Jungheinrich arbeitete ich mit verteilten Systemen, Microservices und Event Sourcing. Die Aufgaben reichten von der Entwicklung einzelner Dienste bis zur Verarbeitung großer Datenmengen und der Begleitung des produktiven Betriebs.

• MOIA: Entwicklung und Betreuung von Backend-Diensten und APIs für Preis- und Kundenprozesse, einschließlich Fahrtenhistorie und Rechnungsdownload. Als Technical Designer wirkte ich an Architekturentscheidungen mit. In meinen Projekten wurde cloud-nativ auf AWS entwickelt.
• VTG: Entwicklung von Diensten zur Verarbeitung von Telemetrie- und Sensordaten, Auswertungen und Schnittstellen für die Plattform traigo.
• Jungheinrich: Mitarbeit an der Ablösungsstrategie und Entwicklung von Diensten, Schnittstellen und Weboberflächen bei der Modernisierung des Flottenmanagements.

Diese Erfahrung fließt in die Planung Ihrer Architektur ein. Das oben beschriebene SNS-/SQS-Servicebeispiel veranschaulicht einen möglichen Aufbau und beschreibt keine konkrete Umsetzung bei diesen Kunden.