Java reloaded – 99 Prozent Serverkosten eingespart
Wir unterstützen Mercedes-Benz bei der Kostenreduzierung einer Java-Anwendung dank des Einsatzes von GraalVM und Serverless Computing.
Mehr lesen Java reloaded – 99 Prozent Serverkosten eingespart
Du möchtest die „echten“ Hyperscaler-Vorteile für bereits existierende Java-Anwendungen voll ausnutzen? Wir machen es mit der Kombination aus GraalVM und Serverless Computing ohne Code-Anpassungen und ohne Vendor-Lock-in möglich.
Hoher Speicherbedarf, lange Startzeit und schwere horizontale Skalierbarkeit: Der Ressourcenbedarf cloudbasierter Java-Anwendungen ist nicht zu unterschätzen. Wenn dann noch mehrere Server zwecks Ausfallsicherheit parallel im Einsatz sind, können der Stromverbrauch und damit der Kostenaufwand immens sein.
Dabei ist es vor allem der klassische Non-Stop-Betriebsmodus, der die Kosten in die Höhe treibt. Denn auch, wenn die Zugriffe wie bei einem Online-Shop unregelmäßig und verteilt erfolgen, muss die Anwendung stets am Laufen sein.
Eine Lösung ist das Serverless Computing, bei dem Hyperscaler wie AWS, Azure & Co. die benötigte Serverinfrastruktur virtuell zur Verfügung stellen und sich um die Provisionierung, Verwaltung, Sicherheit und Skalierung kümmern.
Entwickler:innen müssen nur noch die Anwendung bereiststellen und schon lässt sich die Serverless-App bedarfsabhängig ausführen und automatisch nach oben oder unten skalieren.
So wird die Java-App nur dann gestartet, wenn ein Zugriff erfolgt. Und ganz gleich, ob ich null, tausend oder eine Million Anfragen auf meine Anwendung habe: Sie lässt sich immer so skalieren, dass sie genau diese Anzahl an Anfragen verarbeiten kann.
Drei Nachteile bleiben allerdings:
Der erhöhte Speicherbedarf,
die lange Startzeit
und der Vendor-Lock-in, der sich durch die speziell für z. B. AWS Lambda angepasste Anwendung ergibt.
Hier kommt GraalVM ins Spiel: Das Java Development Kit von Oracle nutzt einen fortschrittlichen „ahead-of-time Compiler“ für eine Vielzahl von Programmiersprachen, um nativ ausführbare Dateien (native image) zu erstellen. Diese lassen sich im Vergleich zum klassischen Java mit einer deutlich besseren Startzeit und wesentlich geringerem Speicherbedarf ausführen.
Der eigentliche Clou im Teamplay mit dem Serverless Computing: Neben den genannten Skalierungsvorteilen lassen sich die Server mit diesen Executables innerhalb weniger Millisekunden und bei einem Bruchteil der sonst benötigten Servergröße starten.
Bei unserem Vorgehen gibt es außerdem keinen Vendor-Lock-in: Die Java-Anwendung wird so gebaut, dass man sie unabhängig von AWS & Co. jederzeit zu einem anderen Hyperscaler mitnehmen kann.
So müssen die Server weder im Non-Stop-Betriebsmodus laufen, noch benötigt man redundante Systeme, um Ausfallsicherheit zu garantieren. Und da die Java-Anwendung bei einer beliebigen Anzahl von Zugriffen in nahezu Echtzeit verfügbar ist, bekommen die Anfragenden davon gar nichts mit.
Das Ergebnis, das wir für unseren Kunden Mercedes-Benz bei einem Projekt rund um Sicherheits-Updates in der Werkstatt erreichen konnten, spricht Bände:
Senkung der Serverkosten um bis zu 99 Prozent
Reduzierung der Servergröße auf ein Zehntel
Optimierung der Java-Startzeit auf weniger als eine Sekunde
Deutlich reduzierter Entwicklungsaufwand zur Skalierung
Rückgang der Serverkosten
Nein, durch das beschriebene Vorgehen muss der Code für den Switch auf GraalVM und Serverless Computing überhaupt nicht oder nur minimal angepasst werden. Developer:innen können wie gewohnt ihre Java-Anwendungen entwickeln, sie werden lediglich durch einen angepassten Build-Prozess anders ausgespielt und bereitgestellt.
Das bietet den Vorteil, dass die Einsparungen sich sehr schnell amortisieren und eine langwierige und kostspielige IT-Modernisierung und Migration nicht nötig ist. Die einzige Voraussetzung, um Java-Anwendungen mit GraalVM fit fürs Serverless Computing zu machen, liegt darin, sie zunächst auf eine moderne Version zu aktualisieren.
Beim klassischen Setting macht man bei einer Java-Anwendung immer einen zusätzlichen Schritt. Vereinfacht beschrieben wird aus dem fertigen Code ein Zwischencode generiert, der in die Cloud ausgeliefert und erst einmal aufwändig gestartet wird.
Mit GraalVM lässt sich dieser Zwischenschritt überspringen: Der Code wird nicht erst während des Starts, sondern bereits initial bei der Auslieferung optimiert. So erhält man eine extrem effiziente Anwendung, deren Start direkt und schnell serverless möglich ist. Der Request startet also seinen eigenen kleinen Server, verarbeitet ihn und wird sofort wieder runtergefahren. Und da die App nativ kompiliert ist, geht es so fix, dass man es pro Request machen kann. Das Resultat sieht dabei nach außen immer gleich aus.
Da dafür zusätzliche Optimierungen durchgeführt werden müssen, liegt eine kleiner Nachteil allerdings darin, dass die initiale Erstellung der Anwendung länger dauert.
Ja, denn die Nutzung von GraalVM und Serverless Computing stellt einen bedeutenden Paradigmenwechsel dar: Anstatt lediglich ein Datacenter bei z. B. AWS zu betreiben, kann ich die Hyperscaler-Vorteile auch für bereits in die Jahre gekommene Java-Anwendungen voll ausnutzen.
Denn die Rechenkapazitäten lassen sich extrem schnell und ohne Aufwand hoch- und wieder runterfahren, ohne dass man sich Gedanken über Kapazitäten, Konfigurationen, Redundanzen usw. machen muss. Und das mit großen Auswirkungen schon bei kleinen Anwendungen – egal, ob die App einmal, fünfmal oder tausendmal angefragt wird.
Nutzt man diese Vorteile hingegen nicht voll aus, hätte man aus rein wirtschaftlicher Sicht auch gleich im On-Prem-Rechenzentrum bleiben können. Denn wenn die Anwendung 24/7 läuft, rechnet sich der Kauf von Servern für gewöhnlich in zwei bis drei Jahren. Letzendlich ergibt sich eine Win-Win-Situation, bei der ich für hochverfügbare Anwendungen weniger Ressourcen und Energie verbrauche und damit auch bedeutend weniger bezahle.
Im Prinzip können alle Java-Anwendungen vom GraalVM und serverless Teamplay profitieren, bei denen es auf eine hohe Performance, Zuverlässigkeit und Verfügbarkeit ankommt. Aber vor allem bei Anwendungen mit stark schwankenden Zugriffszahlen macht sich die Kombination schnell bezahlt.
Denn ich kann meine Auslastung, ohne dass ich mich manuell darum kümmern muss, automatisch an die eingehenden Anfragen anpassen. Am Beispiel eines Online-Shops wäre es damit nicht mal nötig, Ressourcen bei Rabattaktionen oder saisonalen Nachfragespitzen vorauszuplanen. Im Grunde braucht man sich gar keine Gedanken mehr über den Betrieb seiner Infrastruktur zu machen. Aber auch in vielen anderen Settings, in denen ich die Rechenleistung ohne Anfragen non-stop vorhalten und bezahlen müsste, macht sich das dynamische Java-Duo schnell bezahlt.
Ein Startvorteil liegt natürlich darin, wenn Unternehmen bereits Cloud-ready oder schon in der Cloud sind und damit die ersten technischen Voraussetzungen fürs Serverless Computing erfüllen.
Vielen ist der Effekt einer mit GraalVM optimierten Java-Anwendung längst klar, aber nicht der noch viel größere Effekt, den der gleichzeitige Sprung aufs Serverless Computing mit sich bringt. Und aus eigener Erfahrung wissen wir, dass sich das Thema mittlerweile von einer technischen Spielerei zu einem ernstzunehmenden IT-Produkt mit echtem Business Impact entwickelt hat.
Wir möchten, dass auch du davon profitierst. Deshalb haben wir die Stärken von GraalVM und Serverless Computing kombiniert, um daraus ein einzigartiges Angebot zu machen. Wann revolutionierst du deine existierenden Java-Anwendungen?
Wir unterstützen Mercedes-Benz bei der Kostenreduzierung einer Java-Anwendung dank des Einsatzes von GraalVM und Serverless Computing.
Mehr lesen Java reloaded – 99 Prozent Serverkosten eingespart
Sicher, datenschutzkonform und „privat“: Wir zeigen am Beispiel von Azure, wie du einen KI-basierten Chatbot in die Cloud implementierst.
Mehr lesen So geht´s mit dem eigenen GPT-Chatbot in die Cloud
Exxeta implementiert gemeinsam mit Mercedes-Benz Leasing Deutschland neue State-of-the-Art-Leasingplattform
Mehr lesen Pkw-Leasing neu gedacht