Microservices – von Menschen gemacht

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.

Microservices – nicht ohne die richtige Infrastruktur

Das optimale System-Design

Microservices – nicht ohne die richtige Infrastruktur

11.04.18 - Microservices können aller Vorteile zum Trotz die grundlegende Infrastruktur komplexer machen, denn sie setzen einen höheren Automatisierungsgrad und eine operationelle Reife voraus. Wie also sieht eine ideale Infrastruktur für Microservices aus? Und wie betreibt man eine Microservice-Architektur? lesen

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.

Microservices – Ein Einstieg in die Praxis

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

Microservices – Ein Einstieg in die Praxis

17.01.18 - Viele Unternehmen wollen monolithische Anwendungen umgestalten und Microservice-Architekturen für mehr Agilität und Skalierbarkeit aufbauen. Doch wie gelingt der Einstieg ins Thema Microservices? Nach welchen Prinzipien sollte man arbeiten? Was sind die Erfolgsfaktoren und wo liegen die Fallen? Ein Leitfaden liefert erste Anhaltspunkte. lesen

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.

Best Practices zu Microservice-Design, Logik und APIs

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

01.02.18 - Wie sieht gutes Microservice-Design aus? Wenn Micro klein ist – wie klein sind dann die Services? Wie können APIs und Frameworks dafür aussehen? Was kann eine lose Kopplung gefährden? Und wie stellt man Datenpersistenz sicher? Ein Blick auf die Entwicklung aus einer System-Perspektive. lesen

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?

Kleine Services für schnelle Ergebnisse

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

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

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