Interview mit Hanna Prinz

Service Mesh und Microservices: „Wartbare Software zu schreiben, ist und bleibt offenbar ein schwieriges Problem“

Jean Kiltz

Hanna Prinz

Service Meshes und Microservices sind ein nahezu ungebremster Trend im Bereich der Softwarearchitektur. Mit der neuen Control Plane, istiod, im Service Mesh Istio kommt allerdings neuer Schwung in die Debatte darum, wie und wann diese Infrastukturmodelle angewandt werden sollten. Wir haben uns mit unserer Expertin Hanna Prinz über geeignete Anwendungsfälle, die Zukunft und die Nachteile von Microservices und Service Meshes unterhalten. Hanna Prinz ist Entwicklerin und Consultant bei INNOQ mit dem Schwerpunkt Infrastruktur und Service Mesh.

JAXenter: Was sind neben Istio für dich die wichtigsten Service Meshes auf dem Markt?

Hanna Prinz: Mit Blick auf die letzte Befragung der CNCF, einer Organisation, die die Landschaft rund um Kubernetes unterstützt, sind neben Istio auch Linkerd 2 und Consul sehr beliebte Service-Mesh-Implementierungen. Alle drei werden bereits in Produktivsystemen eingesetzt. Darüber hinaus glaube ich, dass das AWS App Mesh durch die Integration mit anderen AWS-Diensten für viele sehr attraktiv ist. Diese vier werden uns mit hoher Wahrscheinlichkeit auf absehbare Zeit erhalten bleiben. Die Unternehmen, die dahinter stehen (Google, IBM, Buoyant, HashiCorp und AWS), haben allesamt sehr viel Erfahrung mit Microservices und verteilten Systemen. Bei den jüngsten Produkten wie Maesh und Kuma bin ich mir nicht sicher, ob sie diesen Vorsprung einholen können.

JAXenter: Istio ist mit der Implementierung von istiod gerade auf eine monolithische Struktur umgeschwungen. Könnte das einen Trend in anderen Service Meshes bedeuten oder gab es da schon vergleichbares?

Hanna Prinz: Istio hat sich entschieden, aus den vielen Komponenten der Control Plane (pilot, mixer, citadel, galley) eine einzige (istiod) zu machen. Diese Control Plane konfiguriert die Proxys, die an der Seite jeder Microservice-Instanz laufen und verarbeitet Daten zum Netzwerkverkehr, die die Proxys aufzeichnen.

Die monolithische Architektur von Istio 1.5 hat bemerkenswert positive Effekte auf die Performance.

Die monolithische Architektur von Istio 1.5 hat bemerkenswert positive Effekte auf die Performance, den Ressourcenverbrauch und die Sicherheit des Service Mesh. Das kann durchaus eine Inspiration für andere Service Meshes wie Linkerd 2 sein, deren Control Plane aus mehreren Komponenten besteht. Aber nicht nur Service Meshes können sich eine monolithische Architektur zum Vorbild nehmen: Microservices sind schließlich kein Allheilmittel und Monolithen nicht immer schlecht. Es gibt gute Gründe für beides. Die wahrgenommene Beliebtheit und „großes Unternehmen X macht das so“ sind allerdings keine. Ich bin froh, dass das Team hinter Istio diesen Schritt gewagt hat und sich damit an der kritischen Diskussion zu Microservices beteiligt.

JAXenter: Worauf muss man achten, wenn man sich für ein Service Mesh entscheidet? 

Hanna Prinz: Die erste wichtige Frage ist, in welcher Infrastruktur die Anwendung läuft. Wer Services nicht oder nicht vollständig in Kubernetes betreibt, hat eine eingeschränkte Auswahl. Linkerd und Maesh sind beispielsweise ausschließlich für Kubernetes entwickelt und entsprechend gut damit integriert. Bei der Motivation, ein Service Mesh einzuführen, stehen immer die Features im Vordergrund. Häufig haben es die Teams auf die Security-Features abgesehen – allen voran das transparente und automatische beidseitige TLS (mTLS) und die automatische Verwaltung der Zertifikate. Ohne Service Mesh ist das sehr aufwendig. Viele sind auch an flächendeckendem Monitoring und dem kontrollierten Ausrollen neuer Versionen (z. B. Canary Releasing) interessiert.

Ich würde davon abraten, das Service Mesh anhand der Menge der potentiell nützlichen Features auszuwählen.

Ich würde allerdings davon abraten, das Service Mesh anhand der Menge der potentiell nützlichen Features auszuwählen. Statt dem Motto „Haben ist besser als Brauchen“ sollten hauptsächlich die Features zählen, die auf absehbare Zeit gebraucht werden. Dabei kann man sich durch Vergleichstabellen unterstützen lassen. Ich arbeite beispielsweise an servicemesh.es mit, wo es eine aktuelle und detaillierte Übersicht zu Features und Kompatibilität gibt.

Die Service-Mesh-Implementierungen setzen viele Features sehr unterschiedlich um. Deshalb würde ich im nächsten Schritt Implementierungsdetails der relevanten Features vergleichen. Nachdem die Service-Mesh-Kandidaten nach Kompatibilität, Features und Implementierungsdetails gefiltert wurden, empfehle ich, die verbleibenden praktisch auszuprobieren. Die offiziellen Tutorials sind schnell durchgearbeitet und geben einen guten Eindruck zur Interaktion und Konfiguration mit dem Mesh. Wenn Ressourcenverbrauch und Performance eine große Rolle spielen, würde ich mit den attraktivsten Kandidaten in eine Testumgebung mit der Microservice-Anwendung deployen und Messwerte wie Latenz, CPU- und Speicher-Auslastung mit dem meshfreien Deployment vergleichen. Leider machen die wenigsten Service Meshes Angaben zu Latenz und Ressourcenverbrauch und unabhängige Benchmarks veralten schnell.

JAXenter: Sind Microservices-Architekturen wirklich immer einer monolithischen Architektur überlegen?

Hanna Prinz: Definitiv nicht. In der Ausführung ist ein Monolith deutlich effizienter und damit performanter als eine Microservices-Anwendung. Wir Menschen sind ab einem bestimmten Level von Komplexität aber einfach überfordert. Das führt dazu, dass Änderungen an monolithischer Software riskant sind, was wiederum zu langen Deployment-Zyklen führt, die für Nutzer unzumutbar sind. Besonders sichtbar wird der Wert von schneller Reaktionsfähigkeit jetzt in der Corona-Krise, wo viele Unternehmen ihr Angebot anpassen. Genau darum geht es bei Microservices. Sie sollen die Komplexität für die Entwickler beherrschbar halten und es mehreren Teams ermöglichen, parallel an einer Software zu arbeiten und diese, dank minimiertem Risiko, schnell in Produktion zu bringen. Anders gesagt: Bei Microservices geht es immer um die Performance der Softwareentwickler, nicht um die der Software. Doch mit Microservices handeln wir uns Komplexität an anderer Stelle ein: bei der Infrastruktur, der Integration der Services und beim Ressourcenbedarf. Tatsächlich konnten Microservices nur so erfolgreich werden, weil wir den Betrieb mit Docker und Kubernetes automatisieren können und weil Cloud-Provider Ressourcen dynamisch bereitstellen können.

Wartbare Software zu schreiben ist und bleibt offenbar ein schwieriges Problem.

Kritische Auseinandersetzungen mit Microservices sehe ich mittlerweile nicht nur innerhalb unserer Firma, sondern auch bei Istio und auch bei großen Unternehmen wie Uber. Letztere begründen ihre Entscheidung damit, dass Microservices mittel- und langfristig zu schlecht test- und wartbar sind. Interessanterweise sind das fast die gleichen Nachteile, die man auch einem Monolithen zuschreibt. Wartbare Software zu schreiben, ist und bleibt offenbar ein schwieriges Problem.

Lesen Sie auch: Women in Tech: „Egal wie fähig oder mutig man ist, man ist auf Chancen angewiesen“

JAXenter: Was glaubst du wird 2020 und 2021 in Sachen Softwarearchitektur das große Thema sein?

Hanna Prinz: In den letzten Jahren wurden häufig die extremen Ausprägungen von Monolithen und Microservices diskutiert. Dazwischen gibt es aber ein sehr breites Spektrum, zu dem beispielsweise SCS (Self-Contained Systems) gehören. Ich denke (oder hoffe), dass es in Zukunft mehr darum gehen wird, aus dem verfügbaren Spektrum eine zu den Gegebenheiten passende, pragmatische Architektur auszuwählen. Es gibt bereits Methodik die das unterstützt. DDD (Domain Driven Design) unterstützt beispielsweise dabei, eine Brücke von fachlichen Strukturen und Begriffen zu technischen Entscheidungen zu schlagen. Ich kann mir aber vorstellen, dass sich im Bereich solcher Methodik noch mehr tut.

Als weiteres Thema sehe ich die Weiterbildung. Wir haben in der IT die sehr vielversprechende Kombination aus größtenteils interessierten Entwicklern und einem fast unerschöpflichen Angebot an Tutorials, Podcasts, Artikeln, Meetups, Konferenzen und Workshops. Diese Situation können Arbeitgeber sehr viel intelligenter nutzen, um ihre Entwickler mit den Skills auszustatten, die sie für die erfolgreiche Umsetzung der gewählten Architektur brauchen. Wie wir das intern bei INNOQ umgesetzt haben und in welchen Situationen ich gerne von einem Service Mesh abrate, habe ich in meinem letzten Blogpost beschrieben.

 

Hanna Prinz hat bei INNOQ ihre Masterarbeit über Service Meshes geschrieben. Davor hat sie Seminare zum Einstieg ins Programmieren gegeben und als Full-Stack-Developer an Apps, Front- und Backends entwickelt. Heute beschäftigt sie sich mit allen Themen im Bereich Automatisierung und DevOps wie Kubernetes, CI/CD und Service Meshes.

Geschrieben von
Jean Kiltz
Jean Kiltz ist seit März 2020 Redakteur bei Software & Support Media. Er hat Geschichte und Kulturanthropologie an der Johannes Gutenberg-Universität Mainz studiert. Danach war er beim ZDF als First-Level-IT-Support angestellt.
Kommentare

1
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Maria Lankes Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Maria Lankes
Gast
Maria Lankes

Sehr informativ und aufschlussreich.