Cloud Plattformen wie AWS bieten Unternehmen eine hohe Flexibilität und ermöglichen den Aufbau der IT Infrastruktur in kurzer Zeit. Wir kamen mit der AWS Plattform in Kontakt als wir für unsere Kollegen aus der Buchhaltung ein Tool entwickeln sollten mit dem einige Prozesse optimiert werden können. Nach einer Versuchs- und Einarbeitungsphase war klar, dass AWS Lambda für unseren Anwendungsfall am besten geeignet war.
Wir stellten nach dem ersten Deployment fest, dass die serverless Function für uns im Vergleich zu einer dauerhaft aktiven EC2 Instanz wesentlich kostengünstiger, jedoch mit Herausforderungen im Betrieb verbunden war.
Lange Startzeiten bei der Nutzung von Java in AWS Lambda
AWS Lambda schien die ideale Wahl zu sein, um bei möglichst geringen Kosten, gleichzeitig die notwendige Skalierbarkeit und Flexibilität bereitzustellen. Doch es gab ein entscheidendes Problem: Die Startzeiten der Java-Funktionen waren sehr langsam – im Durchschnitt hat dies circa 15 Sekunden gedauert. In unserem konkreten Beispiel war das Tool immer noch nutzbar, da die lange Startzeit für den User vorerst nur eine Unannehmlichkeit darstellt.
Aus technischer Sicht hingen diese langen Startzeiten mit dem Starten der Java Virtual Machine (JVM) zusammen. Um Java Anwendungen auszuführen benötigt man eine JVM. Diese zu initialisieren benötigt eine bestimmte Zeit. Auch mit mehr Rechenleistung lässt sich die Initialisierung nicht signifikant beschleunigen, sodass in unserem Fall eine Java Anwendung für die Nutzung auf AWS Lambda nicht wirklich geeignet schien. Im Falle weiterer Skalierung könnte das Problem zur Unbrauchbarkeit des Tools führen.
Die Lösung für das Startzeitproblem
Auf unserer Suche nach einer geeigneten Möglichkeit, das Problem der langen Startzeiten zu beheben, haben wir uns für GraalVM entschieden. Mittels dieser Lösung konnten wir die Startzeit wesentlich verringern, sodass diese durchschnittlich nur noch 3 Sekunden betrug.
GraalVM ermöglicht es mittels “ahead of time Compilation”, Java-Anwendungen in native Binärdateien zu kompilieren. Dies bedeutet, dass der Java-Code nicht mehr von einer virtuellen Maschine interpretiert werden muss, sondern direkt als ausführbare Binärdatei vorliegt. Somit entfällt die Notwendigkeit, eine JVM zu initialisieren. Dies umgeht unser Problem geschickt und verkürzt die Startzeit auf der Lambda Funktion wesentlich. Zusätzlich sind noch weitere Vorteile festzustellen.
Optimale Ressourcennutzung: Die mit GraalVM erstellten Binärdateien sind nicht nur schnell, sondern auch äußerst ressourceneffizient. Sie beansprucht weniger Speicherplatz, was langfristig Kosten einsparen wird.
Reibungslose Integration: Die Integration von GraalVM in den AWS Lambda-Workflow kann ohne Probleme durchgeführt werden. Wir entwickeln unsere Anwendung in gewohnter Weise weiter und nutzen dann GraalVM, um sie in native Binärdateien umzuwandeln. Umfangreiche Konfigurationen oder Anpassungen im Entwicklungsprozess sind nicht erforderlich.
Die Zukunft von Java in serverlosen Umgebungen
Die Nutzung von GraalVM für unser Buchhaltungstool war nicht nur der richtige, sondern auch ein lehrreicher Schritt. Wir konnten die Herausforderung der langen Startzeiten unserer Java-Anwendungen effektiv bewältigen und gleichzeitig die Effizienz unserer Anwendung steigern.
Die Kombination von GraalVM und AWS Lambda zeigt, dass Java auch in serverlosen Umgebungen eine Zukunft hat. Entwickler können jetzt Java-Anwendungen erstellen, die schnell und effizient auf Anfragen reagieren. Durch den Wegfall der JVM können nun mehr Ressourcen in die eigentliche Anwendung gesteckt werden und auch kompliziertere Anwendungsfälle in AWS Lambda umgesetzt werden. Zudem können die Kosten für die Bereitstellung reduziert werden, da zusätzlich Arbeitsspeicher eingespart und die Laufzeiten verringert werden.
Wir können natürlich nicht erwarten, dass mit GraalVM die Grenzen des Unmöglichen überwunden werden, doch war es uns möglich ein Problem zu lösen was eigentlich untrennbar mit Java verbunden war. Dies war nur möglich, da GraalVM mit der “ahead of time Compilation” einen entscheidenden Schritt gegangen ist und damit die JVM, das ursprünglich überzeugende Argument von Java, als Abhängigkeit entfernt werden konnte.
