Seite 2: Keine Schwarz-Weiß-Malerei

Inhaltsverzeichnis

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)