Lange Zeit war Spring zusammen mit Spring Boot der Defacto-Standard, wenn es um die Entwicklung von Microservices bei hoher Entwicklerproduktivität ging. Nun schicken die Entwickler von Grails ein neues Framework ins Rennen: Micronaut.

Das Versprechen von Micronaut: Aus den Ansätzen von Grails, Spring Boot und Spring zu lernen und ein Framework bereitzustellen, das den Anforderungen von modernen Cloud- und Microserviceumgebungen gewachsen ist.
Aus technischer Sicht sind einige Punkte, wie minimierter Einsatz von Java-Reflection und Proxies, spannend, die für die Verwendung der Substrate VM und Graal relevant sind.

Werfen wir einen Blick auf Micronaut - eine Einführung.

Java Anwendungen haben den Ruf, schwergewichtig und langsam zu sein. Langsam ist Java dank ausgefeilter Optimierungen der JVM zwar nicht (mehr), jedoch sind Docker Container Images von Anwendungen relativ gross.

Das ist dadurch bedingt, dass eine JVM und ein Betriebssystem mitgeliefert werden muss, damit die Java Anwendung im Docker Container ausgeführt werden kann.

In aktuellen Java Versionen ist dank GraalVM die Möglichkeit gegeben, Java Anwendungen als native Programme zu kompilieren und statisch zu linken. Damit ist weder eine JVM noch ein Betriebssystem im Container Image erforderlich - vergleichbar mit dem aus der Go Welt bekanntem Vorgehen.

Wie das ganze funktioniert, wird im folgenden Beitrag vorgestellt.

gRPC hat bisher vor allem im Backend oder bei der direkten Kommunikation zwischen Anwendungen auf dem Endgrät und dem Backend eine Rolle gespielt. Aufgrund der zunehmenden Rolle von Browseranwendungen sollte gRPC auch in clientseitigen Webanwendungen genutzt werden können.
Das zugehörige Projekt ist gRPC-Web: https://github.com/grpc/grpc-web

In diesem Beitrag wurde die Erstellung eines Spring Boot gRPC Backends demonstriert. Nun get es darum, das Backend in einer Angular Webanwendung mit gRPC-Web anzubinden.

In verteilten Systemen, zu denen etwa solche mit Microservice- und Cloud-Architekturen zählen, müssen in der Regel über Anwendungsgrenzen hinweg Funktionsaufrufe erfolgen. Typischerweise kommt dabei für synchrone Aufrufe HTTP als Transportschicht zum Einsatz, das Format der ausgetauschten Daten kann XML, JSON oder eine andere spezifische Datenstruktur sein. Welche HTTP-Verben und welche Adressen (URLs) wie zu verwenden sind, ist dabei eine fast schon in philosophische Bereiche ausufernde Debatte zwischen den verschiedenen Ansätzen. Am häufigsten finden sich REST und Abwandlungen davon als Schnittstellenkonzept.

Im Gegensatz zu der reichhaltigen API-Oberfläche von REST findet sich SOAP als XML-basiertes RPC- (Remote-Procedure-Call-) Verfahren, bei dem lediglich HTTP POST-Requests zum Einsatz kommen. Neben dem oft als schwerfällig bezeichneten Vorgehen von Design und Implementierung von SOAP-Schnittstellen hat XML als Transportformat auch deutliche Auswirkungen auf möglichen Durchsatz und erforderliche CPU- und Speicherresourcen bei der Verarbeitung.

Als Alternative zu diesen Ansätzen hat Google gRPC entwickelt: gRPC setzt ebenfalls auf HTTP auf, verwendet jedoch Google Protocol Buffers als optimiertes Datenformat. Wie der Einsatz im Kontext einer Java-Spring-Boot-Anwendung aussehen kann, wird im Folgenden dargestellt.

Mit Docker haben sich Container als Auslieferungsformat (nicht nur) für Microservices zum Status Quo für Cloudanwendungen etabliert. Zur Erstellung der Container-Images war lange Zeit Zugriff auf einen Docker-Daemon erforderlich. Besonders in Umgebungen wie Kubernetes-Clustern oder Public-Clouds mit gemeinsam genutzter Infrastruktur soll auf privilegierte Container verzichtet werden. Mit dem typischen Ansatz von Docker-in-Docker oder Docker-Outside-Docker erhält ein so ausgeführter Build nämlich relativ viele Rechte. Dank der OCI Spezifikation für Image-Formate ist Docker mit einem Dockerfile jedoch nur noch eine Möglichkeit, zum auslieferbaren Image zu gelangen.

Ein weiterer Aspekt sind die oft schwer umzusetzenden Optimierungsmöglichkeiten für Docker Images: Um vom Layer-Caching optimal zu profitieren und damit sowohl I/O-Operationen als auch Speicherplatz zu sparen, sollten die Daten, die sich weniger häufig ändern, in einem separaten Layer positioniert werden, als Daten, die sich regelmäßig ändern. Bei einer Spring Boot Anwendung könnte man zum Beispiel zwischen allen Abhängigkeiten und den eigentlichen, zu der Anwendung selbst gehörenden Class-Dateien differenzieren: Die Abhängigkeiten werden sich seltener ändern, als das Programm, das bei jedem Bugfix und jeder Erweiterung Änderungen erfährt. Nur dieser geänderte Image-Layer muss dann verteilt werden.

Für beide Probleme soll das Google Projekt "Jib" eine Lösung liefert. Am Beispiel einer Spring Boot Anwendung und Maven wird der Einsatz von Google Jib demonstriert.

Die Beispielanwendung kann z.B. von hier bezogen werden: https://github.com/trion-development/spring-boot-rest-sample

Im Markt der Serverless-Ansätze positioniert sich Oracle mit Project Fn. Dieser Beitrag demonstriert den Einsatz des Fn Project um mittels Docker oder Kubernetes Function-As-A-Service (FaaS) bzw. Serverless Architekturen umzusetzen. Als Demo wird eine Java Anwendung mit Project Fn als Docker-Container erstellt und im Fn Server betrieben.

Der Trend weg von großen, schwerfälligen Applikationsservern hin zu Microservices und Containern wird durch die Cloud als Ablaufumgebung stark beschleunigt. Konsequent weitergedacht erhält man noch kleinere Dienste, Nanoservices, die lediglich einzelne Funktionen umsetzen. Als minimale Deploymenteinheit lässt sich darüber eine feingranulare Skalierung erzielen, und durch verringerten Overhead eine kosteneffiziente Nutzung der Infrastruktur realisieren. Vorreiter war Amazon mit Lambda, doch auch andere Cloud Anbieter zogen schnell nach, und bieten Function-as-a-Service (FaaS) oder "serverless" Umgebungen an.

Kubernetes als De-facto-Standard für containerbasierte Cloudinfrastruktur bietet von Haus aus zwar kein vergleichbares Modell an, jedoch gibt es mit Oracle Fn, Kubeless und Open Whisk zahlreiche Projekte, die FaaS als OpenSource Plattform für den Einsatz in eigener Cloudinfrastruktur oder auch öffentlichen Kubernetes Cloud-Runtimes ermöglichen wollen.

Im folgenden wird ein kurzer Blick auf Kubeless in Kombination mit Java geworfen. Ausschlaggebend für diese Auswahl war ein relativ unkompliziertes Setup, wodurch die Hemmschwelle für Experimente verringert wird.

Im April hat Thomas Kruse in München einen Workshop zum Thema "Reactive Programming" mit Java gegeben. Die kostenlose Veranstaltung richtete sich an alle interessierten Personen, die in rund zwei Stunden sowohl Hintergründe zu reaktiver Programmierung, als auch erste eigene praktische Erfahrungen sammeln wollten.

Auf der diesjährigen JavaOne in San Francisco war die trion mit durch Speakern vertreten: Stefan Reuter, Karsten Sitterberg und Thomas Kruse. Stefan und Karsten hatten den Schwerpunkt "reactive Programming", bei dem Architekturaspekte und Umsetzungsoptionen aufgezeigt wurden. Stefan Reuter lieferte neben einer Einführung in RxJava auch Beispiele und Hinweise zur Implementierung reaktiver Backends mit Spring bzw. Spring Boot.

Karsten Sitterberg zeigte wie mit RxJS und dem Angular 2 JavaScript Framework reaktive Frontends implementiert werden können. Thomas Kruse befasste sich mit dem Thema Microservices, DevOps und Integration mit relationalen Datenbanken.

Die diesjährige JavaOne findet vom 18. bis 22. September in San Francisco statt.

Neben dem wichtigen Austausch mit der internationalen Entwicklercommunity und der Pflege von Kontakten steht für uns die aktive Beteiligung im Mittelpunkt. So werden Karsten Sitterberg und Stefan Reuter mit dem Talk CON3285: Reactive Everywhere vertreten sein und Thomas Kruse wird als Organisator der Java User Group in Münster auf dem JUGs Sunday sprechen.

In Kundenprojekten taucht immer wieder in der einen oder anderen Variante die Fragestellung auf: Wie kann eine bestehende Java Swing Anwendung am besten in das Web-Zeitalter migriert werden?

Wir haben uns eingehend mit der Anforderung und möglicher Lösungswege befasst…​