Suche
Experten-Check Teil 1

Microservices im Experten-Check: Warum eigentlich Microservices?

Melanie Feldmann
shutterstock_338320208

© Shutterstock / Login

Was ist eigentlich der Sinn von Microservices, einer Continuous-Delivery-Pipeline und dem ganzen Rest? Acht Microservice-Experten, Autoren des Java Magazins und Sprecher auf den Microservice Days der JAX 2016, bringen in dieser Serie auf den Punkt, warum das Konzept der verteilten Anwendungen so genial ist. Außerdem zeigen sie auf, wo die Knackpunkte liegen und ob das ganze Brimborium um den Kulturwandeln gerechtfertigt ist.

Was ist der wichtigste Vorteil von Microservices?

Uwe Friedrichsen: Sie setzen das Konzept der organisatorischen Autonomie auf Architekturebene fort.

Alexander Heusingfeld: Im besten Fall deckt ein Microservice fachliche Anwendungsfälle ab, die eine hohe Kohäsion haben. Das erlaubt Fokussierung sowohl beim Service als auch bei den Personen, die den Service betreuen.

Jörg Müller: Auf ein Wort zusammengefasst: Geschwindigkeit. Es ist sehr einfach einen neuen Service zu erstellen. Altlasten können weitgehend ignoriert werden. Dies wiederum lädt dazu ein, zu experimentieren. Schließlich kann jede Entscheidung die innerhalb eines Services getroffen wird schnell geändert werden. Dies gilt selbst für grundlegende Architekturentscheidungen. Im Zweifel ist ein ganzer Service schnell neu geschrieben. Am Ende sorgen diese Möglichkeiten einfach für mehr Produktivität und Spaß beim Entwickeln.

Die Microservice-Experten

friedrichsen

Uwe Friedrichsen, CTO bei codecentric

heusingfeld_alexander_sw

Alexander Heusingfeld, Senior Consultant bei innoQ

joerg_mueller_mittel_13f34

Jörg Müller, Senior Software Engineer und Manager bei Hypoport

schwartz_alexander_wp

Alexander Schwartz, Principal IT Consultant bei msg systems

tilkov_stefan

Stefan Tilkov, Geschäftsführer und Principal Consultant bei innoQ

Stefan Toth

Stefan Toth, Softwarearchitekt bei embarc

Oliver Wehrens, Chief Architect bei Deutsche Post E-Post Development

Eberhard Wolff, Fellow bei innoq

Alexander Schwartz: Wartung und Weiterentwicklung erfordern, dass sich Entwickler in den Code einarbeiten. Bei Microservices fällt dies leichter: Jeder Microservice hat für sich eine überschaubare Anzahl an Bibliotheken, maximal eine Datenbank und ein konsistentes Programmiermodell. Voraussetzung dafür ist jedoch, dass das Single-Responsibility-Prinzip gilt. Frei nach Robert C. Martin: Es sollte nie mehr als einen Grund dafür geben, einen Microservice zu ändern. Um dies einzuhalten hilft eine Architektur, die sich an der Fachlichkeit orientiert. Dies verhindert, dass für eine fachliche Anforderung übermäßig viele Services geändert werden müssen. Ein Ansatz des Domain Driven Designs ist dafür gut geeignet.

Stefan Tilkov: Die Möglichkeit, Entscheidungen in einem klar abgegrenzten Bereich im Sinne eines lokalen Optimums treffen zu können.

Stefan Toth: Aus meiner Sicht die Möglichkeit in kleinen Kontexten zu arbeiten gepaart mit der Fehlertoleranz dieser Systeme. Das schreit nach guter Time-to-Market und Innovationsfähigkeit.

Oliver Wehrens: Für uns ist die Unabhängigkeit der Teams der größte Vorteil. Es gibt klare Zuständigkeiten und der Abstimmungsaufwand ist deutlich geringer. Technologisch sind wir damit auch deutlich flexibler. Die kleinere – und hoffentlich verständlichere – Codebasis ist ein weiterer Pluspunkt.

Eberhard Wolff: Sie ermöglichen eine weitgehend unabhängige Entwicklung von Microservices in getrennten Teams und so eine höhere Geschwindigkeit bei der Umsetzung von Anforderungen.

Was ist die größte Herausforderung bei Microservices?

Uwe Friedrichsen: Neben den Veränderungsprozessen im Unternehmen ist auf technischer Ebene aus meiner Sicht die “Production Readiness” das größte Problem. Microservices ergeben ein verteiltes System mit vielen Bausteinen, das nur zuverlässig funktioniert, wenn man entsprechenden Aufwand in Themen wie Deployment- und Konfigurationsautomatisierung, Monitoring, Resilience, Discoverability, Choreographie, usw. steckt.

Alexander Heusingfeld: Der Komponentenschnitt sowie der Betrieb haben sich als Herausforderungen erwiesen. Ersteres hängt damit zusammen, dass oft ein Komponentenschnitt gewählt wird, welcher der Organisationsstruktur entgegensteht. Dies führt zu Schwierigkeiten. Die Herausforderung im Betrieb besteht darin, dass man versucht ist, die vollständige Übersicht über alle Microservices zu erlangen. Bei großen Deployments kann dies eine beachtliche Landkarte werden. Wenn man sich stattdessen auch bei der Überwachung der Microservices auf die Geschäftsfälle konzentriert, stellt man fest, dass manche Kommunikationswege kritischer sind als andere und man getrennte Landkarten erstellen kann.

Jörg Müller: Die Infrastruktur, um schnell neue Services zu erstellen und in Produktion zu bringen, ist vermutlich bei den Wenigsten vorab vorhanden. Das richtige Maß für diese Infrastruktur zu finden ist nicht einfach. Man kann sich leicht im Aufbau einer perfekten Infrastruktur verzetteln. Dies kann bis zu dem Punkt gehen, an dem das Business berechtigt die Frage stellt, ob die Investition in Microservices überhaupt gerechtfertigt ist. Gleichzeitig ist aber ein Mindestmaß an Automatisierung notwendig, damit sich der Entwickler eines Microservices auf die eigentliche Funktionalität konzentrieren kann. Vermutlich ist es auch bei dieser Herausforderung sinnvoll, sich schrittweise anzunähern und bei jedem neuen Service mehr zu lernen, was das richtige Maß für die eigene Organisation ist.

Alexander Schwartz: Damit sich Services finden (Service Discovery) und sich gegenseitig robust aufrufen können (Resilience) gibt es gute technische Bibliotheken. Immer mehr Frameworks erlauben kompakte Deployments, z. B. als ein JAR. Was bleibt ist die Herausforderung, wie Daten aus anderen Services zu replizieren sind, um größere Unabhängigkeit zwischen Services zu erreichen: Event- oder Zustandsreplikation? Wie passen Deduplikation, Aufbau eines initialen Datenbestands und Konsistenz mit der geplanten Fachlichkeit zusammen? Publish-Subscribe über ein leichtgewichtiges Bussystem, oder Polling über REST? Für die Datenreplikation wünsche ich mir mehr technische Standardlösungen, sowohl auf der Seite, die Daten bereitstellt, als auch auf der konsumierenden Seite.

Stefan Tilkov: Die Durchgängigkeit durch alle Disziplinen und Organisationseinheiten ist die größte Herausforderung.

Stefan Toth: Zu akzeptieren, dass man es nicht mit deterministisch koordinierbaren Teilen zu tun hat. Statt zu standardisieren und zu zentralisieren benötigt man Tools, um das Chaos zu beherrschen. Die sind für viele Kunden neu.

Oliver Wehrens: Zu wissen wann der Service zu groß ist und bei der Aufteilung eine Vertikalisierung durch alle Schichten (Datenbank, Logik, Frontend) zu erreichen. Beachtet man dies nicht, erschafft man einen ‘Big ball of mud’.

Eberhard Wolff: Das Deployment und Monitoring aller beteiligten Komponenten ist die größte technische Herausforderung. Auf organisatorischer Ebene ist es die Autonomie der Teams, die in der Organisation auch ermöglicht werden muss.

Wie sehr beeinflussen Microservices die Organisation? Geht es ohne Organisationsänderung?

Uwe Friedrichsen: Ich denke, die Frage ist verkehrt herum gestellt. Eigentlich ermöglichen Microservices im Sinne der Umkehrung von Conway’s Law dezentrale, autonome Teams – idealerweise mit ganzheitlicher Ende-zu-Ende-Verantwortung im Sinne von DevOps. Sie setzen sie aber nicht voraus. Man kann prinzipiell Microservices auch mit anderen Organisationsformen verwenden, nur werden sie dann ihren Nutzen nicht entfalten.

Alexander Heusingeld: Das hängt stark von der vorherrschenden Organisationsstruktur ab. In jedem Fall muss man sich bewusst machen, dass Conway’s Law nicht ohne Grund in nahezu jedem Microservices-Vortrag der vergangenen Monate vorkommt. Wenn man eine Microservice-Architektur entwirft, die nicht den Kommunikationswegen der Organisation entspricht, dann wird diese Architektur nicht lange Bestand haben. Es gibt hier zwei Möglichkeiten: Entweder man entwirft die Architektur so wie man gerne die Kommunikationsstruktur im Unternehmen hätte und forciert eine Anpassung der Kommunikationsstrukturen oder die Architektur wird sich nach und nach den Kommunikationsstrukturen anpassen.

Jörg Müller: Bei uns hat die Einführung erstaunlicherweise wenig Auswirkungen auf die Organisation gehabt. Die Teams waren bereits für den gesamten Lebenszyklus des Produktes verantwortlich. Abgesehen von dieser Voraussetzung sehe ich Microservices eher als Werkzeug, um die Technologie an die Organisation anzupassen. Die fachlichen Grenzen sind oft bereits vorhanden. Durch Monolithen werden diese meistens aber ignoriert.  Dann wirkt Conway’s Law im negativen Sinne. Mit Microservices hingegen kann die Architektur viel leichter der richtigen Organisation angepasst werden.

Stefan Tilkov: Im Prinzip sind die Änderung der Organisation weg von Projekten und horizontalen Verantwortungen hin zu einer Produktorganisation, die vertikal geschnitten ist, unabhängig von Technik. Genauso lassen sich Microservices auch in klassischen Organisationen einsetzen. Auf der anderen Seite passen sie einfach außerordentlich gut zueinander, sodass es schade wäre, das eine ohne das andere zu tun.

Stefan Toth: Die Strukturbeeinflussung ist sicher spürbar aber nicht so zentral wie die Kulturbeeinflussung in Organisationen. Zentrale Steuerung, Koordination und auch Governance oder Standardisierung sind in vielen Unternehmen so tief verankert, dass es schwierig ist einfach zu starten.

Oliver Wehrens: Microservices beeinflussen die Organisation und fördern unabhängige Teams, die alleine entscheiden können, wie sie welche Themen umsetzen. Das ist für die eine Organisation eine größere Herausforderung als für eine andere.

Eberhard Wolff: Wenn Microservices die Unabhängigkeit der Teams verbessern sollen, geht das nicht ohne Organisationsänderung. Microservices haben jedoch auch andere Vorteile – beispielsweise vereinfachen sie das Deployment oder die Services können einzeln skaliert werden. Für diese Einsatzkontexte muss die Organisation nicht zwingend geändert werden.

Morgen geht’s weiter: Lesen Sie in Teil 2 des Experten-Checks, wann man Microservices nutzen sollte und wann eher nicht!

Aufmacherbild: Abstract geometrical 3d background von Shutterstock / Urheberrecht: Login

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *