Blog

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!