Cloud-Infrastrukturen bieten flexible Ressourcen und Preismodelle, die sich am tatsächlichen Verbrauch orientieren. Java-Anwendungen waren bislang aufgrund ihrer Startzeiten und Ressourcen-Verbräuche mit einem negativen Image behaftet.
Das Spring-Native-Projekt will hier Abhilfe schaffen, indem es die native Kompilierung von Spring-Anwendungen vereinfachen und optimieren will. Die Grundlagen dazu haben wir in unserem Blog Artikel "Java Cloud Ready" zusammengefasst.
Mit dem Spring Boot Release 3.0 ist die native Kompilierung nun kein experimentelles Feature mehr. Vielmehr ist sie fester Bestandteil des Frameworks. Praktischerweise bringt Spring Boot dafür die notwendigen Konfigurationen von Haus aus mit, womit prinzipiell jede neuere Spring-Boot-Anwendung nativ kompilierbar ist.
Was hat sich mit Spring Boot 3 geändert?
Organisatorisch bedeutet die Aufnahme in das Spring Boot Basis Framework vor allem ein langfristiges Commitment zu Spring Native durch die Spring Community und eine Bestätigung seines Reifegrades.
Technisch haben sich vor allem die notwendigen Konfigurationen vereinfacht. So muss zum Beispiel Paketo, das zugrundeliegende Werkzeug zur Container-Image-Erstellung, nicht mehr selbst konfiguriert werden. Sowohl die Image-Erstellung als auch die Auswahl einer klassischen oder nativen Laufzeitumgebung sind jetzt im Build-Workflow des Frameworks fest verankert.
Hier reicht es aus, das passende „native“ Maven Plugin anzugeben. Spring übernimmt die Aufgabe, ein Image mit GraalVM-Laufzeitumgebung und AOT-Kompilierung zu bauen. Der Einstieg in die Cloud-kompatible Entwicklung ist dadurch deutlich leichter geworden.
Um das vereinfachte Setup nachvollziehen zu können, haben wir in dem Beispielprojekt des letzten Artikels einen Spring Boot 3 Branch bereitgestellt.
Ressourcen-Optimierung durch Native bei Spring Boot 3?
Die Startzeiten der Beispielanwendung wurden in unserem Test-Cluster durch die native Kompilierung von ca. 6 Sekunden auf 0,06 Sekunden reduziert.
Der Memory-Footprint von Spring Boot 3.0 ist im Vergleich zur Vorgängerversion auch ohne native Kompilierung gesunken. Durch das Upgrade konnten wir den durchschnittlichen Arbeitsspeicherverbrauch unserer Beispielanwendung mit JIT-Kompilierung von 215 MB um 25 % auf 158 MB senken.
Leider ist diese Reduktion nicht bei der Verwendung des Native-Images bemerkbar. Im Vergleich zur Vorgängerversion, ist der Arbeitsspeicherverbrauch mit AOT-Kompilierung von ursprünglich 30,2 MB sogar um 56 % auf 47,4 MB gestiegen.
Dennoch lässt sich der Verbrauch der Anwendung somit auf ein Drittel des ursprünglichen Verbrauchs deutlich reduzieren. Zudem ist Spring Boot 3.0 noch nicht allzu lange öffentlich verfügbar. Verbesserungen an dem AOT-Kompilierungsprozess sind denkbar, wodurch der Verbrauch in Nachfolgeversionen wieder gesenkt werden könnte.
Speicherverbrauch der beiden Varianten mit Spring 3.0 visualisiert mit Grafana
Ändert sich etwas an den grundlegenden Herausforderungen?
An den wirklich grundlegenden Herausforderungen, die wir auch in unserem letzten Artikel beschrieben haben, ändert sich leider erstmal nichts. Beispielsweise bedarf es bei den meisten nicht-trivialen Anwendungen immer noch manueller Unterstützung, damit alle benötigten Code-Referenzen zur Compile-Zeit aufgelöst werden können.
Die Build-Konfiguration hat sich dagegen deutlich vereinfacht, auch wenn diese in der Regel nur einmal in der Build-Pipeline vorgenommen werden muss.
Ist Spring Native "ready for production"? Prinzipiell ja, jedoch sollte man gerade bei umfangreicheren Anwendungen mit vielen ausgefallenen Abhängigkeiten den initialen Setup-Aufwand berücksichtigen.
Wie geht es weiter?
Als Teil des Spring Boot Frameworks ist die Langfristigkeit des Spring Native Projekts nun gesichert, was auch mehr Sicherheit bei einer Umstellung produktiver Workloads verspricht.
Spannend wird zudem, wie sich die Unterstützung der nativen Kompilierung in den Spring-Komponenten und in der Community entwickelt. Spring verweist auf ein Repository, in dem sie selbst Code-Hints veröffentlicht haben. Es bleibt abzuwarten, ob und welche Projekte eine Unterstützung in Form von Spring Native Type Hints anbieten werden.
Fazit: Spring Boot ist inzwischen neben Frameworks wie Quarkus und Micronaut wieder ein ernstzunehmender Kandidat für die Entwicklung von Cloud-Ready Java-Anwendungen.
Weitere Einblicke teilen wir in unserem Vortrag beim Navigate Kongress.
Wir freuen uns auf spannende Diskussionen!
Dr. Benjamin Klatt ist IT-Architekt und Agile Coach. Seine Schwerpunkte liegen in der Digitalisierung von Produkten und Prozessen, Cloud- und Software-Lösungen sowie Innovationen und agilen Arbeitsweisen.
Matthias Kutz ist schwerpunktmäßig im Bereich Software-Analyse und -Entwicklung tätig. Matthias besitzt mehrjährige Erfahrung im Java-Umfeld. Außerdem engagiert er sich in unserem F&E-Bereich für Cloud-Themen rund um Docker und Continuous Delivery sowie für Künstliche Intelligenz.
Pia Diedam beschäftigt sich in Kundenprojekten und im Forschungs- und Entwicklungsbereich mit Softwarearchitekturen und deren Zukunftsfähigkeit mit Java. Aktuell liegt ihr Fokus auf dem Zusammenspiel von Cloud-Technologien und Java-Anwendungen, um bestehendes Wissen und Code weiterhin nachhaltig nutzbar zu machen.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
