Agile Softwareentwicklung mit Microservices

Organisation

Die Appentwickler der Handelskette verteilen sich nicht klassisch-horizontal auf Teams etwa für Backends, Frontends, Middleware, sondern vertikal, das heißt, eine Arbeitsgruppe entwickelt alle Schichten eines Funktionsbausteins.

Wenn an einer großen Applikation zu viele Entwickler parallel arbeiten, gehen Fokus und Verantwortung verloren. Der einzelne Entwickler kann nicht mehr alle fachlichen Aspekte von vorne bis hinten durchdenken. Bei Modulen aus Microservices hingegen bleibt dies möglich. Wenn Backend-Entwickler komplizierte Schnittstellen abliefern, auf denen Frontend-Entwickler aufsetzen müssen, ist im Wortsinn Ärger programmiert.

Das klassische Modell der horizontalen Schichtung der Apps und Teams hat ausgedient. Heute schneidet man beide vertikal entlang funktional vollständiger Module, die sich in Microservices aufteilen. So verstehen die Entwickler den Sinn und Zweck der App besser, kommen mit der Arbeit schneller voran, es entstehen weniger Schnittstellen zwischen Teams, die aus Microservices zusammengesetzte App lässt sich leichter warten.

Methoden und Tools

Wie gut und schnell Entwickler arbeiten, hängt primär von den verfügbaren Methoden und Werkzeugen ab. Einen entscheidenden Anteil am Projekterfolg hat die laufende Integration (Continuous Integration, CI) und Auslieferung (Continuous Delivery, CD) der Microservices. Bei der CI werden die iterativ entwickelten Beiträge des Teams automatisiert in die Gesamtapp eingefügt, ihre Funktion und das Zusammenspiel dabei getestet. Continuous Delivery heißt, nach jeder Programmierrunde den Zwischenstand auszuliefern, um den produktiven Einsatz der Software zu beschleunigen, Feedback der Nutzer einzuholen und die App iterativ zu optimieren.

Die ganze Softwarepipeline muss automatisiert sein. Jedes Rollout kostet Zeit und Geld. Die Entwickler wenden sich an die IT-Zentrale, Tickets für das Rollout werden angelegt und abgearbeitet, manchmal wartet das Team Stunden oder Tage darauf, dass der Kollege in der Zentrale einen Knopf drückt. Frustrierend. Das braucht niemand. Hier schont eine Automation des Rollouts das Budget – und die Nerven!

Wichtig ist auch eine Deployment-Governance, ein Verfahren, das sämtliche Änderungen erfasst und den aktuellen Stand der App verbindlich dokumentiert. Also im Wesentlichen ein Releasemanagement inklusive Festlegung des Funktionsumfangs und Versionskontrolle.

Nur wenn sich jede Änderung an der App im Detail nachvollziehen lässt, wissen wir bei Problemen im Echtbetrieb, wo die Fehleranalyse ansetzen sollte.

Hochgradige Automation rationalisiert nicht nur die Verteilung der Software, sondern auch die Infrastruktur, auf der die App läuft. Die bevorzugte Methode, neue Software schnell und sicher einzusetzen, ist der Betrieb im virtuellen Container, kurz Containerisierung oder Containering genannt.

Das Rollout sollte die Software und die Infrastruktur, auf der sie aufsetzt, umfassen. Das anzuwendende Verfahren heißt Infrastructure as Code oder programmierbare Infrastruktur. Eine Virtualisierung mit Containern hat nur Vorzüge, keine Nachteile. Das Unternehmen behält seinen Softwarestack im Griff, die einzelnen Entwicklungsteams können ihre Rollouts optimal unterstützen. Ein Container enthält alles, was man dazu braucht, von den Umgebungsvariablen über Bibliotheken und die Java-Version bis zur Laufzeitumgebung.

In Betrieb gehen darf eine Software allerdings nur mit einem strengen Monitoring und automatischen Meldungen bei kritischen Zuständen.

Wenn wir einen Geschäftsprozess mit mehreren Microservices abbilden, müssen wir im Detail wissen, wie das Zusammenspiel klappt. Das ist nicht einfach. Dazu brauchen wir Metriken sowohl für den Gesamtprozess wie für die einzelnen Microservices. Nur die Services zu messen und zu analysieren, genügt nicht. Wir müssen den Gesamtablauf als Kette aus Microservices überwachen.

Jedes Entwicklungsteam muss seine Microservices während der gesamten Lebensdauer selbst überwachen. Diese Verantwortung darf man niemals an eine zentrale Stelle abgeben. Was man delegieren kann, sind die Infrastrukturaufgaben, also etwa: Welches Tool verwenden wir zum Monitoring, wer setzt das Tool auf, wer überwacht es? Solche Aufgaben sind in einer Zentrale sogar besser aufgehoben, zumal diese mit Vorgaben für Effizienz in den Teams sorgt.

Die verbreitete, von manchen Quellen empfohlene zentrale Speicherung und Analyse von Logdaten zur Prozesskontrolle erachtet unser Gesprächspartner als weniger relevant. Allerdings muss ein mit Microservices abgebildeter Fachprozess anhand sogenannter Correlation- IDs in seinem Ablauf verfolgbar bleiben.

Erfahrungsgemäß sind Fehler in verteilten Prozessen mit dem zentralen Logsystem allein kaum zu finden. Bei dessen Analyse zeigen die Teams wieder mit den Fingern aufeinander. Selbst wenn das Logsystem mit Correlation-IDs arbeitet, verteilt sich das IT-Wissen auf die unterschiedlichen Teams und es herrscht eine gewisse Scheuklappenmentalität.

Dennoch erweist sich ein zentrales Logging als nützlich. In kompetenter Hand hilft es, den personellen Aufwand bei der Fehleranalyse zu minimieren. Hier sind dann aber eher Fachexperten gefragt als Entwickler. Doch auch wenn sich Fehler damit schneller orten und beheben lassen, heißt das nicht unbedingt, dass sich deswegen das ganze Entwicklungsprojekt beschleunigt.

Arbeitskultur

Eine durchgängig agile Arbeitskultur fördert eine schnelle, passgenaue Softwareentwicklung. Die Vorzüge des agilen Arbeitens lassen sich aber auch auf Teamebene verwirklichen.

Zum agilen, autonomen Arbeiten braucht man interdisziplinäre Teams. Nur dann kann jedes Team einen vollständigen, runden Beitrag abliefern. Zudem müssen sich Teams weniger untereinander abstimmen.

Kleine Teams sind ideal, zumal dies einer Polarisierung innerhalb einer größeren Abteilung vorbeugt.

Bei kleinen Einheiten sinkt der Projektmanagement-Aufwand. Die Teams arbeiten autonom, beim Rollout sind weniger Interdependenzen zu beachten. Hier kommt es darauf an, eine Methodik zu wählen, die eine agile Zusammenarbeit und Skalierung unterstützt. Ob man sich für Scrum of Scrums entscheidet, für SAFe, LeSS oder das Spotify-Modell, ist im Grunde egal. Hauptsache, man verfügt überhaupt über Strukturen zur Zusammenarbeit. Natürlich werden einzelne agile Teams oder Projekte in konservativ geführten Unternehmen immer wieder gegen Wände laufen. Manche werden mit starren Strukturen und Eckpunkten hadern. Das kostet Energie, bremst die Softwareentwicklung, reibt die agilen Teams auf. Trotzdem lässt sich Software auch in einer traditionellen Arbeitskultur agil entwickeln. Früher oder später werden weitere Ressorts und schließlich das ganze Unternehmen agil arbeiten wollen. Oft ist es sogar besser, klein anzufangen und eine Abteilung nach der anderen zu transformieren.

Freiheit

Agile Softwareentwicklung heißt, den Teams weitgehend freie Hand zu lassen. Doch wo liegen die Grenzen dieser Freiheit? Erstreckt sie sich auch auf die Wahl der Entwicklungsumgebung, Frameworks und Tools? Entscheidend sind hier die Zeit und die Kosten, die anfallen, bis ein neuer Entwickler produktiv arbeitet.

Ein Entwickler muss vom ersten Tag an jederzeit in der neuen Systemumgebung arbeiten können. Unternehmen sollten messen, wie lange es bei ihnen dauert, bis ein neuer Kollege die erste Codezeile geschrieben hat. Gut wären maximal fünf Minuten. Dazu muss die IT-Zentrale einiges tun. Sie muss standardisieren, auch die Entwicklungsumgebung, was nicht jedem passen wird, weil es die Wahl der Arbeitsmittel einschränkt.

Das Betriebssystem des Programmierrechners darf keine Rolle spielen. Der Entwickler sollte nur einen Docker-Container mit der Arbeitsumgebung auf seinem Rechner installieren müssen, bevor er loslegt. Nur dann ist er vom Rechner und Plattformen unabhängig.

Auch die Toolsets sollten vorgeschrieben sein. Damit erspart man sich manche Diskussion über bevorzugte Methoden und Sprachen. Die Standardisierung erhöht die Betriebssicherheit nicht nur aus technischer, sondern auch aus rechtlicher Sicht. Dieses Kriterium ist bei intern entwickelter Software zentral.

Bei der Technik sollte sich die Freiheit darauf beschränken, etwa zwischen einer relationalen Datenbank, einem Document-Store, einer NoSQL-Datenbank oder einer Big-Data-Bank zu wählen. Aus dem breiten Spektrum der Optionen sollte die IT-Zentrale jeweils eine einzige bereitstellen. Passend zur Funktion eines Microservices legt das Team die Art der Persistenz der darin verarbeiteten Daten fest und nutzt dann die dafür vorgegebene Option. Geht es aber darum, ob ein Team in Java, Scala oder Python programmiert, habe ich eine dezidierte Meinung: nein zur freien Wahl der Programmiersprache je Microservice.

Es muss im Unternehmen fertige Softwarestacks geben, auf denen die Entwickler geschult sind und über die sie sich austauschen. Die Wahl einer bestimmten Ausprägung des Stacks kann man dem Team überlassen.

Sogar Frameworks und Bibliotheken würde ich vorgeben. Zumindest sollte die Auswahl einer IT-Governance unterliegen. Ich bezweifle, dass den Entwicklerteams sämtliche Rechtsfolgen klar sind, die sich aus der Wahl einer Bibliothek ergeben können. Es gibt zu viele Lizenzmodelle. Wer nicht aufpasst, verpflichtet sich mit der Wahl der Bibliothek zur Veröffentlichung des Quellcodes aller damit entwickelten Apps. Das Unternehmen braucht also wenigstens einen Prozess zur Freigabe und Kontrolle der Bibliotheken und anderer Arbeitsmittel.

Vorgaben müssen an zentraler Stelle hinterlegt sein. Im Grunde ist die Entwicklung, Pflege und Durchsetzung interner Standards ein Vollzeitjob. Entscheidungen über solche Vorgaben treffen Gremien aus Vertretern der davon betroffenen Teams, sogenannten Gilden, in einem offenen Prozess. Allerdings ist auch klar, dass man nicht zu jedem potenziellen Problem eine Stackvariante vordenken kann.

Vorteile der Standardisierung:

Je kleiner die Auswahl an Methoden und Tools, desto kürzer die Einarbeitung und desto routinierter der Umgang damit. Zudem können die Teams einander kurzfristig verstärken, wenn alle technisch auf demselben Stand sind. Auch Schulungen lassen sich leichter organisieren. Experimentiert ein Team indes im Alleingang mit alternativen Ansätzen, produziert es bald Insellösungen, die nur unter größtem Aufwand in die Arbeit der anderen zu integrieren sind.

Fazit

Die Projekterfahrung unseres Gesprächspartners in der agilen Softwareentwicklung hebt sich in einigen Punkten von der „reinen Lehre“ aus der Fachliteratur ab. Im Umfeld des Experten hat sich eine straffere Struktur bewährt, die die Wahlfreiheit der Entwickler zugunsten einer höheren Standardisierung ein Stück weit beschneidet. Inwieweit sich dieses Modell für andere Unternehmen eignet, wäre von Fall zu Fall durch eine Bestandsaufnahme und Bedarfsanalyse zu klären.

Wir danken unserem Gesprächspartner für die interessanten Einblicke.

Das Gespräch führten unsere Experten für agile Softwareentwicklung mit Microservices Claus Ried und Dirk Siegel.