Ein Angebot von

Tipps für Microservice-Development-Teams

| Autor / Redakteur: Georg Lauer * / Stephan Augsten

In einer Microservice-orientierten Organisation verantwortet ein Team eine Komponente im System, solange es sie gibt.
In einer Microservice-orientierten Organisation verantwortet ein Team eine Komponente im System, solange es sie gibt. (Bild: startupstockphotos.com / CC0)

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.

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.

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.

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.

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
Georg Lauer (Bild: CA Technologies)

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.

Microservices – Neue Geheimwaffe oder SOA-Remake?

Microservices – Neue Geheimwaffe oder SOA-Remake?

05.12.17 - Microservices – der Programmieransatz wird als Geheimwaffe gehandelt, die Software schneller und flexibler macht. Kleine Codeblöcke – Microservices – statt komplexer Anwendungssilos klingt gut. Doch wie? Und … hatten wir das nicht schon mal? lesen

Red-Hat-Umfrage zu Microservice-Architekturen

Red-Hat-Umfrage zu Microservice-Architekturen

22.01.18 - Mit dem aktuellen Stand von Microservice-Strategien hat sich Red Hat im Rahmen einer Studie beschäftigt. Im Fokus standen dabei Vorteile und Herausforderungen der Mikrodienste, zu den Befragten gehörten JBoss-Middleware- sowie OpenShift-Kunden. lesen

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45205497 / Software Engineering)