zurück zum Artikel

Der Berater und Autor Sam Newman erzählt im Gespräch mit heise Developer, wie seine Bücher entstanden sind und warum er Monolithen nicht mit Legacy gleichsetzt.

Sam Newman gilt als einer der führenden Köpfe im Bereich Microservices. Er ist als unabhängiger Berater tätig und hat zuvor unter anderem bei ThoughtWorks und einigen Start-ups gearbeitet. Heute ist er als selbstständiger Berater und Autor tätig. Sein Buch "Building Microservices" gilt als Standardwerk zu dem Thema, mit dem er sich seit gut fünf Jahren auseinandersetzt.

heise Developer sprach mit Sam Newman im Rahmen eines Trainings, das er Anfang Februar für die Lebensversicherung LV 1871 und deren Partner ARS, HUK und Datev veranstaltet hat.

heise Developer: Sam Newman, du bist einer der führenden Köpfe im Bereich Microservices. Wie bist du ursprünglich zu dem Thema gekommen?

Sam Newman: Ich war zur richtigen Zeit am richtigen Ort. Nachdem ich eine Weile als Entwickler gearbeitet hatte, kam ich 2004 zu ThoughtWorks. Zufälligerweise lag mein Fokus damals auf dem Bereich, den wir heute Continuous Delivery nennen. Damit waren Themen wie Pipeline- und Testautomatisierung verbunden. Auch die Cloud und das passende Deployment waren wichtige Themen.

Dabei habe ich bemerkt, dass häufig die Architektur einer Anwendung nicht zu den Anforderungen passte. Sie behinderte die Leute dabei, die Software so zu verwalten, wie sie es wollten. Zu der Zeit beschäftigte sich mein damaliger Kollege James Lewis mit einer neuen Form der Architektur, die er Micro Apps nannte.

Das führte zu der Überlegung, wie wir die Architektur so ändern können, dass sich Software schneller und zuverlässiger ausliefern lässt.

heise Developer: Was hat dich zu deinem ersten Buch über Microservices motiviert?

Newman: Ich wollte schon immer ein Buch schreiben – am liebsten für O'Reilly, denn das erste Programmierbuch, das ich mir selbst gekauft hatte, war von O'Reilly. Der Verlag kam mit einem anderen Thema auf mich zu [1]. Schließlich habe ich dann auch das Buch geschrieben, das seinerzeit das erste zum Thema Microservices war [2].

Mit dem Zeitpunkt hatte ich Glück, und die Leser mochten das Buch offenbar. Viele teilten ihre Erfahrungen mit mir. Zahlreiche Leser haben mir ihre Ideen geschickt. Es entstand ein fruchtbarer Kreislauf, und das Thema beschäftigt mich immer noch.

heise Developer: Haben die vielen Rückmeldungen Sie zum Schreiben des zweiten Buchs motiviert, das vier Jahre später erschienen ist?

Newman: Das erste Buch von 2014 behandelte vor allem die grundlegenden Konzepte und weniger spezifische Techniken. Der Vorteil daran ist: Die Konzepte sind im Gegensatz zu den Techniken nicht so schnell überholt.

Aber in einigen Bereichen ging es um explizite Techniken. Daher hatte ich das zweite Buch zunächst als eine aktualisierte Ausgabe des ersten geplant. Für die Arbeiten an Kapitel 5, das sich damit beschäftigt, wie man Systeme auseinanderbricht, habe ich einen Monat gebraucht. Aus den ursprünglich 5000 Wörtern wurden nach der Überarbeitung 30.000. Also habe ich ein Kapitel darüber, wie man etwas kleiner bekommt, viel größer gemacht – und zwar so groß, dass es ein eigenes Buch abgeben musste.

Statt einer zweiten Edition entstand somit ein frisches Buch [3]. "Building Microservices" war eine umfassende Abhandlung darüber, wie Microservices die Prozesse des Software Delivery ändern. Welchen Einfluss es auf Testing, Security und weitere Themen hat.

Dagegen taucht der Nachfolger "Monolith to Microservices" tief in den Umbau einer monolithischen zu einer Microservice-Architektur ein.

heise Developer: Möchtest du die zweite Edition trotzdem noch schreiben?

Newman: Die Techniken ändern sich nach wie vor in einem ungeheuren Tempo, und in der Tat arbeite ich gerade an einer aktualisierten Ausgabe von "Building Microservices". Derzeit sitze ich an dem Kapitel, das am meisten von technischen Änderungen betroffen ist: das Deployment.

Kubernetes muss ich natürlich ebenfalls in der Neufassung behandeln, weil es viele brennend interessiert und ich finde, dass es eine faszinierende Technik ist. Außerdem glaube ich, dass es die Probleme nicht so einfach löst, wie manche denken – auch darüber möchte ich schreiben.

Ein weiteres wichtiges jüngeres Thema sind Serverless-Architekturen beziehungsweise Function as a Service (FaaS). Andere Dinge kann ich dafür herausnehmen. Seinerzeit mussten sich Entwickler typischerweise mit Puppet-, Chef- oder Ansible-Skripten herumschlagen. Durch die fortschreitende Containerisierung ist vieles davon überflüssig. Auch andere Themen sind für Entwickler heute deutlich weniger relevant als vor fünf oder sechs Jahren.

heise Developer: Was ist für Unternehmen schwieriger beim Umstellen auf Microservices: der technische oder der kulturelle Wandel?

Newman: Gerald M. Weinberg, der Autor des großartigen Buchs "Das Gesetz der Himbeer-Marmelade – 103 Geheimnisse der Beratung" [4] ("Secrets of Consulting") hat den Satz "It's always a people problem" geprägt, es ist also immer ein Problem des Umgangs der Menschen untereinander.

Wir versuchen die Techniken durch die Technologiebrille zu betrachten, aber Menschen haben die Techniken entwickelt. Daher kann man nichts reparieren, wenn man es rein technisch betrachtet. Meiner Meinung nach kann man keinen kulturellen Wandel durch neue Techniken bewirken. Technologie kann den Wandel fördern oder behindern, aber nicht erzwingen.

Wer das Beste aus Microservices als Architektur herausholen möchte, muss auch die organisatorischen Strukturen berücksichtigen. James Lewis hat gesagt, dass Microservice-Architekturen eine Optimierung in Richtung Autonomie bringen. Der Architekturstil ermöglicht Organisationen, autonome Teams und autonome Arbeitsweisen zu etablieren.

Die Verantwortung wandert von einer zentralen Stelle in die einzelnen Teams. Zu Organisationen, die eine solche Arbeitsweise wünschen, passen Microservices als Konzept gut. Organisationen, die eine zentrale Befehls- und Kontrollebene beibehalten möchten und in denen eine kleine Gruppe von Menschen alle Änderungen steuert, werden kaum von den Vorteilen der Microservices profitieren.

Meiner Meinung nach muss daher der technische Wandel Hand in Hand mit dem kulturellen erfolgen. Allerdings ist eine technische Umstellung fast immer einfacher, als Leute dazu zu bringen, ihre Denk- oder Arbeitsweise zu ändern.

Keine Schwarz-Weiß-Malerei

heise Developer: Oft werden Monolithen gegen Microservices in einem Schwarz-Weiß-Schema betrachtet. Befinden sich viele Firmen nicht eher in der Grauzone dazwischen?

Newman: Das typische Schwarz-Weiß-Schema ist meiner Meinung nach Unfug. Zudem ist "Monolith" der neue Begriff für "Legacy" geworden – und das ist nicht richtig. Man sollte Monolith als Art des Deployments betrachten, mehr nicht.

Viele sehen den Monolithen als Feind an – auch das stimmt nicht. Deine Kunden interessiert es nicht, ob du einen Monolithen oder eine Microservice-Architektur verwendest. Sie interessiert nur, ob die Software funktioniert.

Wenn ich Firmen berate, frage ich sie, welche Probleme sie lösen möchten. Wenn ihr Architekturmodell sie beispielsweise daran hindert, Software schneller ausliefern zu können, mag das Ändern der Architektur der richtige Weg sein.

Microservices sind nicht automatisch der richtige Weg nach vorn, und ich habe etwa der Hälfte meiner Kunden in den letzten vier Jahren geraten, in ihrer aktuellen Situation nicht auf Microservice-Architekturen umzustellen. Einige von ihnen haben sogar auf mich gehört, aber oft galt schon im Vorfeld die Prämisse: "Wir müssen Microservices einsetzen", sodass sie den Prozess nicht aufhalten konnten.

heise Developer: Was würden sie als größte Missverständnisse rund um Microservices bezeichnen?

Newman: Nummer 1: "Das geht schnell". Firmen müssen verstehen, dass es ein längerer Prozess ist. Es gibt die unterschiedlichen Systeme zu berücksichtigen, die über die Jahre gewachsen sind: Server, Mainframes, Legacy-Datenbanken. Es handelt sich um einen Prozess, keine schnelle Umstellung.

Zweitens: "Es geht in einem Rutsch." Nein, die Umstellung muss als inkrementeller Prozess laufen. Eine monolithische Anwendung lässt sich nicht von jetzt auf gleich in Microservices aufteilen und nahtlos weiterverwenden.

In der Realität erkennt man 90 Prozent der Unannehmlichkeiten, Sorgen und Ängste bis zu blankem Schrecken erst, wenn man in Produktion geht. Daher muss man die Umstellung schrittweise angehen. Microservices sind ein Weg nach vorne, bei dem es immer wieder abzuwägen gilt, wie weit man voran schreitet. Ändere eine Kleinigkeit, setze es dem regulären Workload im Produktivbetrieb aus und, wenn es funktioniert, nimm dir das nächste Stück vor.

Die Umstellung ist kein An-/Aus-Schalter, sondern ein Drehknopf.

heise Developer: Derzeit sind Micro Frontends ein angesagtes Thema. Was meinst du dazu?

Newman: Von Anfang an haben wir beim Konzept der Microservices auch daran gedacht, den Code für die UI aufzubrechen. Zugegebenermaßen haben wir aber bei unseren ganzen Gesprächen über Microservices die UI nicht genügend berücksichtigt. Das hat bei manchen Leuten den Eindruck hinterlassen, dass man die Backend-Services auseinanderbrechen soll, aber die UI eine monolithische Schicht bleibt.

Viele Organisationen haben die UI schon auseinandergebrochen. Allerdings sind Single-Page Webanwendungen (SPA) äußerst beliebt, und sie haben das Problem im Namen: "Ich bin die App, das ist meine eine Seite". Sie bieten keine guten Konzepte für die Modularisierung.

Bei Micro Frontends geht es also primär darum, UIs und dabei vor allem SPAs zu betrachten und Wege zu finden, sie auseinanderzunehmen und auf mehrere Teams aufzuteilen. Allerdings braucht man keine Micro Frontends, wenn man auf herkömmliche Webseiten setzt – dort sind die einzelnen Seiten schon eine gute Aufteilung. Wer aber SPAs erstellt, sollte auf jeden Fall Micro Frontends erwägen.

heise Developer: Wir haben schon am Rande über Serverless Computing gesprochen: Siehst du Function as a Service (FaaS) als konsequente Fortsetzung des Microservices-Konzept in der Cloud?

Newman: Aus meiner Sicht ist FaaS die beste entwicklerfreundliche Abstraktion für das Deployment von Software seit Heroku. Letzteres hat die Messlatte für eine entwicklerfreundliche Platform as a Service sehr hoch gelegt, und alle anderen haben die Heroku-UI jahrelang kopiert. Pivotal hat Cloud Foundry komplett umgeschrieben, um die Heroku-UI zu imitieren.

Entwickler sollten sich beispielsweise nicht mit Kubernetes-Deployment herumschlagen müssen, sondern auf einer Abstraktionsebene arbeiten, und FaaS ist eine sehr gute. Daher empfehle ich manchmal Teams beim Auseinanderbrechen von Projekten: Vielleicht solltet ihr zuerst die Funktionen betrachten und den Kubernetes-Gedanken überspringen. In der Kombination Kubernetes und FaaS gibt es viel Bewegung: OpenFaaS, Knative – auch wenn ich bei Letzterem etwas vorsichtig bin, da Google es komplett steuert.

FaaS mag nicht die perfekte Antwort auf alles sein, aber es ist meiner Ansicht nach das Beste, was an entwicklerfreundlichen Techniken in letzter Zeit aufgekommen ist.

heise Developer: Zum Abschluss: Kommst du noch zum Programmieren, und welche der jüngeren Programmiersprachen wie Go, Rust oder Kotlin findest du besonders spannend?

Newman: Auch wenn ich nicht mehr für das Programmieren bezahlt werden, schreibe ich gelegentlich noch Code. Wenn ich Skripte schreibe, ist Python meine Heimat. Derzeit versuche ich Go zu lernen, weil ich es für eine recht pragmatische Programmiersprache halte. Sie hat viele Vorteile im Zusammenspiel mit der Container-Verwaltung. Einige meiner Kunden nutzen Go. Es hat so wunderbar schlanke Binaries.

Wenn ich mich auf meine Wurzeln als Java-Programmierer unter Unix zurückbesinne, steht Kotlin ganz oben auf meiner Liste der Sprachen, die ich nutzen möchte. Sie ist einfach toll. Und als jemand, der jahrelang versucht hat, Scala richtig zu begreifen, wünschte ich, Kotlin wäre fünf Jahre früher erschienen und hätte vielen Programmierern den Umgang mit Scala erspart.

Das Interview führte Rainald Menge-Sonnentag, Redakteur von heise Developer.

Literatur

1. Sam Newman; Lightweight Systems for Realtime Monitoring; O'Reilly 2014
2. Sam Newman; Building Microservices; O'Reilly 2015
3. Sam Newman; Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith (English Edition); O'Reilly 2019
4. Gerald M. Weinberg; Das Gesetz der Himbeer-Marmelade – 103 Geheimnisse der Beratung; Redline Wirtschaft 2003

(rme [1])

URL dieses Artikels:
https://www.heise.de/-4714365

Links in diesem Artikel:
[1] mailto:rme@ix.de

Copyright © 2020 Heise Medien