© Excellent backgrounds/Shutterstock.com
Java Magazin
Web Components in der Welt der Micro Frontends

Kolumne: EnterpriseTales

Früher bestand eine Webanwendung mehr oder weniger aus nur einer Sammlung von dynamisch erzeugten HTML-Dokumenten, die ggf. mit Ajax Calls und jQuery angereichert wurden. Nahezu die gesamte Komplexität war serverseitig. Erhöhte Anforderungen an Interaktivität haben mittlerweile aber dazu geführt, dass mehr Logik im Client zu finden ist. Single Page Applications (SPAs) sind das Resultat. Durch diese wachsende Logik steigt auch die Komplexität der Anwendungen. Es entstehen Frontend-Monolithen. Eine Wunderwaffe dagegen können Micro Frontends sein. Aber wie gewährleisten wir dann Konsistenz in der gesamten Anwendung und isolieren gleichzeitig die einzelnen Micro Frontends voneinander?

Hendrik Müller


Vom Monolithen zu MicroservicesDas eigentliche Problem der Wartbarkeit liegt jedoch nicht an der monolithischen Architektur an sich, sondern vielmehr an der häufig fehlenden Modularität. Um diese zu erreichen und damit die Entwicklungsgeschwindigkeit der Teams auf einem konstant hohen Niveau zu halten, müssen wir große Software in möglichst unabhängige und kleinere Stücke zerschneiden. Während die Komplexität des technologischen Aspekts der Software auch bei deren längerer Existenz meist konstant bleibt (die Technologie veraltet höchstens), ist es meist die Fachlichkeit, die mit jedem neuen Feature umfangreicher und komplexer wird. Das führt dazu, dass die Software bei schlechtem Schnitt nicht mehr wartbar ist. Um die Komplexität eines Monolithen aufzubrechen, ist es daher sinnvoll, fachlich (und eben nicht technisch) zu schneiden.Aus dieser Überlegung heraus hat sich in den letzten Jahren ein alternatives Architekturmuster zum Monolithen im Backend etabliert, die Microservices. Dieser Ansatz zwingt technisch dazu, die Software zu modularisieren. Der richtige Schnitt ist auch hier leider eine Kunst für sich, denn jeder Microservice hat einen abgegrenzten fachlichen Aufgabenbereich.Die Architektur, die sich ergibt, ist im Idealfall nicht so verworren und dadurch besser wartbar. Service-Abhängigkeiten werden explizit sichtbar und lassen sich besser kontrollieren. Ein weiterer Vorteil von Microservices ist, dass jeder einzelne Service seinen eigenen Technologiestack haben kann und ihn auch unabhängig voneinander aktualisieren darf – Stichwort: Polyglot Microservices. Wir müssen unsere Software also modular bauen, damit die Produktivität der Entwicklerteams, also die schnelle und flexible Weiterentwicklung der Software, auch zukünftig sichergestellt ist.Der Frontend-MonolithMittlerweile haben höhere Anforderungen an Interaktivität im Client zur Entwicklung von SPAs geführt, die nur noch via HTTP mit dem Backend kommunizieren. Das klingt nicht nur komplexer, sondern ist es auch. So hat es die Problematik der großen und verworrenen Software auch ins Frontend geschafft – wir haben Frontend-Monolithen. Und auch das Resultat ist das gleiche: Wieder skalieren die Teams nicht. Änderungen werden teurer und langsamer. Doch es ist eine Lösung in Sicht: Entsprechend der Microservices-Bewegung im Backend gibt es mittlerweile den Trend hin zum Micro Frontend.Micro FrontendsAbb. 1: Standalone Micro FrontendsDas Problem der Kommunikation zwischen Micro Frontends tritt nur...

Java Magazin
Web Components in der Welt der Micro Frontends

Kolumne: EnterpriseTales

Früher bestand eine Webanwendung mehr oder weniger aus nur einer Sammlung von dynamisch erzeugten HTML-Dokumenten, die ggf. mit Ajax Calls und jQuery angereichert wurden. Nahezu die gesamte Komplexität war serverseitig. Erhöhte Anforderungen an Interaktivität haben mittlerweile aber dazu geführt, dass mehr Logik im Client zu finden ist. Single Page Applications (SPAs) sind das Resultat. Durch diese wachsende Logik steigt auch die Komplexität der Anwendungen. Es entstehen Frontend-Monolithen. Eine Wunderwaffe dagegen können Micro Frontends sein. Aber wie gewährleisten wir dann Konsistenz in der gesamten Anwendung und isolieren gleichzeitig die einzelnen Micro Frontends voneinander?

Hendrik Müller


Vom Monolithen zu MicroservicesDas eigentliche Problem der Wartbarkeit liegt jedoch nicht an der monolithischen Architektur an sich, sondern vielmehr an der häufig fehlenden Modularität. Um diese zu erreichen und damit die Entwicklungsgeschwindigkeit der Teams auf einem konstant hohen Niveau zu halten, müssen wir große Software in möglichst unabhängige und kleinere Stücke zerschneiden. Während die Komplexität des technologischen Aspekts der Software auch bei deren längerer Existenz meist konstant bleibt (die Technologie veraltet höchstens), ist es meist die Fachlichkeit, die mit jedem neuen Feature umfangreicher und komplexer wird. Das führt dazu, dass die Software bei schlechtem Schnitt nicht mehr wartbar ist. Um die Komplexität eines Monolithen aufzubrechen, ist es daher sinnvoll, fachlich (und eben nicht technisch) zu schneiden.Aus dieser Überlegung heraus hat sich in den letzten Jahren ein alternatives Architekturmuster zum Monolithen im Backend etabliert, die Microservices. Dieser Ansatz zwingt technisch dazu, die Software zu modularisieren. Der richtige Schnitt ist auch hier leider eine Kunst für sich, denn jeder Microservice hat einen abgegrenzten fachlichen Aufgabenbereich.Die Architektur, die sich ergibt, ist im Idealfall nicht so verworren und dadurch besser wartbar. Service-Abhängigkeiten werden explizit sichtbar und lassen sich besser kontrollieren. Ein weiterer Vorteil von Microservices ist, dass jeder einzelne Service seinen eigenen Technologiestack haben kann und ihn auch unabhängig voneinander aktualisieren darf – Stichwort: Polyglot Microservices. Wir müssen unsere Software also modular bauen, damit die Produktivität der Entwicklerteams, also die schnelle und flexible Weiterentwicklung der Software, auch zukünftig sichergestellt ist.Der Frontend-MonolithMittlerweile haben höhere Anforderungen an Interaktivität im Client zur Entwicklung von SPAs geführt, die nur noch via HTTP mit dem Backend kommunizieren. Das klingt nicht nur komplexer, sondern ist es auch. So hat es die Problematik der großen und verworrenen Software auch ins Frontend geschafft – wir haben Frontend-Monolithen. Und auch das Resultat ist das gleiche: Wieder skalieren die Teams nicht. Änderungen werden teurer und langsamer. Doch es ist eine Lösung in Sicht: Entsprechend der Microservices-Bewegung im Backend gibt es mittlerweile den Trend hin zum Micro Frontend.Micro FrontendsAbb. 1: Standalone Micro FrontendsDas Problem der Kommunikation zwischen Micro Frontends tritt nur...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang