Quarkus - Reaktives, Microservices & Deployment

Quarkus – Reaktives, Microservices & Deployment

0:00 Bis hierher haben wir eine solide Anwendung gebaut: strukturiert, mit Datenbank, konfigurierbar, getestet. Aber sie lebt noch für sich allein – auf unserem Rechner. Heute geht es um den letzten, entscheidenden Schritt: aus der guten Anwendung einen Dienst zu machen, der in der Cloud besteht. Der viele Nutzer gleichzeitig verträgt, der mit anderen Diensten spricht, ohne beim ersten Ausfall umzukippen, der sich beobachten lässt und der am Ende als fertiges Container-Paket ausgeliefert wird.

0:29 Reaktive Programmierung, Microservice-Bausteine, Observability, Deployment – das ist der Bogen dieses Abschlusstages. Behalten Sie im Kopf: Hier verwandelt sich Handwerk in Betrieb.

Reaktives, Microservices & Deployment

0:40 Der rote Faden bleibt unsere vertraute Kurs-API – wir machen sie jetzt betriebsfest. Vier Blöcke führen dahin: Zuerst schauen wir, wie ein Dienst mit wenigen Ressourcen viele Anfragen bedient. Dann lernen wir, wie Services miteinander reden, ohne sich gegenseitig mitzureißen. Anschließend machen wir den Dienst beobachtbar und sichern ihn ab.

1:01 Und zuletzt schnüren wir das Paket fürs Deployment. Am Ende steht kein Prototyp mehr, sondern ein resilienter, auslieferbarer Microservice – und der Abschluss unserer dreiteiligen Reise.

Reaktive Programmierung

1:12 Beginnen wir mit einer Frage, die in der Cloud über Kosten entscheidet: Wie bedient ein Dienst möglichst viele Nutzer mit möglichst wenig Ressourcen? Die Antwort führt uns zur reaktiven Programmierung – und sie ist weniger exotisch, als der Name klingt. Stellen Sie sich einen guten Kellner vor. Ein schlechter würde an einem Tisch stehen bleiben, bis das Essen fertig ist – und alle anderen Gäste warten lassen.

1:36 Ein guter nimmt die Bestellung auf, gibt sie in die Küche und kümmert sich derweil um den nächsten Tisch. Genau so arbeitet die reaktive Engine, auf der Quarkus aufbaut, namens Vert.x: Ein sogenannter Event Loop bedient mit ganz wenigen Threads sehr viele Verbindungen, indem er nie untätig wartet. Damit dieses asynchrone Hin und Her lesbar bleibt, gibt es Mutiny mit seinen Typen `Uni` und `Multi`.

1:59 Und Virtual Threads bieten einen bequemen Mittelweg – reaktiven Durchsatz, aber im vertrauten, geradlinigen Programmierstil. Warum dieser Aufwand? Weil das klassische Modell in der Cloud teuer wird. Traditionell bekommt jede Anfrage ihren eigenen Thread – und ein Thread, der auf die Datenbank wartet, blockiert kostbaren Speicher, ohne etwas zu tun.

2:19 Der Event Loop dreht das um: wenige Threads, hoher Durchsatz, weil niemand wartend herumsteht. Die goldene Regel dabei: Blockierende Arbeit gehört auf eigene Worker Threads, niemals auf den Event Loop – sonst steht der Kellner doch wieder still. Mutiny macht die asynchronen Abläufe lesbar und zusammensetzbar. Und Virtual Threads sind das Beste aus beiden Welten: den hohen Durchsatz bekommen Sie geschenkt, dürfen aber weiter geradlinigen, blockierenden Code schreiben.

2:47 Der rote Faden bei der Entscheidung ist eine einzige Frage: Blockiert dieser Code oder nicht? Ist die Arbeit nicht-blockierend, läuft sie wunderbar auf dem Event Loop, beschrieben mit Mutiny. Steckt dagegen ein blockierender Aufruf drin – etwa eine klassische Datenbankabfrage –, gehört er auf einen Worker Thread oder eben einen Virtual Thread.

3:07 Für die Rückgabe gilt: `Uni` für ein einzelnes Ergebnis, `Multi` für einen ganzen Strom von Werten. Wer lieber im gewohnten, imperativen Stil bleibt, setzt `@RunOnVirtualThread` davor. Und über allem thront die eine unumstößliche Regel, die man sich einrahmen sollte: Den Event Loop niemals blockieren. Diese Folie zeigt bewusst dieselbe Aufgabe in zwei Stilen nebeneinander – achten Sie auf den Unterschied im Denken, nicht auf die Syntax.

3:33 Oben der reaktive Weg: Der Endpunkt gibt kein fertiges Ergebnis zurück, sondern ein `Uni` – gewissermaßen ein Versprechen, dass die Kursliste später eintrifft. Der Thread ist derweil frei für andere. Unten derselbe Abruf, aber mit der Virtual-Thread-Markierung: Hier schreiben Sie ganz geradlinig, als würden Sie einfach die Liste holen und zurückgeben – und bekommen trotzdem den hohen Durchsatz.

3:56 Die Botschaft: Sie müssen sich nicht zwischen Effizienz und Lesbarkeit entscheiden. Quarkus bietet beide Türen zum selben Raum. Jetzt kommt eine Aufgabe, bei der die Entscheidung wichtiger ist als der Code. Modellieren Sie einen Endpunkt und treffen Sie dabei bewusst einen begründeten Trade-off: reaktiv mit `Uni` oder `Multi`, oder imperativ mit einem Virtual Thread.

4:18 Erfüllt ist das Ziel, wenn der Endpunkt korrekte Daten liefert und – das ist der Kern – Sie Ihre Wahl des Thread-Modells begründen können. Denn genau diese bewusste Entscheidung unterscheidet den Profi vom Zufallstreffer. Wer schneller fertig ist, nimmt den Stretch: Ergänzen Sie einen `Multi`-Stream, etwa über Server-Sent-Events, und erleben Sie, wie Daten kontinuierlich zum Client fließen.

4:40 Drei Fallen lauern hier besonders. Die gefährlichste zuerst: ein blockierender Aufruf auf dem Event Loop. Quarkus warnt dann sogar ausdrücklich mit „blocked event loop thread" – und das zu Recht, denn Sie legen damit Ihren guten Kellner lahm und alle anderen Anfragen stocken. Die zweite ist tückisch, weil scheinbar nichts passiert: Ein `Uni` oder `Multi`, das niemand abonniert, tut gar nichts – es ist lazy, es wartet auf den Startschuss.

5:05 Wer das nicht weiß, sucht lange nach einem Fehler, der keiner ist. Und die dritte ist eine Warnung vor Euphorie: Virtual Threads sind kein Freifahrtschein – der Kontext, in dem sie laufen, will trotzdem bedacht sein.

Microservice-Bausteine

5:18 Ein Dienst allein ist selten. In der Cloud reden Services miteinander – und genau da beginnt es interessant zu werden. Denn was passiert, wenn der Dienst, den ich anrufe, gerade nicht abhebt? Sobald Ihr Dienst einen anderen anruft, brauchen Sie drei Dinge. Erstens einen bequemen Weg, überhaupt zu telefonieren: Der typsichere REST Client von Quarkus lässt Sie einen entfernten Dienst wie ein simples Java-Interface ansprechen – Sie beschreiben nur, was Sie wollen, den mühsamen HTTP-Code erledigt Quarkus.

5:48 Zweitens einen Schutz gegen die Tücken verteilter Systeme: SmallRye Fault Tolerance härtet die Aufrufe, für den Fall, dass die Gegenseite lahmt oder ausfällt. Und drittens eine gute Dokumentation: OpenAPI beschreibt Ihre Schnittstelle automatisch, damit andere wissen, wie sie mit Ihnen sprechen. Zusammen sind das die Grundbausteine, aus denen belastbare Microservices entstehen.

6:11 Der Nutzen liegt in weniger Code und mehr Widerstandskraft. Der typsichere REST Client ersetzt handgeschriebenen HTTP-Code durch ein sauberes Interface – der Compiler passt auf, nicht Sie. Wichtiger noch ist die Fehlertoleranz: Mit Bausteinen wie `@Retry`, `@Timeout` und `@CircuitBreaker` fangen Sie Ausfälle der Gegenseite kontrolliert ab, statt selbst mitzukippen.

6:33 Denken Sie an eine Sicherung im Stromkasten – lieber ein einzelner Stromkreis fällt aus, als das ganze Haus brennt. Und OpenAPI mit der Swagger UI dokumentiert Ihre API automatisch, immer aktuell. Unterm Strich: weniger Boilerplate, dafür deutlich mehr Resilienz – und in verteilten Systemen ist Resilienz keine Kür, sondern Überlebensfrage.

6:54 Der Weg zum abgesicherten Service-Aufruf ist erstaunlich kurz. Zuerst deklarieren Sie ein Interface und markieren es mit `@RegisterRestClient` – damit sagen Sie: Dieses Interface ist mein Draht zu einem entfernten Dienst. Die Basis-URL gehört dabei nicht in den Code, sondern in die `application.properties`, damit sie je Umgebung wechseln kann.

7:14 Dann härten Sie die Methoden: `@Retry` für einen zweiten Versuch, `@Timeout`, damit ein Aufruf nicht ewig hängt. Für wiederholte Fehler kommt der `@CircuitBreaker` dazu, der die Leitung vorübergehend kappt, statt immer weiter gegen eine Wand zu laufen. Zum Schluss werfen Sie einen Blick in die Swagger UI und sehen Ihre API dokumentiert.

7:34 Schauen Sie hier auf ein bemerkenswertes Verhältnis: Ein paar Zeilen Interface, und Sie haben einen robusten Fernaufruf. Das Interface beschreibt nur, was Sie wollen – die Kursliste von einem Katalog-Dienst. Keine einzige Zeile HTTP-Klempnerei; die generiert Quarkus für Sie. Das eigentlich Spannende sind die Markierungen darüber: Die eine sagt „versuch es notfalls noch einmal", die andere „warte höchstens zwei Sekunden, dann gib auf".

8:01 Diese Regeln stehen deklarativ am Interface, nicht als verstreute if-Abfragen im Code. So liest man die Ausfallstrategie auf einen Blick – und ändert sie an einer Stelle. Genau das macht verteilte Aufrufe wartbar statt fragil. Ihre Aufgabe bringt die Theorie in die Praxis: Kapseln Sie einen entfernten Service-Aufruf über den REST Client und sichern Sie ihn gegen Ausfälle ab.

8:23 Der Erfolg ist herrlich konkret – simulieren Sie einen Timeout und beobachten Sie, wie Retry oder Fallback greift und Ihre API antwortfähig bleibt, statt mit dem fremden Dienst unterzugehen. Das ist der Moment, in dem Ihr Service lernt, allein zu stehen. Wer noch Luft hat, nimmt den Stretch: Ergänzen Sie einen Fallback-Handler, der eine sinnvolle Ersatzantwort liefert, wenn die Gegenseite endgültig schweigt – etwa eine zwischengespeicherte Liste statt einer leeren Fehlermeldung.

8:50 Drei typische Konfigurationsfehler bei der Fehlertoleranz. Der erste ist verführerisch: `@Retry` ohne `@Timeout`. Sie wiederholen brav – aber wenn jeder Versuch ewig hängt, stauen sich die Aufrufe, und aus einem lahmen Dienst wird ein Dominoeffekt. Retry braucht immer ein Timeout als Partner. Der zweite betrifft den Circuit Breaker: Sind seine Schwellen zu eng gesetzt, schaltet er ständig ein und aus – er „flappt". Sind sie zu weit, schützt er gar nicht.

9:18 Die richtige Einstellung ist Fingerspitzengefühl. Und der dritte ist ein alter Bekannter aus dem Konfigurations-Kapitel: die Basis-URL im Code fest verdrahtet, statt in der Konfiguration. Was sich je Umgebung ändert, gehört nach außen. Ein kurzer Ausblick auf eine ganz andere Art, Services zu verbinden – heute nur als Demo, nicht als Übung. Bisher haben unsere Dienste direkt miteinander telefoniert.

9:42 Reactive Messaging geht einen Schritt weiter und entkoppelt sie über sogenannte Topics: Ein Dienst wirft eine Nachricht in einen Kanal, ein anderer nimmt sie auf – ohne dass beide gleichzeitig online sein müssen. In Quarkus geschieht das elegant mit Markierungen wie `@Channel` zum Senden und `@Incoming` zum Empfangen. Und typisch Quarkus: Die Dev Services starten Ihnen für die Entwicklung sogar automatisch ein Kafka im Hintergrund.

10:07 Das ist die Tür zu ereignisgetriebenen Systemen – ein großes Thema für einen eigenen Tag.

Observability & Security im Überblick

10:12 Ein Dienst, der in der Cloud läuft, wirft eine neue Frage auf: Woher weiß ich eigentlich, dass es ihm gut geht – und wer darf ihn überhaupt bedienen? Beobachtbarkeit und Sicherheit, darum geht es jetzt. Zwei Themen, die im Betrieb untrennbar zusammengehören. Observability, also Beobachtbarkeit, heißt: Ihr Dienst kann nach außen zeigen, wie es ihm geht.

10:34 Drei Bausteine liefern das – SmallRye Health meldet, ob der Dienst gesund ist; Micrometer sammelt Messwerte wie Last und Latenz; und OpenTelemetry verfolgt einzelne Anfragen quer über Dienstgrenzen hinweg. Denken Sie an die Instrumente im Cockpit: Sie fliegen nicht blind. Das zweite Thema ist Security: OIDC übernimmt die Anmeldung, und mit einer Markierung wie `@RolesAllowed` legen Sie fest, wer welchen Endpunkt benutzen darf – der Türsteher, der nach dem Ausweis fragt, bevor er jemanden einlässt.

11:04 Warum ist das im Betrieb unverzichtbar? Weil Kubernetes, die übliche Cloud-Umgebung, ständig wissen will, ob es Ihren Dienst neu starten oder Verkehr zu ihm schicken darf – genau das signalisieren die Health Checks mit Liveness und Readiness. Die Micrometer-Metriken zeigen Ihnen Last, Latenz und Fehlerraten, damit Sie Probleme sehen, bevor die Nutzer sie melden.

11:25 Das OpenTelemetry-Tracing verfolgt eine Anfrage über mehrere Dienste hinweg – unbezahlbar, wenn irgendwo im Zusammenspiel etwas klemmt. Und OIDC delegiert die heikle Authentifizierung an einen spezialisierten Identity Provider, statt dass Sie Passwörter selbst verwalten. Kurz: Sicherheit vor Bequemlichkeit – und Sichtbarkeit vor bösen Überraschungen.

11:46 Der Weg zu einem beobachtbaren, abgesicherten Dienst ist gut sortiert. Zuerst holen Sie die passenden Extensions ins Projekt – für Health, Metriken und Tracing. Dann prüfen Sie den Gesundheitsstatus unter `/q/health` und die Messwerte unter `/q/metrics`; beide Endpunkte liefern die Extensions praktisch geschenkt. Für die Sicherheit konfigurieren Sie die OIDC-Extension und verbinden sie mit Ihrem Identity Provider.

12:10 Und der entscheidende Handgriff zum Schluss: Sie schützen die sensiblen Endpunkte mit `@RolesAllowed`, sodass nur berechtigte Rollen durchkommen. Fünf Schritte – und aus dem offenen Dienst wird einer, der sich zeigt und sich schützt. Diese Folie zeigt beide Themen in je einem winzigen Beispiel – achten Sie auf das Prinzip.

12:30 Oben ein Readiness-Check: eine kleine Klasse, die auf Nachfrage schlicht „ich bin bereit" meldet, hier für die Datenbank. Kubernetes fragt genau das regelmäßig ab, um zu entscheiden, ob es Verkehr schicken darf. Unten der Rollenschutz: Der Löschen-Endpunkt trägt die Markierung, dass nur die Rolle „admin" ihn aufrufen darf. Wer ohne diese Rolle klopft, kommt nicht rein.

12:53 Das Schöne an beidem: Es ist deklarativ. Sie schreiben keine Prüf-Logik aus, Sie markieren die Absicht – und das Framework setzt sie durch. Sichtbarkeit und Schutz, jeweils in wenigen Zeilen. Jetzt machen Sie Ihre Kurs-API betriebsreif. Die Aufgabe hat zwei Seiten: Machen Sie den Dienst beobachtbar und sichern Sie einen Endpunkt rollenbasiert ab.

13:15 Der Erfolg ist doppelt messbar – der Health-Endpunkt unter `/q/health` meldet sauber UP, und ein Aufruf ohne passende Rolle wird korrekt mit HTTP 403 abgewiesen. Damit hat Ihr Dienst zum ersten Mal beides: Er zeigt, wie es ihm geht, und er lässt nicht jeden an die heiklen Funktionen. Wer noch mag, nimmt den Stretch: Ergänzen Sie eine eigene Micrometer-Metrik, etwa einen Zähler für angelegte Kurse, und beobachten Sie ihn unter `/q/metrics`.

13:42 Drei Missverständnisse, die im Betrieb echten Ärger machen. Das erste ist subtil, aber folgenreich: Liveness und Readiness verwechseln. Liveness fragt „lebst du noch?", Readiness „bist du bereit für Verkehr?". Wer sie vertauscht, provoziert entweder unnötige Pod-Neustarts oder schickt Anfragen an einen Dienst, der noch gar nicht so weit ist.

14:02 Das zweite ist eine trügerische Sicherheit: Wer Security nur ohne echten Identity Provider testet, erlebt in der Entwicklung leicht ein falsches Erfolgserlebnis – es sieht geschützt aus, ist es aber nicht. Und das dritte betrifft das Tracing: ohne Sampling verfolgen Sie in der Produktion jede einzelne Anfrage und ertrinken in Daten. Weniger ist hier oft aussagekräftiger.

Packaging & Deployment

14:24 Und nun der letzte Schritt der ganzen Reise: Aus dem fertigen Code wird ein auslieferbares Paket. Wie verpacke ich meinen Dienst so, dass er in der Cloud landet – und welche Verpackung passt zu welchem Zweck? Verpacken heißt: aus Ihrem Projekt ein lauffähiges Artefakt schnüren – und da hat Quarkus mehrere Formate im Angebot.

14:44 Das Fast-JAR ist die schlanke Standard-Variante, optimiert für schnellen Start auf der JVM. Das Uber-JAR packt buchstäblich alles in eine einzige Datei – praktisch zum Weitergeben. Das Native Image ist die radikalste Form: Mit GraalVM wird daraus ein eigenständiges Programm, das in Millisekunden startet und kaum Speicher braucht.

15:04 Und das Leyden-AOT-Caching ist ein neuer Mittelweg, noch in der Vorschau. Aus jedem dieser Artefakte machen mitgelieferte Dockerfiles und Image-Extensions am Ende einen Container – die Standard-Kiste, in der Software heute in die Cloud reist. Warum überhaupt die Wahl – warum nicht immer dasselbe? Weil jede Variante ihren Sweet Spot hat.

15:25 Das Fast-JAR bietet schnellen JVM-Start und ist für die allermeisten Fälle die vernünftige Standardwahl. Das Uber-JAR glänzt, wenn Einfachheit zählt: alles in einer Datei, leicht zu kopieren und zu starten. Das Native Image spielt seine Stärke dort aus, wo jede Millisekunde und jedes Megabyte zählt – bei Serverless und Scale-to-zero, wo ständig neue Instanzen blitzschnell hochfahren.

15:48 Und Leyden-AOT verspricht schnelleren JVM-Start, ganz ohne den aufwendigen Native-Build – noch Preview, aber vielversprechend. Die Kunst, die Sie hier lernen: die Verpackung bewusst zum Einsatzzweck wählen, nicht aus Gewohnheit. Die eigentliche Aussage dieser Tabelle ist kein Sieger, sondern ein Tauschgeschäft mit drei Größen: Startzeit, Speicher und Build-Dauer.

16:11 Das Fast-JAR startet in rund einer Sekunde, braucht moderaten Speicher – und ist schnell gebaut. Bequem für den Alltag. Das Native Image dreht die Startzeit auf einen Wimpernschlag und den Speicher aufs Minimum – bezahlt das aber mit einem spürbar langen Build. Und Leyden-AOT liegt bewusst dazwischen: schneller Start, moderater Speicher, mittlere Build-Dauer.

16:32 Der Punkt, den Sie mitnehmen sollten: Was Sie beim Start und Speicher gewinnen, zahlen Sie oft bei der Build-Zeit – und was in der Entwicklung nervt, kann in der Produktion Gold wert sein. Es gibt kein kostenloses Bestes. Gehen wir den Weg vom Code zum laufenden Container durch. Zuerst bauen Sie das Native Image – ein Kommando genügt, GraalVM oder Mandrel erledigt die Schwerarbeit.

16:55 Dann messen Sie: Startzeit und Speicherverbrauch gegen das gewohnte Fast-JAR – Zahlen sagen mehr als Bauchgefühl. Als Nächstes wählen Sie, wie das Container-Image entsteht: mit jib ganz ohne Docker-Daemon oder klassisch über Docker. Sie bauen das Image und starten es einmal lokal, um zu sehen, dass alles läuft. Und der Ausblick am Horizont: Von hier ist es nur noch ein kleiner Schritt, dieses Image nach Kubernetes zu deployen – dorthin, wo Ihr Dienst am Ende wirklich zu Hause ist.

17:24 Achten Sie hier nicht auf die genauen Befehle, sondern auf die kurze Kette, die dahintersteht: von Quellcode zu laufendem Container in drei Schritten. Der erste Befehl baut das Native Image – das ist der aufwendige, aber lohnende Teil. Der zweite verpackt dieses Ergebnis in ein Container-Image, die standardisierte Kiste für die Cloud.

17:43 Und der dritte startet diese Kiste lokal, mit einem durchgereichten Port, sodass Sie Ihren Dienst sofort im Browser erreichen. Das ist der ganze Zauber des Deployments, entmystifiziert: bauen, verpacken, starten. Genau diese drei Schritte laufen später in Ihrer Pipeline automatisch – hier machen Sie sie einmal von Hand, um zu verstehen, was passiert.

18:03 Diese Aufgabe ist bewusst eine Messaufgabe, keine Bauaufgabe. Das Lernziel ist, eine Build-Variante bewusst zu wählen und ihren Gewinn nicht zu glauben, sondern zu belegen. Bauen Sie also ein Native Image und stellen Sie zwei Zahlen daneben, die Sie selbst erhoben haben: Startzeit und Speicherverbrauch, jeweils im Vergleich zum Fast-JAR.

18:23 Genau das ist das Erfolgskriterium — das Image startet, und der Vergleich ist dokumentiert. Denn erst diese Zahlen machen die Entscheidung im Projekt später diskutierbar. Wer mag, zieht denselben Vergleich noch mit dem AOT-Caching aus dem Leyden-Umfeld — dann sehen Sie, dass der Weg zu schnellen Starts nicht nur über Native führt.

18:42 Beim Packaging lauern drei typische Missverständnisse. Der Native-Build braucht deutlich mehr Zeit und Arbeitsspeicher als ein normaler Build — wer das in der CI nicht einplant, bekommt Läufe, die scheinbar grundlos abbrechen. Zweitens: Reflection, die nicht registriert ist, funktioniert im JVM-Modus klaglos und bricht im Native Image.

19:02 Das ist der Klassiker, weil der Fehler erst dort auftaucht, wo man ihn am wenigsten sucht. Und drittens werden Uber-JAR und Fast-JAR gern verwechselt — sie haben unterschiedliche Startpfade, und was für das eine gilt, gilt für das andere nicht. Alle drei sind keine Argumente gegen Native, aber gute Argumente dafür, es früh auszuprobieren statt kurz vor dem Release.

19:24 Fassen wir die roten Fäden aller drei Kapitel zu einer Handvoll Merksätze zusammen – das ist die Essenz zum Mitnehmen. Nutzen Sie in der Produktion die LTS-Version und machen Sie Dev Services und Continuous Testing zum festen Teil Ihres Arbeitsflusses – sie kosten nichts und sparen viel. Steuern Sie Verhalten über Profile und halten Sie Secrets konsequent aus den Properties heraus, in Umgebungsvariablen.

19:47 Verwalten Sie Ihr Datenbankschema mit Flyway-Migrationen statt mit dem gefährlichen `drop-and-create`. Und schreiben Sie keinen Boilerplate, den Panache oder Jakarta Data Ihnen längst abnehmen. Das sind keine Geschmacksfragen, sondern hart erarbeitete Erfahrungswerte – wer sie beherzigt, erspart sich die meisten typischen Schmerzen.

20:06 Zum Schluss ein Blick auf das, was jenseits dieses Workshops wartet – Türen, die jetzt für Sie offenstehen. Besonders spannend: Quarkus LangChain4j bringt KI-Integration direkt in Ihren Java-Code, ein hochaktuelles Feld. GraphQL ist eine flexible Alternative zu REST, wenn Clients sich ihre Daten selbst maßschneidern sollen.

20:25 WebSockets Next öffnet die Tür zu echter Zwei-Wege-Kommunikation in Echtzeit. Und Reactive Messaging mit Kafka führt Sie tief in ereignisgetriebene Systeme, das große Thema, das wir vorhin nur angerissen haben. Sie müssen nicht alles auf einmal angehen – aber es ist gut zu wissen, dass Quarkus mit Ihren Ansprüchen mitwächst.

Danke!

20:45 Damit schließt sich der Kreis über drei Kapitel: Grundlagen, Kernkonzepte und heute das Reaktive samt Deployment. Erinnern Sie sich, wo wir angefangen haben – bei der Frage „Warum überhaupt Quarkus?". Inzwischen haben Sie einen ganzen Weg zurückgelegt: vom ersten REST-Service über eine getestete Anwendung bis zum resilienten, auslieferbaren Microservice.

21:06 Das ist eine ordentliche Strecke für drei Tage. Alle Materialien liegen zum Nacharbeiten in der Freigabe, und bei Fragen erreichen Sie uns unter info@HCO.de. Ich danke Ihnen herzlich für Ihre Aufmerksamkeit und Ihr Mitmachen – und wünsche Ihnen viel Freude und Erfolg beim Weiterbauen mit Quarkus.