© Enkel/Shutterstock.com
Serverless Java: Infrastrukturoverhead reduzieren

Leicht und schnell …


Nach wie vor ist Java die erste Wahl, wenn es um Softwareentwicklung für den Unternehmenseinsatz geht [1]. Allein mit der Entwicklung einer Java-Software ist es allerdings nicht getan: Für den Produktiveinsatz werden Maschinen, Betriebssysteme, JREs, Application Server etc. benötigt – und als Grundlage für die eigentliche Funktionalität im Code auch große Frameworks und Bibliotheken. Dieser Overhead schmerzt umso mehr, je einfacher die eigentlich benötigte Funktionalität ist, denn er erschwert Entwicklung, Tests und Betrieb. Der Gegenentwurf: Serverless.

Bei diesem Gegenentwurf wird die Software statt als eigenständig lauffähiges Binary als aufrufbare Funktion in ein passendes Umfeld deployt, das sich anstelle eines Application Servers und aller Infrastruktur darunter um die Verbindung zur Außenwelt kümmert. Bisher werden diese Funktionen lieber in JavaScript, Python und Go verfasst, u. a. wegen langer Startzeiten und hoher Speicheranforderungen JVM-basierter Anwendungen.

Dabei kann man auch sowohl von vorhandener Java-Erfahrung und bestehendem Code als auch vom reduzierten Aufwand für Deployment und Betrieb profitieren: Verbesserungen der JVM, neue schlanke Web-Frameworks wie Quarkus und Micronaut und Techniken wie Native-Image-Kompilierung mit GraalVM machen Java wieder interessant für den Einsatz im Serverless-Bereich. Dieser Artikel stellt einige Ansätze zur Verwendung von Java in Serverless-Umgebungen vor.

Anwendungsszenarien

Allgemein eignet sich ein Serverless-Ansatz gut für Aufgaben, die zu folgenden Nutzungsprofilen passen:

  • Asynchron, leicht parallelisierbar in unabhängige Ausführungseinheiten

  • Unregelmäßige oder sporadische Nachfrage mit großer, nicht vorhersehbarer Varianz des Nutzungsaufkommens

  • Zustandslos, kurzlebig, toleriert hohe Latenz

  • Schnell ändernde Geschäftsanforderungen mit Bedarf an hoher Entwicklungsgeschwindigkeit

Einige konkrete Beispiele sind:

  • Dateiverarbeitung nach Upload

  • WebHooks, um Logik mit HTTP-Aufrufen zu verbinden

  • Backgroundjobs – zeitgesteuerte Verarbeitungen

  • einfaches Backend für Web-Frontends

Grundlagen

Zwei Sichtweisen auf Serverless möchte dieser Artikel beleuchten: Entwicklung und Betrieb. Für den Entwickler bedeutet das, die Anwendungslogik in Form einfacher Funktionen zu implementieren. Für den Admin ist es eine einfache Art, Software zu deployen und zu betreiben, nämlich in entsprechenden lokalen oder Cloud-Umgebungen, die sich um das betriebsnotwendige Drumherum kümmern.

Einmal deployt, kann eine Funktion dann z. B. über HTTP, Messaging oder sonstige Ereignisse aufgerufen werden. Ein Beispiel ist die Erzeugung einer Vorschau für hochgeladene Fotos: Hat ein Nutzer ein neues Bild hochgeladen, so löst dieses Ereignis die Ausführung einer Funktion zur Erstellung einer Vorschau aus. Die Funktion kann selbst wieder andere Funktionen anstoßen.

Wie eine Serverless-Plattform intern arbeitet, ist letztendlich unerheblich für den Entwickler, solange sie ihm nur Boilerplate-Code abnimmt, z. B. den HTTP-Layer. Hat er seine Software hochgeladen, kümmert sich die Plattform um Betrieb und Skalierung der Funktion. Cloud-basierte Angebote berechnen Kosten nur für tatsächlich anfallende Ressourcennutzung, z. B. die verwendete CPU-Zeit, Arbeitsspeicher oder Anzahl der Aufrufe. Neben einem effizienten und ökonomischen Betrieb liegt somit der Fokus auf der Produktivität der Entwickler. Eine gute Zusammenfassung zum Thema bietet das Serverless Whitepaper der CNCF Serverless Working Group [2].

Geht eine Anfrage ein, die die Software bedienen soll, wird sie zunächst in einer Ausführungsumgebung gestartet und ein Endpunkt eingerichtet, der die Funktion aufruft, Argumente übergibt und das Ergebnis zurücksendet. Maßgeblich für die Performance ist dabei die Latenzzeit von der Anfrage bis zur Antwort, die der Entwickler zum einen über die Wahl der Plattform, zum anderen über geeignete Laufzeitumgebungen sowie Programmoptimierungen beeinflussen kann (Abb. 1). Anschließend kann die Plattform die Umgebung zerstören oder ggf. wiederverwenden. Plattformen begrenzen in der Regel die maximale Ausführungszeit einer Funktion z. B. auf 15 Minuten, danach wird die Ausführung abgebrochen.

Funktionen müssen z...

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

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang