Microservices – von Menschen gemacht Tipps für Microservice-Development-Teams

Microservices entwickeln sich nicht von alleine – sie werden von Menschen gemacht. Doch wie muss das entsprechende Arbeitsumfeld aussehen? Welche Teamgrößen, welche Kommunikationswege haben sich bewährt? Und was müssen die Software-Ingenieure können? Ein Blick auf eine Technologie aus einer sehr menschlichen Perspektive.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

CA Deutschland GmbH

Mit den prinzipiellen Eigenschafen, institutionellen Voraussetzungen und technischen Designaspekten von Microservices haben wir uns in den letzten Artikeln dieser Serie beschäftigt. Nun werfen wir nun einen Blick auf organisatorische und konzeptionelle Prinzipien der Teams.

Das optimale System-Design

Microservices – nicht ohne die richtige Infrastruktur

Die Services hinter der Microservice-Architektur mögen klein sein, aber der Ansatz selbst zwingt dazu, groß zu denken. In einem Microservice-System spielt alles eine Rolle: die Architektur mit Elementen wie Design und Service-Koordination, die Organisationsstruktur, die Zusammensetzung der Entwicklerteams und ihre Arbeitsweise, aber auch Fehler-Handling und Arbeitsprozesse. Und natürlich gibt es für all diese Bereiche auch Best Practices.

Das optimale Team

Eine wichtige organisatorische Voraussetzung für Erfolg ist die richtige Kultur – also gemeinsame Werte und Überzeugungen. Dazu zählen eine offene Kommunikation, eine strikte Ausrichtung an einem gemeinsamen Ziel und Offenheit gegenüber Innovation und Veränderung.

Ein guter Ansatz für die Entwicklung von Microservices ist es, die Struktur des Outputs als direkte Reflektion der Teamstruktur zu betrachten – eine Folgerung aus dem alten „Conway’s Law“. Die Idee ist, dass bessere Teamstrukturen besseren Code – in diesem Fall Microservices – liefern. Es gilt also, ein paar Grundprinzipien zu beachten:

• Das Team darf nicht zu groß sein, denn analog zur Zahl der Menschen steigt der Kommunikationsbedarf. Stockt man ein Team auf, um ein Projekt voranzutreiben, so erreicht man oft den gegenteiligen Effekt. Bewährt haben sich Development-Teams aus fünf bis zwölf Personen.

• Teams, die selbständig arbeiten und selber entscheiden können, sind schneller, leisten mehr und können skalieren. Natürlich brauchen sie einen Rahmen, aber innerhalb dieser – weit gesetzten – Grenzen sollten sie frei agieren können.

• Die Rollen im Team müssen klar verteilt sein. Wer ist der Projektverantwortliche, wer Architekt oder Entwickler, wer ist für Qualitätssicherung oder Betrieb zuständig?

• Teams brauchen halbwegs freie Hand bei der Auswahl der Tools. Es hat sich bewährt, ihnen die Wahl aus einer vorselektierten Tool-Liste (Entwicklungstools, Support Libraries, Configuration Utilities etc.) zu geben oder aber die Möglichkeit, ihre Tools selbst zu entwickeln.

Teams und Tools in Aktion

Microservices zu entwickeln hat wenig mit der klassischen Organisation nach Projekten zu tun. In einem Projekt arbeiten Teams für eine bestimmte Zeit an einem definierten Problem. Ist das Projekt abgeschlossen, werden den Spezialisten neue Aufgaben und neue Teams zugeordnet – mit der Folge, dass das Know-how rund um das Projekt dahinschmilzt und Veränderungen immer schwieriger werden.

Was sich bei der Microservice-Einführung bewährt hat

Microservices – Ein Einstieg in die Praxis

In einer Microservice-Organisation läuft das anders. Ein Team verantwortet eine Komponente im System, solange es sie gibt. Sie wird laufend verbessert, angepasst und aktualisiert. Diese schrittweise Weiterentwicklung sorgt nicht nur für hohe Qualität und Innovation. Die Verantwortlichkeit dafür schafft auch Motivation – und der Erfolg gibt weiteren Schub. Denn wenn Development und Operations zusammenarbeiten, dann ist Code einfach umsetzbar.

Eine Cloud-Infrastruktur erleichtert die schnelle Bereitstellung und das automatisierte Deployment. Container garantieren hohe Portabilität und Heterogenität. Die Middleware für Data Storage, Integration, Sicherheit und Operations sollte Web-API unterstützen, um Automatisierung und Discovery zu ermöglichen. Sie sollte aber auch offen sein für dynamische, dezentralisierte Distribution.

Die idealen Programmiersprachen sind ebenfalls API-freundlich, gleichzeitig aber auch funktional und passen zum Know-how im Unternehmen. Developer Tools machen es den Entwicklern leichter, setzen aber auch den Rahmen, damit der neue Code auch umsetzbar ist.

Neue Features werden in kontrollierter Abfolge ausgerollt, damit ihre Auswirkungen auf das restliche System überschaubar bleiben. Der Einsatz von Discovery Tools und die zentrale Registrierung von Services durch sie ermöglicht es den Teams, ihre eigenen Services an anderer Stelle laufen zu lassen, ohne das Funktionieren des Codes anderer Teams zu gefährden.

Die Menschen hinter dem Code

Es ist für viele nicht einfach, richtig agil zu arbeiten, denn es setzt nicht nur Offenheit, Kommunikationsfreudigkeit und Neugier voraus, sondern auch ein gutes Maß an Chaos-Resistenz. Statt strukturiert an einem Wasserfall-Projekt zu arbeiten, muss ein Developer immer wieder springen.

Das sieht dann so aus, dass sie kleine Releases testen, andere entwickeln und sich dabei immer an den dynamischen Geschäftsproblemen, Systemanforderungen und externem Systemdesign orientieren. Dazwischen kommen Meetings, Planungs-Sessions und Compliance-Checks. Und bei alledem sollte man noch auf dem Laufenden bleiben, was neue Technologien, aktuelle Tools, Branchentrends und Standards betrifft.

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

Die Profile im Team sehen entsprechend sehr unterschiedlich aus. Kenntnisse im Bereich API-Design und –Management, verteilte Applikationen, Containerisierung (v.a. Docker) und Container Management sind unabdingbar. Darüber hinaus gibt es einige sehr nützliche Qualifikationen wie etwa Wissen um test- oder verhaltensbasierte Entwicklungsansätze sowie Erfahrung mit Middleware Technologien und Cloud-Lösungen.

Das Know-how sollte aber auch über Tech-Wissen hinausgehen: Ansätze wie Value Stream Mapping helfen, die Abläufe in der Wertschöpfung zu verstehen und sie können einen Hinweis geben, wo Veränderungen effizient und wenig schmerzhaft sind.

Agilität für alle

Eine Microservices-Architektur ist niemals fertig und eine ideale Lösung gibt es ebenso wenig wie eine ideale Qualifikation. Allerdings: Ideale Teams kann es durchaus geben – Teams, die mit großer Dynamik auf Veränderungen reagieren. Doch ein dynamisches Team alleine reicht nicht. Agilität muss im ganzen Unternehmen stattfinden und die Ressourcen müssen zwar agil, aber dauerhaft verfügbar sein.

Georg Lauer

Moderne Softwareunternehmen haben bereits einige dieser organisatorischen Verschiebungen in ihre Prozesse integriert. Es geht nicht nur darum, neue Technologien oder Werkzeuge für die Software-Entwicklung zu übernehmen, es geht im Wesentlichen darum, die Kultur des Arbeitens in den Unternehmen zu verändern. Und Microservices sind der Anfang – in einem bestimmten, essenziellen Bereich.

* Georg Lauer ist als Senior Principal Business Technology Architect bei CA Technologies tätig.

Kleine Services für schnelle Ergebnisse

Microservices – Neue Geheimwaffe oder SOA-Remake?

(ID:45186939)