Blog

Resilient steht für widerstandsfähig, flexibel und anpassungsfähig. Der Begriff ist in weitgehend allen Bereichen unseres Lebens verbreitet. Man verwendet ihn nicht nur bei der Beschreibung der Persönlichkeit eines Menschen, er wird auch im Zusammenhang mit IT-Systemen und der Ausgestaltung des Programmcodes eingesetzt. Geht es um die Resilienz der Psyche, so wird darunter eine innere Stärke, besondere psychische Widerstandsfähigkeit bzw. die Fähigkeit bezeichnet, nach Niederlagen immer wieder aufzustehen.

Vernünftige Software zu schreiben ist schwer. Vernünftige Software in verteilten Systemen zu schreiben ist noch schwerer. Wie können wir uns also die Arbeit erleichtern, wenn es viele bewegliche Ziele gibt, die Dienste mal da sind und mal nicht und das ganze System am besten auch noch immer verfügbar und performant sein soll wie in der Cloud?

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?