Blog

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.

Enterprise Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet zu sein. Erschwerend kommt hinzu, dass viele Enterprise Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet dies das Aus für Java in der Wunderwelt der Cloud? Mitnichten. Microframeworks to the Rescue!