© StonePictures/Shutterstock.com
Kolumne: EnterpriseTales

Wie hält „Cloud-native“ Einzug in Enterprise Java?


Sowohl Spring als auch Quarkus proklamieren für sich, Cloud-native zu sein [1], [2]. Aber was heißt das eigentlich und wie sieht’s mit dem Rest des (Enterprise-)Java-Ökosystems aus? Diese Ausgabe unserer Kolumne erläutert, was eigentlich im Allgemeinen hinter dem vielgehörten Begriff Cloud-native steckt und welche Auswirkungen das auf die Softwareentwicklung in Enterprise Java im Speziellen hat.

Als Amazon 2002 die AWS-Plattform startete [3], war wohl noch niemandem klar, dass damit eine Zeitenwende im Enterprise Computing eingeläutet wurde – die Cloud war geboren. Seither hat sich viel bewegt, initial war die Begeisterung groß, weil man sich per Knopfdruck einen Root-Server in der Cloud erstellen konnte. Mittlerweile ist aber vielen klar geworden, dass der eigentliche Mehrwert der Cloud gerade darin liegt, keinen eigenen Root-Server mehr betreiben zu müssen, sondern sich auf die Implementierung der fachlichen Anwendungen fokussieren zu können. Die können dann auf den verschiedenen Clouds proprietär betrieben werden, ohne dass man sich um die Administration der Server kümmern muss.

Lange Zeit war es allerdings so, dass man dabei Cloud-Anbieter-spezifische APIs verwenden und sich somit schon früh auf einen Anbieter festlegen musste. Mittlerweile gibt es aber mit Kubernetes einen De-facto-Standard, um die eigene Applikation anbieterunabhängig in der Cloud zu betreiben. Aber was ist in diesem Zusammenhang eigentlich eine Applikation, und was bedeutet, dass sie „Cloud-native“ ist?

Die Cloud Native Computing Foundation [4] definiert Cloud-native folgendermaßen: „Cloud-native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen zu implementieren und zu betreiben. [...] Best Practices wie Container, Service Meshes, Microservices, immutable Infrastruktur und deklarative APIs, unterstützen diesen Ansatz.“

In dieser Definition fallen ein paar Schlüsselworte, die ich im Folgenden erklären möchte.

Container, Service Meshes und Microservices

Die ersten drei (nämlich Container, Service Meshes und Microservices) dürften dem geneigten Java-Magazin-Leser bereits bekannt sein, selbst wenn er sie noch nicht aktiv im Unternehmen einsetzt. Dennoch lohnt es sich, auch hier einen Blick darauf zu werfen, warum die genannten Technologien denn geeignet sind, „skalierbare Anwendungen in modernen, dynamischen Umgebungen zu implementieren“. Um das zu verstehen, werfe ich einen Blick darauf, wie ein klassischer Deployment-Prozess ohne Cloud-native-Gedanken eigentlich aussieht.

Klassischerweise ist es so, dass das Artefakt, das das Entwicklungsteam ausliefert, ein Web Application Archive (WAR) oder ein Enterprise Application Archive (EAR) ist. Dieses wird dem Operations-Team quasi über den Zaun geworfen, das es zunächst auf den Testsystemen und später (nach umfangreichen manuellen und selten automatisierten Tests) auf dem Produktionssystem auf einem Application Server installiert, von dem das Entwicklungsteam nicht so genau wusste, wie er konfiguriert ist. Häufig unterschied sich zudem die Konfiguration von Test- und Produktivsystem. Konfigurationen wurden häufig manuell auf die Systeme übertragen. Das war ein fehleranfälliger Prozess.

Um eine Anwendung der alten Art zu skalieren, musste zunächst vom Admin ein neuer Application Server gestartet und dann exakt so konfiguriert werden wie die bestehenden Server (inklusive der Applikation). Dann musste der Load Balancer so konfiguriert werden, dass er den neuen Server mit aufnahm und mit Last versorgte. Auch hier waren viele manuelle...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang