Entwickler: Kannst Du uns etwas zu den Vor- und Nachteilen sagen, wenn man von einem Monolithen auf Microfrontends umsatteln möchte?
Lars Kölpin-Freese: Zunächst einmal sind Microfrontends ein recht junges Konstrukt. Sie sind letztlich das Ergebnis vieler Umstrukturierungen großer IT-Unternehmen, die bereits ihre Struktur in viele verteilte Systeme umgebrochen haben, um den Teams im Einzelnen eine bessere Performance – sei es in der Entwicklung oder im Deployment zum Time-to-Market – zu liefern.
Die Idee, Dinge in verschiedene Systeme aufzuteilen, ist nicht umsonst.
Und da liegt meiner Meinung nach auch die größte Schwierigkeit: Die Idee, Dinge in verschiedene Systeme aufzuteilen, seien es Microservices im Backend oder Microfrontends, ist nicht umsonst. Verteilte Systeme bringen eine massive Komplexität in Sachen Integration der Systeme, aber vor allem auch in der Datenverwaltung mit, die häufig mit Datenreplikation und Synchronisationsmechanismen gespickt ist. Probleme, die man beim klassischen Monolithen schlichtweg nicht hat. Und das ist die Krux: Es ist extrem schwer, von vornherein einen guten Team-Schnitt hinzubekommen!
Entwickler: Welche Synergien ergeben sich durch die Verwendung von Microfrontends?
Lars Kölpin-Freese: Wer erwägt, Microfrontends einzuführen, ist sicherlich schon dabei, Microservices zu nutzen und die entsprechenden Techniken des Domain-driven Design anzuwenden. Und obwohl die Anforderungen der User nicht immer eins zu eins auf einen Bounded Context mappen, kann eine grobe Team-Split-Vorgabe hier sicherlich profitieren.
Entwickler: Welche Probleme können auf Entwickler beim Einsatz von Microfrontends zukommen?
Lars Kölpin-Freese: Natürlich ist der Begriff „Microfrontend“ erstmal ein Kampfbegriff und wird je nach Unternehmen anders ausgelegt. Es gibt kein Konsortium, das festlegt: Das sind Microfrontends. Klassischerweise werden Microfrontends so interpretiert, dass der Nutzer am Ende eine Webseite sieht, aber die einzelnen Komponenten oder Abschnitte der Seite von verschiedenen Teams geliefert werden. Häufig findet hier der Begriff des horizontalen Schnitts Anwendung.
Die Probleme entstehen nicht, wenn das Gesamtbild so schön stehen bleibt: jede Komponente eines Teams für sich auf einer Seite. Die wahren Probleme entstehen, wenn das „heile Gesamtbild“ einbricht und die Komponenten einer Seite im Namen der User Experience miteinander interagieren müssen und sich gegenseitig beeinflussen und/oder eben gleich Aussehen müssen. Das bedeutet nämlich Folgendes: Cross-Team-Alignment und Schnittstellen, die stabil bleiben müssen. Also das, was man durch Microfrontends eigentlich versucht zu vermeiden. Das ist z. B. der Grund, warum ich sage, ich würde nicht versuchen, von vornherein eine UI-Bibliothek einzuführen. Ein separates Team würde schon von Anfang an eine Abhängigkeit einführen. Stattdessen sollte sich eine UI-Bibliothek mit der Zeit ergeben.
Entwickler: Wann würdest du von einem Einsatz von Microfrontends abraten?
Lars Kölpin-Freese: Meiner Meinung nach sollte die Frage nicht lauten „Wann rät man ab“, sondern eher „Wann eignen sich Microfrontends“. Denn aus meiner Sicht sollte eine Begründung da sein, etwas zu tun, anstatt etwas nicht zu tun. Ansonsten es ist extrem schwer, die Hype-Brille abzunehmen – so auch bei Micofrontends.
Viele Unternehmen implementieren bereits unbewusst einen Ansatz von Microfrontends, ohne dass sie es überhaupt merken!
Das Konzept von Microfrontends ist eine Antwort auf die Komplexität, die Unternehmen mitbringen, wenn sie mit vielen parallelen Teams gemeinsam an einem langjährigen IT-System arbeiten. Arbeite ich dagegen nur mit einem einzigen Team an einem Fullstack-Produkt (sprich Backend und Frontend, die erzeugten Daten sind vollständig in der Hand des Teams), dann ist das auch gut so und es sollte nicht künstlich ein Problem für eine Lösung geschaffen werden. Die Lösung folgt immer einem konkreten Problem!
Habe ich im Gegenzug eine riesige IT-Landschaft mit vielen Teams zu verwalten, die am Ende zu einem großen Produkt beitragen, dann ist der Einsatz von Microfrontends vielleicht gerechtfertigter. Übrigens: Viele Unternehmen implementieren bereits unbewusst einen Ansatz von Microfrontends, ohne dass sie es überhaupt merken! Häufig sind sie also nur das Ergebnis des natürlichen Team-Schnittes. Neu ist da wohl eher der Trend, dass verschiedene Teile einer Seite von verschiedenen Teams verwaltet werden.
Entwickler: Welche Technologie aus dem Bereich würdest du Neueinsteigern auf jeden Fall ans Herz legen?
Lars Kölpin-Freese: Ich denke, es kann nie schaden, sich mit den Standard-Tools des Webs auszukennen. Ein Reverse Proxy wie Nginx für serverseitige Integration oder das Browser-API wie z. B. Web Components oder das History-API sind da sicherlich ein solider Anfang, mit dem sich bereits viel erreichen lässt. Schließlich baut darauf alles auf. Für etwas komplexere Anwendungsfälle oder Erleichterungen sind für Single-Page-Applications sicher „single-spa“ oder das Mosaic-Framework von Zalando einen Blick Wert. Das sind aber nur konkrete Toolings und diese sollten dem Problem folgen!
Entwickler: Kannst du abschätzen, inwieweit Microfrontends die üblichen Monolithen im Frontend ablösen werden?
Die „üblichen Monolithen“ werden nie verschwinden.
Lars Kölpin-Freese: Ich kann mich nur wiederholen: Für mich ist das keine „entweder oder“-Frage. Die „üblichen Monolithen“, womit klassische Single-Page-Applications gemeint sind, werden nie verschwinden. Dazu gibt es einfach viel zu viele kleine abgeschlossene Produkte als riesige IT-Strukturen, die es einfach nicht wert sind, weiter aufgeteilt zu werden. In großen Konzernen wird der Begriff „Microfrontend“ wohl immer wichtiger werden.
Entwickler: Vielen Dank für das Interview!
