Suche
Experten-Check Teil 2

Microservices im Experten-Check: Wann man Microservices nutzen sollte und wann eher nicht

Melanie Feldmann

© Shutterstock / Login

Acht Microservice-Experten, Autoren des Java Magazins und Sprecher auf den Microservice Days der JAX 2016, geben in kurzen Statements Einblicke in ihre Praxiserfahrungen mit Microservices. Sie klären auf wann man mit Microservices lieber erst gar nicht anfängt und auf welche erste Erfolge sie zurückblicken.

Welche Voraussetzungen müssen Entwickler und ihre Unternehmen erfüllen, um mit Microservices anzufangen?

Uwe Friedrichsen: Man sollte als Organisation ein essentielles Interesse daran haben, die IT-Wertschöpfungskette von einer Anforderung bis zur Produktion massiv zu beschleunigen. Denn nur dann entfalten Microservices den erforderlichen Nutzen. Und dann sollte man bereit für harte Arbeit und jede Menge Überraschungen sein, denn Microservices sind alles andere als einfach.

Jörg Müller: Es muss möglich sein, dass ein Team den gesamten Lebenszyklus eines Microservice abdeckt. Wer den Service baut ist für ihn verantwortlich, bei der Implementierung und beim Betrieb. Das beginnt bei der Konzeption des Services und geht bis zur Rufbereitschaft. Wenn die Organisation ein solches Denken noch nicht unterstützt, weil z. B. Abteilungen und Funktionen im Vordergrund stehen, können Microservices sogar schaden. Die Reibungspunkte zwischen Abteilungen werden durch diese Architektur vervielfacht.

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 and 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: Ein Continuous Delivery, d. h. ein vollständig automatischer Prozess für das Bauen der Artefakte bis hin zur Installation der Software in den Entwicklungs-, Staging- und Produktionsumgebungen ist absolut notwendig, um effizient zu bleiben. In Produktion kann die Vielzahl von Services nur beherrscht werden, wenn sie ein einheitliches Monitoring und Logging bieten. Ein Tracing von Aufrufen über verschiedene Services hinweg ist notwendig, um Produktionsprobleme zu analysieren. Diese Kompetenzen sollte eine Organisation aufbauen, bevor sie sich auf die Expedition „Microservices“ begibt.

Stefan Tilkov: Aus meiner Sicht muss man wissen und verstehen, was notwendig ist, damit die behaupteten Vorteile auch wirklich entstehen können. Gerade die Rolle von Technologieunabhängigkeit und getrenntem Deployment kann man sehr leicht unterschätzen.

Stefan Toth: Microservices ist kein rein technisches Thema. Die Vorteile müssen geschäftlich einen hohen Stellenwert haben. Dann kann man das Thema auf allen Ebenen angehen.

Oliver Wehrens: Man sollte wissen wie die Business-Domäne ungefähr aussieht. Häufig geht mit Microservices auch Continuous Deployment einher, um Funktionalität schnell ändern zu können. Nur in diesem Gespann können Microservices ihre volle Wirkung ausspielen.

Eberhard Wolff: Die Organisation sollte die Unabhängigkeit der Teams auch zulassen und fördern. Außerdem muss genügend technologisches und architekturelles Wissen vorhanden sein, um mit der Komplexität der Microservices umgehen zu können.

Warum haben Sie mit Microservices angefangen?

Uwe Friedrichsen: Zunächst gefiel mir die Idee, austauschbare Services (Replaceable Services) zu haben, die eine überschaubare Größe haben („fits in one head“). Als ich begann, mich gründlicher mit Microservices auseinanderzusetzen, stellte ich aber schnell fest, dass sie ein essentieller Bestandteil zur Beschleunigung der IT-Wertschöpfungskette sind und seitdem sind sie für mich nicht mehr wegzudenken.

Jörg Müller: Die Arbeit an unserem Produkt wurde nach drei Jahren Entwicklung sehr zäh. Die Abhängigkeiten waren zwar durch gute Modularisierung relativ klar. Die Größe allein war jedoch ausreichend, um sowohl die lokale Arbeit in der IDE, als auch die Deployment-Pipeline unerträglich zu verlangsamen. Das Erweitern der Applikation machte keinen Spaß mehr und die Entwicklung neuer Features dauerte zunehmend länger.

Alexander Schwartz: In agilen Projekten gab es schon lange das Konzept von technischen Spikes. Microservices sind für mich die konsequente Weiterentwicklung. In den „Spikes“ genannten Experimenten prüfen die Entwickler, wie ein Feature mit neuen Technologien umgesetzt werden kann. Ist der Spike erfolgreich, ist der Kunde glücklich. Aber die Entwickler und Architekten sind unglücklich: Das Projekt hat ein eine zusätzliche Datenbank, ein paar zusätzliche Bibliotheken, oder an einer Stelle ein neues Programmierparadigma. Damit wird das Projekt schwerer wartbar, und nach und nach erodiert die Architektur. Microservices denken dies gemäß Teile-und-Herrsche-Prinzip weiter: Jeder Microservice hat für sich eine überschaubare Anzahl an Bibliotheken, maximal eine Datenbank und ein konsistentes Programmiermodell. Dadurch ist jeder Microservice für sich einfach wartbar. Dies ist für mich der entscheidende Vorteil von Microservices.

Stefan Tilkov: Microservices bieten gerade in großen Projekten eine Möglichkeit, Dinge, die wir uns immer wünschen, praktisch aber nur selten erreichen, durch explizite technische Grenzen zu erzwingen. Gleichzeitig sind sie erfrischend unabhängig von Produkten oder Anbietern und passen gut zu meiner Geschmack, der leichtgewichtige gegenüber schwergewichtigen Ansätzen vorzieht.

Stefan Toth: Weil Microservices mit vielen klassischen Ideen brechen.

Oliver Wehrens: Die Wartung von einem (verteiltem) Monolithen wurden immer schwerer. Die  Aufteilung der Services in kleinere, unabhängige Fachlichkeiten und Funktionalitäten lag auf der Hand, um den Aufwand zu reduzieren.

Eberhard Wolff: Die Prinzipien haben mich schon länger verfolgt – 2006 berichtete der Amazon-CTO auf einer Konferenz davon, dass bei Amazon Teams fachliche Dienste mit technologischer Selbstbestimmung entwickeln und betreiben. Ähnliche Konzepte haben wenig später einige meiner Kunden umgesetzt. Und bei einem Kunden habe ich eine Ablösung eines Monolithen durch kleinere Services vorgeschlagen. Die Konzepte sind also schon lange wichtig. Durch Continuous Delivery und den Fokus auf schnelle Umsetzung von Anforderungen sind sie in den letzten Jahren endgültig in den  Fokus gerückt.

Wann sollte man Microservices nicht machen?

Uwe Friedrichsen: Wenn das Senken der IT-Kosten der primäre oder einzige Treiber allen Handelns ist.

Alexander Heusingfeld: Es gibt einige Ausgangssituationen in denen ich Kunden von Microservices abraten würde. Allen voran wäre dies, wenn eine strikte horizontale Trennung zwischen den Abteilungen Marketing/Anforderungsmanagement, Entwicklung, Test oder Betrieb vorliegt. Wenn die Handover-Mentalität nicht abgeschafft werden kann, sodass Teams Ende-zu-Ende-Verantwortung für ein Feature von Anforderung über Entwicklung und Test bis hin in die Produktion übernehmen können, wird das Unternehmen mit Microservices wahrscheinlich nicht glücklich

Alexander Schwartz: Wenn nur seltene Releases der Software gewünscht sind, lohnt sich der Aufwand der Teilung in viele kleine Services in der Regel nicht. Wenn die Software nach der Entwicklung von einem möglichst kleinen Wartungsteam betreut werden soll, ist die Vielfalt von verschiedenen Technologien und Programmier-Paradigmen einer Microservice-Landschaft wahrscheinlich zu teuer.

Stefan Tilkov: Wenn sie für die Aufgabe, der man sich gegenüber sieht, schlicht Overkill wären. Ein kleines Team, dass eine überschaubare Anwendung mit geringen Anforderungen bauen muss, braucht wahrscheinlich keine Microservices.

Stefan Toth: Wenn Innovation und Skalierbarkeit gegenüber anderen Qualitätsanforderungen eine untergeordnete Rolle spielen. Wenn aus irgendwelchen Gründen keine kontinuierliche Auslieferung – zumindest in eine Testumgebung – möglich ist.

Oliver Wehrens: Wenn noch nicht ganz klar ist, was in einem Bounded Context (typischerweise Sammlung von Microservices) enthalten sein soll. Das Refactoring in einem Monolithen ist deutlich einfacher.

Eberhard Wolff: Wenn die höhere technologische Komplexität vor allem im Betrieb nicht handhabbar ist oder keine klaren Vorteile aus dem Einsatz von Microservices zu erwarten sind.

Haben Sie Ihre Ziele mit dem Einsatz von Microservices erreicht?

Uwe Friedrichsen: Microservices allein sind keine Silberkugel. Man muss sie mit anderen Konzepten wie Cloud Computing, DevOps oder Continuous Delivery verbinden, damit sie ihre volle Wirkung entfalten können. Das setzt aber größere Veränderungsprozesse in den betroffenen IT-Organisationen voraus, was aufwendig und mühselig ist – und wofür ich leider viel zu ungeduldig bin. So gesehen ist die Antwort – bislang zumindest noch – ein klares „Jain“.

Jörg Müller: Unsere wesentlichen Ziele haben wir erreicht. Die Arbeit am gesamten Produkt macht wieder deutlich mehr Spaß. Features werden erheblich schneller umgesetzt, als vorher. Damit lohnen sich auch die Investitionen, die in das Lernen der neuen Vorgehensweisen und das Einrichten der entsprechenden Infrastruktur geflossen sind.

Alexander Schwartz: Es ist noch zu früh, um dies zu beantworten. Dies wird sich erst zeigen, wenn die Software, die ich heute entwickel, zu Legacy-Software geworden ist.

Stefan Tilkov: Auf jeden Fall! Die Erfahrungen aus den Projekten, in denen wir Microservices einsetzen, sind fast immer positiv.

Stefan Toth: Ich habe schon einige Implementierungen gesehen und begleitet. Die Ziele wurden noch nicht überall erreicht. Ich kenne allerdings auch kein wirklich fertiges Microservice-System.

Oliver Wehrens: Wir sind noch nicht am Ende unserer Migration. Da, wo wir es einsetzen, liegen die Vorteile auf der Hand.

Eberhard Wolff: Einige Kunden können mit Microservices tatsächlich sehr schnell und zuverlässig Software in Produktion bringen. Sie haben auch eine weitgehende Unabhängigkeit der Teams erreichen. Bei anderen Kunden ist die Situation nicht ganz so gut, weil die notwendigen organisatorischen Änderungen nicht durchgeführt worden sind. Und natürlich müssen die Organisationen mit der Vielzahl an deploybaren Artefakten umgehen können.

Lesen Sie auch: Experten-Check Teil 1 – Warum eigentlich Microservices?

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.