Quarkus als Modernisierungsoption

Quarkus als Modernisierungsoption

0:00 Jetzt das zweite mögliche Ziel. Quarkus spricht dieselben APIs wie der Application Server — Jakarta REST, CDI, Persistence, Transaktionen — und trifft dahinter trotzdem andere Entscheidungen. Genau diese Unterschiede sind für eine Migration entscheidend, denn sie bestimmen, was einfach übertragbar ist und was nicht. Wir sehen uns an, wie Quarkus aufgebaut ist und warum der Build so eine große Rolle spielt, welche Werkzeuge die Entwicklungsschleife verkürzen, und — besonders wichtig — wo die Grenzen liegen.

0:29 Denn Quarkus ist kein zertifizierter Jakarta-EE-Application-Server, und das ist keine Schwäche, sondern eine Entwurfsentscheidung.

Quarkus als Modernisierungsoption

0:38 Damit schließen wir den ersten Tag ab. Wir haben Ziele, ein Inventar, den Weg nach Jakarta EE 11, die Optionen und den Application Server im Container. Was jetzt noch fehlt, ist die ehrliche Einschätzung der Alternative — nicht als Werbeblock, sondern als Machbarkeitsprüfung. Am Ende dieses Moduls sollten Sie sagen können, welche Teile von Zählwerk auf Quarkus laufen könnten und welche nicht.

Architektur und Programmiermodelle

1:01 Beginnen wir mit der Grundidee. Sie lässt sich in einem Satz sagen: Was der Server bisher beim Start erledigt hat, erledigt jetzt der Build. Aus dieser einen Verschiebung folgt fast alles Weitere — der schnelle Start ebenso wie die Grenzen, über die wir im dritten Kapitel sprechen. Stellen Sie sich zwei Restaurants vor. Im ersten wird bei jeder Bestellung frisch geschnitten, gewogen und abgemessen.

1:24 Im zweiten ist alles vorbereitet, wenn die Gäste kommen — gekocht wird trotzdem erst dann, aber ohne Vorlauf. Genau das macht Quarkus: Arbeit, die klassische Laufzeiten beim Start erledigen — Beans ermitteln, Konfiguration auswerten, Metadaten erzeugen — wandert in den Build. Was zur Laufzeit übrig bleibt, ist kleiner und startet schneller. Der Preis dafür ist weniger Dynamik nach dem Build.

1:47 Für Dienste in Containern ist das ein guter Tausch, für einen klassischen Application Server wäre es keiner. Diese Gegenüberstellung erklärt fast alles, was in den nächsten Modulen an Unterschieden auftaucht. Links wird zur Laufzeit gescannt und verdrahtet, das Deployment kommt in eine bereits laufende Laufzeit, die Konfiguration gehört dem Server.

2:08 Rechts passiert die Ermittlung im Build, die Anwendung bringt ihre Laufzeit mit, und die Konfiguration gehört der Anwendung. Der sichtbare Effekt ist die Startzeit — aber der wichtigere Effekt ist der Besitz: Rechts gehört alles der Anwendung und liegt damit im Repository. Genau das ist es, was Reproduzierbarkeit ausmacht.

2:27 Vier Konsequenzen, und die zweite ist die praktisch bedeutsamste: Erweiterungen sind mehr als Bibliotheken. Sie bringen ihren Build-Anteil mit, also den Teil, der zur Bauzeit Metadaten erzeugt und Beans registriert. Wenn Sie eine Bibliothek einfach als normale Abhängigkeit einbinden, fehlt dieser Teil — und dann funktioniert vieles nicht, was Sie erwarten.

2:47 Der vierte Punkt ist für die Entscheidung wichtig: Dieselben Mittel tragen den JVM-Betrieb und die native Übersetzung. Sie müssen sich also jetzt nicht festlegen; die Frage JVM oder nativ behandeln wir in Modul sechzehn mit Messwerten statt mit Meinungen. Worauf es hier ankommt, ist nicht die Syntax, sondern zwei Konzepte. Erstens: Sie wählen beim Anlegen die Erweiterungen — hier REST mit Jackson und Hibernate.

3:12 Das ist die Entsprechung zu dem, was Sie in Modul zwei im Inventar gefunden haben, nur eben als Liste von Erweiterungen. Zweitens, und das steht in der Fußzeile: Die Plattform-BOM hält die Versionen aller Erweiterungen konsistent. Sobald Sie anfangen, einzelne Versionen von Hand zu setzen, brechen Sie diese Zusage auf — und bekommen genau die Versionskonflikte zurück, die Sie beim Application Server loswerden wollten.

3:37 Der dritte Punkt ist eine Warnung, die in Migrationsprojekten wichtig ist: Reaktiver Code wird eingeführt, obwohl das Problem blockierender Zugriff war. Quarkus unterstützt beide Modelle, und die Verlockung ist groß, beim Umbau gleich alles reaktiv zu machen. Aber das ist ein zweiter, eigener Umbau mit eigenen Fehlerbildern — und er verhindert den sauberen Vergleich mit dem Bestand. Übertragen Sie zuerst so nah am Original wie möglich.

4:02 Und Punkt vier ist der klassische Build-Fehler: Klassen, die zur Laufzeit dynamisch geladen werden, kennt der Build nicht — und was er nicht kennt, entfernt er.

Werkzeuge und Entwicklungsschleife

4:12 Kommen wir zu dem Teil, der im Migrationsalltag den größten unmittelbaren Unterschied macht: der Zeit zwischen einer Änderung und ihrer Wirkung. Denn beim Umbau fremden Codes probiert man ständig etwas aus. Die Länge dieser Schleife entscheidet darüber, wie oft man das tatsächlich tut. Erinnern Sie sich an die Kette aus Modul eins — bauen, ausrollen, testen, freigeben? Im Entwicklungsmodus schrumpft der vordere Teil davon auf nahezu null.

4:37 Quarkus übersetzt geänderte Dateien beim nächsten Aufruf neu, führt betroffene Tests fortlaufend aus und bietet unter der Dev-UI eine Oberfläche für Konfiguration, Erweiterungen und Zustände. Kein Deployment-Schritt, kein Serverneustart. Für ein Migrationsprojekt ist das mehr als Bequemlichkeit: Wenn ein Versuch zehn Sekunden statt zehn Minuten kostet, probiert man Dinge aus, statt sie zu diskutieren.

5:02 Die Logik dieser Tabelle: vier Werkzeuge, die alle dasselbe Ziel verfolgen — die Rückmeldung verkürzen. Am interessantesten für Migrationen ist die letzte Zeile, die Dev Services. Sie starten fehlende Infrastruktur automatisch als Container: eine Datenbank, einen Broker, einen Identity Provider. Damit entfällt die Frage, wer die Testdatenbank pflegt und wer ihre Zugangsdaten kennt.

5:25 Und beachten Sie die Fußzeile, denn dort steckt der Mechanismus: Dev Services starten nur, solange die zugehörige Konfiguration fehlt. Sobald Sie eine Datenbank-URL setzen, treten sie zurück. Das ist elegant — und es ist gelegentlich verwirrend, wenn man es nicht weiß. Der zweite Punkt ist der, den ich hervorheben möchte: Fortlaufende Tests zeigen Regressionen im Moment ihrer Entstehung.

5:49 Bei einer Migration ist das besonders wertvoll, weil Sie die ganze Zeit an fremdem Code arbeiten, dessen Sonderfälle Sie nicht kennen. Wenn ein Test drei Sekunden nach Ihrer Änderung rot wird, verbinden Sie beides sofort. Wenn er in der nächtlichen Pipeline rot wird, sitzen Sie am nächsten Morgen vor fünfzehn Änderungen und suchen.

6:08 Und Punkt vier ist unterschätzt: Die Dev-UI zeigt, welche Konfiguration wirklich greift — nicht welche in der Datei steht. Zwei Zeilen, und das Wesentliche steckt im Ergebnis: Der Standard ist das Fast-JAR-Layout, ein Ordner mit indizierten Abhängigkeiten und einer schlanken Start-Datei. Das ist kein einzelnes Archiv mehr, und genau das ist die häufigste Stolperfalle beim Bau von Images — man kopiert die Start-Datei und wundert sich, warum nichts läuft.

6:35 Der Ordner gehört vollständig ins Image. Ein Uber-JAR, also ein einzelnes Archiv mit allem darin, ist über eine Eigenschaft möglich, aber es startet langsamer. Für Container ist das Fast-JAR-Layout die bessere Wahl. Punkt zwei ist eine subtile Falle in Migrationsprojekten: Dev Services laufen unbemerkt weiter und verdecken eine fehlende Konfiguration.

6:56 Lokal läuft alles, weil ein Container im Hintergrund einspringt. In der Testumgebung fehlt die Datenbank-URL — und dort gibt es keinen Container, der einspringt. Prüfen Sie deshalb rechtzeitig gegen ein Profil mit vollständiger Konfiguration. Und Punkt drei ist die menschliche Falle: Fortlaufende Tests werden abgeschaltet, weil sie beim Umbau stören.

7:17 Verständlich, und trotzdem falsch — gerade beim Umbau sind sie die einzige unmittelbare Rückmeldung.

Reichweite und Grenzen

7:23 Jetzt der ehrlichste Teil dieses Moduls. Quarkus ist standardnah — aber es ist kein Application Server, und das sollten Sie wissen, bevor Sie planen. Wir gehen die Spezifikationen einzeln durch und halten fest, was unverändert trägt und was einen Ersatz braucht. Quarkus implementiert die Jakarta-EE-APIs, die für Dienste in Containern zählen: REST, CDI, Persistence, Transaktionen, Validierung, Security — ergänzt um MicroProfile.

7:50 Was darüber hinausgeht, fehlt bewusst. Das ist derselbe Gedanke wie beim provisionierten Server aus Modul fünf, nur konsequenter: Nicht alles mitbringen, was jemand brauchen könnte, sondern das, was dieser Anwendungstyp braucht. Für einen Dienst, der in einem Container läuft, ist das eine gute Entscheidung. Für eine Anwendung, die tief in Serverfunktionen verwoben ist, bedeutet es Umbauarbeit — und die will vorher bekannt sein.

8:18 Diese Tabelle ist die eigentliche Machbarkeitsanalyse — Zeile für Zeile geprüft, nicht als Gesamturteil. Die ersten vier Zeilen sind gute Nachrichten: REST, CDI, Persistence und Transaktionen gibt es, mit vertrauten APIs. Zwei Einschränkungen stehen aber schon dort: CDI ist nur in der Lite-Variante vollständig, und verteilte Transaktionen gibt es nicht.

8:39 Die letzte Zeile ist die wichtigste für Bestandsanwendungen: Für Enterprise Beans gibt es keinen Eins-zu-eins-Ersatz. Was eine Session Bean gleichzeitig konnte, wird auf mehrere Bausteine verteilt. Wie das aussieht, sehen wir in Modul neun im Detail. Vier Grenzen, und die erste trifft vor allem fremde Bibliotheken: CDI Portable Extensions gibt es nicht, weil die Bean-Ermittlung im Build passiert.

9:04 Wenn eine Bibliothek darauf baut, bleibt sie wirkungslos — und zwar still, ohne Fehlermeldung. Das ist die unangenehmste Sorte Problem. Der vierte Punkt ist der, der Architekturen betrifft: Verteilte Transaktionen über mehrere Ressourcen werden nicht unterstützt. Wenn Ihre Anwendung heute Datenbank und Nachrichtenwarteschlange in einer gemeinsamen Transaktion klammert, ist das kein Detail, sondern eine Entwurfsfrage — und sie gehört in die Pilotauswahl in Modul sieben.

9:32 Punkt zwei ist der Klassiker beim Umzug von Bestandscode: Unbenutzte Beans werden im Build entfernt, obwohl sie per Reflection gesucht werden. Der Build sieht keinen Injektionspunkt, also fällt die Bean weg — und zur Laufzeit findet der Reflection-Aufruf nichts. Punkt drei ist ein feiner, aber folgenreicher Unterschied: Singleton und ApplicationScoped werden gern gleichgesetzt, obwohl sie unterschiedlich erzeugt werden.

9:55 Und der letzte Punkt ist die Botschaft dieses Moduls: Migration wird geplant, bevor jemand die Grenzen tabellarisch geprüft hat. Genau das machen Sie jetzt in der Übung.

Übung

10:05 In der Übung geht es nicht darum, Quarkus zu bewundern, sondern zu prüfen, ob Zählwerk darauf laufen könnte — und wo nicht. Das Ergebnis ist eine Tabelle, in der die markierten Lücken mehr wert sind als alle grünen Zeilen zusammen. Sie stellen die im Inventar gefundenen Spezifikationen und Serverfunktionen den Möglichkeiten der neuen Laufzeit gegenüber.

10:25 Das Lernziel ist die Fähigkeit, eine Machbarkeit zu prüfen statt zu vermuten — und Lücken auszusprechen. Erfolgreich sind Sie, wenn jede Spezifikation aus Modul zwei eine Zeile mit Ersatz, Aufwand und offener Frage hat, und alles ohne Ersatz gesondert markiert ist. Diese Markierungen sind übrigens kein Scheitern, sondern das wertvollste Ergebnis der Übung: Sie sind die Risiken des Projekts, und sie entscheiden mit, welches Modul in Modul sieben zum Piloten wird.

10:52 Vier Schritte, und der rote Faden ist eine Übersetzung: von der Spezifikationsliste zur Erweiterungsliste. Schritt eins und zwei sind Handwerk — Projekt anlegen, Erweiterungen suchen. Schritt drei ist die Bewertung, und Schritt vier ist der, der Mut braucht: alles ohne Ersatz markieren und begründen. Die Versuchung ist groß, an dieser Stelle zu schreiben „lässt sich sicher lösen". Widerstehen Sie ihr.

11:15 Eine offen benannte Lücke lässt sich einplanen; eine zugedeckte Lücke taucht in Modul neun oder elf wieder auf, dann aber mitten in der Umsetzung. Punkt eins ist die häufigste Ungenauigkeit: Die Tabelle nennt Erweiterungen, prüft aber nie, ob sie das Verhalten wirklich abdecken. Es genügt nicht, dass es eine Messaging-Erweiterung gibt — die Frage ist, ob sie Ihre Zustellgarantie abbildet.

11:39 Punkt zwei ist die konkrete Ausprägung davon: Enterprise Beans gelten als gelöst, weil eine Annotation ersetzt wurde. Aber eine Session Bean war ein Bündel von Zusagen, und getauscht wurde nur eine davon. Und Punkt vier ist die Zusammenfassung: Der Entwicklungsmodus beeindruckt, die Machbarkeit bleibt trotzdem ungeprüft. Beides gehört zusammen.