Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Organisation und Arbeitsweise
Wie bei allen Architekturstrategien haben Mikro-Frontends Auswirkungen, die weit über die Technologie hinausgehen, für deren Implementierung sich ein Unternehmen entscheidet. Die Entscheidung, Mikro-Frontend-Anwendungen zu entwickeln, muss auf das Geschäft, das Produkt, die Organisation, den Betrieb und sogar die Kultur abgestimmt sein (z. B. die Stärkung von Teams und die Dezentralisierung der Entscheidungsfindung). Im Gegenzug unterstützt diese Art von Micro-Frontend-Architektur eine wirklich agile, produktorientierte Entwicklung, da sie den Kommunikationsaufwand zwischen ansonsten unabhängigen Teams erheblich reduziert.
Agile Entwicklung
Die Idee der agilen Softwareentwicklung ist in den letzten Jahren so allgegenwärtig geworden, dass praktisch jedes Unternehmen behauptet, agil zu arbeiten. Eine abschließende Definition von Agilität würde zwar den Rahmen dieser Strategie sprengen, es lohnt sich jedoch, die wichtigsten Elemente zu überprüfen, die für die Mikro-Frontend-Entwicklung relevant sind.
Die Grundlage des agilen Paradigmas ist das Agile Manifest
Im Kontext der Micro-Frontend-Architektur ist es wichtig, die folgenden agilen Prinzipien zu berücksichtigen:
-
„Liefern Sie regelmäßig funktionierende Software, von ein paar Wochen bis zu ein paar Monaten, und bevorzugen Sie dabei kürzere Zeiträume.“
Dieses Prinzip unterstreicht, wie wichtig es ist, schrittweise zu arbeiten und Software so regelmäßig und so oft wie möglich für die Produktion bereitzustellen. Aus technologischer Sicht bezieht sich dies auf kontinuierliche Integration und kontinuierliche Lieferung (CI/CD). Bei CI/CD sind die Tools und Prozesse zum Erstellen, Testen und Bereitstellen integraler Bestandteil jedes Softwareprojekts. Das Prinzip beinhaltet auch, dass die Laufzeitinfrastruktur und die operativen Verantwortlichkeiten dem Team obliegen müssen. Diese Eigenverantwortung ist besonders wichtig in verteilten Systemen, in denen unabhängige Subsysteme möglicherweise erheblich unterschiedliche Anforderungen an Infrastruktur und Betrieb stellen.
-
„Bauen Sie Projekte rund um motivierte Einzelpersonen auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie ihre Arbeit erledigen.“
„Die besten Architekturen, Anforderungen und Designs entstehen durch sich selbst organisierende Teams.“
Beide Prinzipien betonen die Vorteile von Eigenverantwortung, Unabhängigkeit und end-to-end Verantwortung. Eine Mikro-Frontend-Architektur wird erfolgreich sein, wenn (und nur wenn) die Teams ihre Micro-Frontends wirklich selbst in der Hand haben. Die nd-to-end Verantwortung von der Konzeption über das Design und die Implementierung bis hin zu Lieferung und Betrieb stellt sicher, dass das Team tatsächlich Verantwortung übernehmen kann. Diese Unabhängigkeit ist sowohl technisch als auch organisatorisch erforderlich, damit das Team die strategische Ausrichtung selbst bestimmen kann. Wir empfehlen nicht, eine Micro-Frontend-Plattform in einer zentralisierten Organisation zu verwenden, die ein Wasserfall-Entwicklungsmodell verwendet.
Zusammensetzung und Größe des Teams
Damit ein Softwareteam Verantwortung übernehmen kann, muss es sich innerhalb der von der Organisation auferlegten Grenzen selbst verwalten, einschließlich der Art und Weise, wie und was das Team leistet.
Um effektiv zu sein, müssen Teams in der Lage sein, Software unabhängig zu liefern, und die Befugnis haben, zu entscheiden, wie sie am besten bereitgestellt wird. Ein Team, das Funktionsanforderungen von einem externen Produktmanager oder UI-Designs von einem externen Designer erhält, ohne an der Planung dieser Elemente beteiligt zu sein, kann nicht als eigenständig betrachtet werden. Die Funktionen könnten gegen bestehende Verträge oder Funktionen verstoßen. Solche Verstöße erfordern weitere Diskussionen und Verhandlungen, wobei die Gefahr besteht, dass sich die Umsetzung verzögert und unnötige Konflikte zwischen den Teams entstehen.
Gleichzeitig sollten die Teams nicht zu groß werden. Während ein größeres Team über mehr Ressourcen verfügt und individuelle Abwesenheiten bewältigen kann, nimmt die Komplexität der Kommunikation mit jedem neuen Mitglied exponentiell zu. Es ist nicht möglich, eine allgemein gültige maximale Teamgröße anzugeben. Die Anzahl der Personen, die für ein Projekt benötigt werden, hängt von Faktoren wie Teamreife, technischer Komplexität, Innovationstempo und Infrastruktur ab. Amazon folgt beispielsweise der Zwei-Pizza-Regel: Ein Team, das zu groß ist, um mit zwei Pizzen gefüttert zu werden, sollte in kleinere Teams aufgeteilt werden. Das kann eine Herausforderung sein. Die Aufteilung sollte entlang natürlicher Grenzen erfolgen und jedem Team Autonomie und Eigenverantwortung für seine Arbeit geben.
DevOps Kultur
DevOps bezieht sich auf eine Praxis der Softwareentwicklung, bei der die Schritte des Entwicklungszyklus aus organisatorischer und technischer Sicht eng miteinander verknüpft sind. Entgegen der landläufigen Meinung geht DevOps es hier sehr viel um Kultur und Denkweise und sehr wenig um Rollen und Tools.
Traditionell verfügte eine Softwareorganisation über Spezialistenteams, z. B. für Design, Implementierung, Tests, Bereitstellung und Betrieb. Immer wenn ein Team seine Arbeit abschloss, übergab es das Projekt an das nächste Team. Die Bereitstellung von Software durch Silos spezialisierter Teams führt jedoch zu Reibungsverlusten bei der Übergabe. Wenn Spezialisten gezwungen sind, mit einem engen Fokus zu arbeiten, fehlt es ihnen gleichzeitig an Wissen in benachbarten Bereichen und sie haben keine systemische Sicht auf das Produkt. Diese Defizite können zu einer geringen Kohärenz des Softwareprodukts führen.
Wenn ein Softwarearchitekt beispielsweise eine Lösung entwirft, die von jemandem in einem anderen Team implementiert werden soll, übersieht er möglicherweise inhärente Aspekte der Implementierung (z. B. ein Missverhältnis zwischen Abhängigkeiten). Entwickler verwenden dann Abkürzungen (z. B. einen Monkey Patch), oder es back-and-forth wird eine formelle Vereinbarung zwischen dem Architekten und dem Entwicklungsteam eingeleitet. Aufgrund des hohen Verwaltungsaufwands für diese Prozesse ist die Entwicklung nicht mehr agil (im Sinne von flexibel, adaptiv, inkrementell und informell).
Obwohl sich der Begriff DevOps hauptsächlich auf Kultur bezieht, beinhaltet er die Technologien und Prozesse, die in der Praxis DevOps möglich sind. DevOps ist eng mit CI/CD verwandt. Wenn ein Entwickler die Implementierung eines Softwareinkrements abgeschlossen hat, überträgt er es an ein Versionskontrollsystem wie Git. Traditionell würde ein Build-System dann die Software erstellen und integrieren und sie in einem mehr oder weniger einheitlichen und zentralisierten Prozess testen und veröffentlichen lassen. Bei CI/CD erfolgt die Erstellung, Integration, Prüfung und Veröffentlichung der Software inhärent und automatisiert. Im Idealfall ist der Prozess mithilfe von Konfigurationsdateien, die speziell auf das jeweilige Projekt zugeschnitten sind, Teil des Softwareprojekts selbst.
So viele Schritte wie möglich werden automatisiert. Beispielsweise sollten manuelle Testpraktiken reduziert werden, da fast alle Arten von Tests automatisiert werden können. Wenn das Projekt auf diese Weise eingerichtet ist, können Updates für ein Softwareprodukt mehrmals täglich mit hoher Zuverlässigkeit bereitgestellt werden. Eine weitere Technologie, die dies unterstützt, DevOps ist Infrastructure as Code (IaC).
Traditionell erforderten die Einrichtung und Wartung der IT-Infrastruktur die manuelle Installation und Wartung von Hardware (Einrichtung von Kabeln und Servern in einem Rechenzentrum) und Betriebssoftware. Das war notwendig, hatte aber zahlreiche Nachteile. Die Einrichtung war zeitaufwändig und fehleranfällig. Hardware war oft über- oder unterausgestattet, was entweder zu hohen Ausgaben oder zu Leistungseinbußen führte. Mithilfe von IaC können Sie die Infrastrukturanforderungen für ein IT-System anhand einer Konfigurationsdatei beschreiben, aus der Cloud-Dienste automatisch bereitgestellt und aktualisiert werden können.
Was hat das alles mit Mikro-Frontends zu tun? DevOps, CI/CD und IaC sind ideale Ergänzungen zu einer Micro-Frontend-Architektur. Die Vorteile von Micro-Frontends beruhen auf schnellen und reibungslosen Lieferprozessen. Eine DevOps Unternehmenskultur kann nur in Umgebungen gedeihen, in denen Teams verantwortungsbewusst Softwareprojekte übernehmen. end-to-end
Orchestrierung der Mikro-Frontend-Entwicklung in mehreren Teams
Bei der Skalierung der Mikro-Frontend-Entwicklung auf mehrere funktionsübergreifende Teams treten zwei Probleme auf: Erstens beginnen die Teams, ihre eigene Interpretation des Paradigmas zu entwickeln, Framework- und Bibliotheksentscheidungen zu treffen und ihre eigenen Tools und Hilfsbibliotheken zu erstellen. Zweitens müssen vollständig autonome Teams die Verantwortung für generische Funktionen wie das Infrastrukturmanagement auf niedriger Ebene übernehmen. Daher ist es sinnvoll, zwei zusätzliche Teams in einer Micro-Frontend-Organisation mit mehreren Teams einzuführen: ein Enablement-Team und ein Plattformteam. Diese Konzepte sind in modernen IT-Organisationen mit verteilten Systemen weit verbreitet und in Teamtopologien ausführlich dokumentiert.
Das folgende Diagramm zeigt, wie das Enablement-Team drei Micro-Frontend-Teams Tools, Bibliotheken, Standards und Tests zur Verfügung stellt. Das Plattformteam stellt Infrastruktur, gemeinsame Runtime-Funktionen und Domain-Services für dieselben drei Micro-Frontend-Teams bereit.
Das Plattformteam unterstützt die Micro-Frontend-Teams, indem es sie von undifferenzierter Schwerstarbeit befreit. Diese Unterstützung kann Infrastrukturdienste wie Container-Laufzeiten, CI/CD-Pipelines, Tools für die Zusammenarbeit und Überwachung umfassen. Die Einrichtung eines Plattformteams sollte jedoch nicht zu einer Organisation führen, in der die Entwicklung vom Betrieb getrennt ist. Das Gegenteil ist der Fall: Das Plattformteam bietet ein technisches Produkt an, und die Micro-Frontend-Teams sind für ihre Dienste auf der Plattform verantwortlich und tragen die Verantwortung für deren Laufzeit.
Das Enablement-Team bietet Unterstützung, indem es sich auf die Steuerung konzentriert und die Konsistenz zwischen den Micro-Frontend-Teams sicherstellt. (Das Plattformteam sollte daran nicht beteiligt sein.) Das Enablement-Team verwaltet gemeinsam genutzte Ressourcen wie eine UI-Bibliothek und erstellt Standards wie die Wahl des Frameworks, Leistungsbudgets und Interoperabilitätskonventionen. Gleichzeitig werden neue Teams oder Teammitglieder darin geschult, die von der Unternehmensleitung festgelegten Standards und Tools anzuwenden.
Bereitstellen
Das Nonplusultra für Autonomie in Micro-Frontend-Teams ist eine automatisierte Pipeline mit einem Weg zur Produktion, der unabhängig von anderen Micro-Frontend-Teams ist. Teams, die dem Share-Nothing-Prinzip folgen, können unabhängige Pipelines implementieren. Teams, die Bibliotheken gemeinsam nutzen oder von einem Plattformteam abhängig sind, müssen entscheiden, wie Abhängigkeiten in Bereitstellungspipelines verwaltet werden sollen.
In der Regel macht jede Pipeline Folgendes:
-
Baut Frontend-Assets auf
-
Stellt die Ressourcen zur Nutzung auf dem Hosting bereit
-
Stellt sicher, dass Registries und Caches aktualisiert werden, sodass die neuen Versionen an Kunden ausgeliefert werden können
Die tatsächlichen Pipeline-Schritte variieren je nach Technologie-Stack und Ansatz zur Seitenzusammensetzung.
Für die clientseitige Zusammenstellung bedeutet dies, dass Anwendungspakete in Hosting-Buckets hochgeladen und durch Caching in einem CDN für den Nutzer freigegeben werden. Anwendungen, die Browser-Caching mit Servicemitarbeitern verwenden, sollten auch Methoden zur Aktualisierung der Servicemitarbeiter-Caches implementieren.
Bei serverseitiger Zusammenstellung bedeutet dies in der Regel, die neue Version der Serverkomponente bereitzustellen und die Micro-Frontend-Registrierung zu aktualisieren, damit die neue Version auffindbar ist. Sie können die Bereitstellungsmuster Blau/Grün oder Canary verwenden, um neue Versionen schrittweise einzuführen.
