Blog

Diese teils scherzhaft gemeinte Antwort hören wir immer wieder, wenn wir in der täglichen Arbeit vor einem Problem stehen, das über ein paar Komponenten hinausgeht. Wer Software entwickelt, weiß: Dem Begriff Architektur kann man – zu Recht – nur schwer aus dem Weg gehen. Sei es in bestehenden Projekten, in denen immer wieder die bestehende Architektur bemängelt wird, aber auch bei Projekten auf der grünen Wiese, wo noch vor der ersten Zeile Code die Architektur in Stein gemeißelt werden muss.Aber was genau ist eigentlich Softwarearchitektur? Eine kleine Umfrage im Team oder gar Unternehmen zeigt schnell: So richtig eindeutig kann das keiner sagen. Überhaupt hat jeder so seine ganz eigene Definition. Auch die oft erwähnte Analogie zur Architektur bei Gebäuden bröckelt häufig.

Die Dokumentation zu einem Softwareprojekt spielt eine wichtige Rolle. Dort ist niedergelegt, wie die Software intern funktioniert und welche Entscheidungen bezüglich der Architektur des Anwendungssystems getroffen wurden; zudem verdeutlicht die Dokumentation den Aufbau und die Umsetzung. Was es dabei zu beachten gibt, schauen wir uns in diesem Artikel an.

Softwarearchitektur ermöglicht es, die Vogelperspektive einzunehmen. Damit alle Projektbeteiligten den Überblick behalten, muss sie in den Unternehmenskontext eingebettet werden und abteilungsübergreifend angelegt sein. Dabei gilt es, strategische Entscheidungen zu treffen, die in hohem Maße von konkreten Anforderungen der spezifischen Branche abhängen. Dieser Artikel zeigt anhand praktischer Beispiele, wie sich die Architektur für moderne Lösungen von Anfang an in den Entwicklungsprojekten verankern lässt.

Damit eine Anwendung in Kubernetes betrieben werden kann, muss sie vorher als Docker Image paketiert werden, um sie anschließend in Kubernetes deployen zu können. Für das Kubernetes Deployment sind verschiedene Manifest-Dateien notwendig, mit denen die erforderlichen Kubernetes-Objekte angelegt werden. Erst jetzt kann mit dem Test der Anwendung in der Cloud-Umgebung begonnen werden. Bei Bugs oder neuen Features der Anwendung wiederholt sich dieser Kreislauf.

Bereits seit einigen Jahren sind Cloud-Anwendungen in aller Munde. Besonders in Aspekten wie Kostenreduktion und effizienterer Nutzung verfügbarer Ressourcen ist die Cloud schwer zu schlagen. Dabei zeigt sich das wahre Potenzial erst bei der Verwendung Cloud-optimierter Architekturen und Entwurfsmuster, da diese es ermöglichen, stabile Software zu entwickeln und komplexe Anforderungen in kleine, handliche Lösungen aufzuteilen. Doch dieser Vorteil hat seinen Preis. So stellen sich beispielsweise die folgenden Fragen: „Wie können die Services untereinander kommunizieren, wenn Systeme ausfallen?“ oder „Wie gehe ich mit Lastspitzen um?“

Module Federation erlaubt das Laden separat bereitgestellter Microfrontends und das Teilen von Abhängigkeiten. Web Components erlauben zusätzlich den parallelen Einsatz verschiedener Frameworks und Versionen. Die Kombination von beidem erhöht jedoch auch die Bundle Size und macht einige Workarounds notwendig.

Eine saubere Architektur zu definieren, ist das eine, sich im Projektalltag auch in stressigen Zeiten daran zu halten, meist eine ganz andere Geschichte. Und wenn es sich dann auch noch um Vorgaben handelt, die nicht direkt den eigenen Service betreffen, sondern seine Kommunikation mit anderen, ist die Motivation, sie einzuhalten, meist noch geringer. Wie kann man also solche Makroarchitekturvorgaben umgehen?

Die Flexibilität und die Geschwindigkeit von Microservices [1], [2] haben den hohen Preis eines verteilten Systems. Während der Betrieb dank Kubernetes kaum herausfordernd ist, müssen andere Funktionen aufwendig mit Bibliotheken implementiert und Werkzeuge für die Datenauswertung installiert werden. Ein Service Mesh wie Istio hilft, indem es viele Funktionen in die Infrastrukturebene hebt und Analysetools mitbringt.