Warum Quarkus für Spring-Boot-Teams

Warum Quarkus für Spring-Boot-Teams

0:00 Willkommen. Drei Tage lang geht es um Quarkus — und zwar aus einer ganz bestimmten Perspektive: der von Menschen, die Spring Boot können. Das ist ein Vorteil, denn die Konzepte sind dieselben. Dependency Injection, REST-Endpunkte, Repositories, Transaktionen, Tests — all das gibt es hier wie dort. Und genau darin liegt die Falle: Hinter den vertrauten Begriffen steht ein anderes Laufzeitmodell.

0:24 Wir beginnen deshalb nicht mit dem ersten Projekt, sondern mit der unbequemsten Frage überhaupt: Lohnt sich der Wechsel für Ihre Anwendung? Wer diese Frage sauber beantworten kann, trifft am Ende eine Entscheidung statt einer Geschmacksfrage.

Warum Quarkus für Spring-Boot-Teams

0:39 Der erste Tag legt das Fundament. Wir klären, wofür Quarkus gebaut ist, wie sich sein Architekturmodell von Spring Boot unterscheidet und wie ein Projekt entsteht. Danach übertragen wir die Bausteine, die Sie täglich benutzen: Dependency Injection, REST und Konfiguration. Dieses erste Modul bleibt bewusst noch ohne Code — es geht um die Frage, ob und wofür sich der ganze Aufwand überhaupt rechnet.

Einsatzszenarien und Migrationsanlässe

1:03 Beginnen wir bei den Szenarien. Quarkus wurde für einen bestimmten Betriebsfall entworfen, und je näher Ihre Anwendung diesem Fall kommt, desto größer der Gewinn. Je weiter sie davon entfernt ist, desto schneller schrumpft er auf null. Stellen Sie sich zwei Arten von Restaurants vor. Das eine öffnet morgens und hat bis Mitternacht durchgehend Betrieb — dort spielt es keine Rolle, wie lange das Anheizen dauert.

1:27 Das andere öffnet immer nur für zwanzig Minuten, wenn ein Bus hält, und schließt danach wieder. Dort entscheidet die Anheizzeit über alles. Quarkus ist für den zweiten Fall gebaut: für Anwendungen, die häufig starten, auf null skalieren und in großer Zahl nebeneinander im Cluster laufen. Das ist ein echter Vorteil — aber eben nur dann, wenn Ihre Anwendung tatsächlich so betrieben wird.

1:50 Vier Fragen entscheiden, ob der Unterschied bei Ihnen überhaupt ankommt. Wie oft startet der Dienst wirklich? Wie viele Instanzen laufen gleichzeitig? Rechnet die Plattform nach Laufzeit ab? Und wächst die Zahl der Dienste weiter? Bei vielen kleinen Diensten wird jedes eingesparte Megabyte pro Pod zu einer Zahl auf der Rechnung — bei drei langlebigen Instanzen merken Sie davon nichts.

2:13 Das ist keine Kritik an Quarkus, sondern eine Frage des Einsatzortes. Ein Sportwagen ist im Stadtverkehr auch nicht schneller als ein Kleinwagen. Diese Gegenüberstellung ist wichtiger, als sie aussieht, denn sie trennt zwei völlig verschiedene Entscheidungen. Links steht ein neuer Dienst: Sie wählen frei, das Risiko bleibt im Projekt, und ein Irrtum kostet Lernzeit.

2:35 Rechts steht eine gewachsene Anwendung: Jede Spring-Abhängigkeit will geprüft, jeder Umbau nachgewiesen werden, und das Risiko trifft den Produktivbetrieb. Wer diese beiden Fälle vermischt, überträgt die Leichtigkeit des ersten Falls auf den zweiten — und wundert sich später über den Aufwand. Für den rechten Fall gilt deshalb: Der Rückweg gehört von Anfang an in den Plan.

2:57 Die typischen Fehler entstehen alle aus derselben Bequemlichkeit. Man nimmt den kleinsten Dienst als Piloten, weil er schnell fertig ist — nur beweist der kleinste Dienst nichts über die Anwendung, um die es eigentlich geht. Man verkauft die Migration als Modernisierung, obwohl der eigentliche Engpass in der Datenbank sitzt und dort auch bleibt.

3:16 Die Entscheidung fällt im Prototyp, wo alles leicht geht, und wird nie wieder geprüft. Und der Betrieb, der die Pods später betreuen muss, erfährt vom Wechsel erst, wenn das Image plötzlich anders aussieht. Sprechen Sie früh mit denen, die Ihre Anwendung nachts betreuen.

Startzeit, Speicher und Produktivität

3:32 Kommen wir zu den Zahlen, die in jeder Präsentation über Quarkus auftauchen: Startzeit und Speicherbedarf. Beide sind real. Interessanter ist aber ein dritter Punkt, über den seltener gesprochen wird — die tägliche Arbeitsgeschwindigkeit im Projekt. Der Kern ist eine Verschiebung in der Zeit. Spring Boot erledigt beim Start eine Menge Arbeit: Es durchsucht den Klassenpfad, wertet Bedingungen aus, baut den Application Context zusammen.

3:59 Quarkus erledigt genau diese Arbeit schon beim Bauen. Das Bild dazu: Sie können jeden Morgen entscheiden, was Sie anziehen — oder Sie legen es am Abend vorher raus. Am Morgen sind Sie dann schneller fertig. Bezahlt wird das mit einem längeren, strengeren Build. Nichts davon ist Magie, es ist eine Verlagerung — und man sollte wissen, wohin.

4:20 Der Dev Mode ist der Punkt, an dem Quarkus im Alltag am spürbarsten wird. Sie ändern eine Datei, speichern, rufen die Anwendung auf — und die Änderung ist da, ohne Neustart. Continuous Testing lässt die betroffenen Tests nebenher mitlaufen und meldet sich nur, wenn etwas bricht. Die Dev UI beantwortet im Browser Fragen zur Konfiguration, für die man sonst im Code sucht. Und Dev Services starten Datenbank oder Broker von selbst.

4:46 Das klingt nach Komfort, ist aber vor allem eines: kürzere Rückmeldezeiten. Und die summieren sich über einen Arbeitstag deutlich stärker als ein paar Millisekunden Startzeit. Viel gibt es hier nicht zu erklären, und das ist die eigentliche Aussage: ein Befehl, und die Anwendung läuft im Entwicklungsmodus. Wichtig sind die drei Hinweise darunter.

5:07 Die Dev UI erreichen Sie im Browser unter dem q-Pfad — merken Sie sich diesen Pfad, alle Quarkus-Bordmittel liegen darunter. Der Debugger lauscht standardmäßig auf einem festen Port, Sie müssen also nichts konfigurieren, um sich anzuhängen. Und mit einem einzigen Tastendruck im Terminal schalten Sie das fortlaufende Testen ein. Probieren Sie das heute Nachmittag aus, bevor Sie über Startzeiten diskutieren.

5:31 Beim Vergleichen geht erstaunlich viel schief. Zwei Anwendungen werden gegeneinander gemessen, die gar nicht dasselbe tun — die eine mit Security und Messaging, die andere ohne. Gemessen wird auf dem Notebook, entschieden wird für den Cluster. Der längere Build fällt im Dev Mode gar nicht auf, dafür später in der Pipeline umso deutlicher.

5:50 Und Live Reload ist so bequem, dass leicht übersehen wird, wann eine Änderung eben doch einen echten Neustart oder sogar einen neuen Build braucht. Genau diesen Unterschied sehen wir uns in Modul sechs noch genauer an.

Entscheidungskriterien statt Framework-Glaube

6:03 Damit sind wir bei der Frage, um die es in diesem Modul eigentlich geht. Nicht: Ist Quarkus gut? Sondern: Woran erkennen Sie, ob sich der Wechsel für eine konkrete Anwendung lohnt — und wie begründen Sie das gegenüber Menschen, die das Geld freigeben? Eine Migration ist eine Investitionsentscheidung, auch wenn sie sich wie eine technische anfühlt.

6:24 Und Investitionsentscheidungen haben immer dieselben drei Bestandteile: einen bezifferten Nutzen, einen geschätzten Aufwand und ein Abbruchkriterium. Der Satz „die Zielplattform ist moderner" erfüllt keinen dieser drei Punkte. Das Unangenehme daran: Den Nutzen müssen Sie messen, den Aufwand schätzen — und das Abbruchkriterium formulieren, bevor Sie anfangen.

6:45 Danach ist es keines mehr, sondern nur noch ein Eingeständnis. Und formulieren Sie das Abbruchkriterium so, dass es jemand anderes überprüfen kann. Ein Kriterium, das nur Sie beurteilen können, ist im Zweifel keines. Lesen Sie die Tabelle nicht als Punktestand, sondern als zwei Prüflisten. Links stehen Bedingungen, unter denen der Wechsel etwas einbringt — meist hat das mit Skalierung, Startverhalten oder einer bereits getroffenen Plattformentscheidung zu tun.

7:13 Rechts stehen Bedingungen, unter denen er teuer wird, ohne etwas zu liefern. Entscheidend ist die Fußnote: Spring Boot hat inzwischen selbst AOT, Native Images und Testcontainers. Wer die Migration mit allgemeinen Cloud-Native-Argumenten begründet, begründet sie also gar nicht. Die Begründung muss aus Ihrer Anwendung kommen, nicht aus einer Featureliste.

7:34 Diese fünf Schritte haben eine gemeinsame Logik: Alles Wichtige wird festgelegt, bevor gemessen wird. Zuerst der Nutzen — was genau geht ohne Migration nicht? Dann die Messgrößen, und zwar schriftlich, denn hinterher findet man immer eine Zahl, die zur Wunschentscheidung passt. Der Pilot soll repräsentativ sein, nicht bequem.

7:54 Aufwand und Rückweg gehören beziffert, weil ein Projekt ohne Rückweg keine Entscheidung mehr kennt, sondern nur noch Fortsetzung. Und das Abbruchkriterium schreiben Sie auf, solange es niemandem wehtut. Hier sammeln sich die Muster, die man in Migrationsprojekten immer wieder sieht. Der Nutzen wird in Millisekunden gemessen, die Kosten in Personenmonaten verschwiegen.

8:16 Ein Prototyp ohne Security, ohne Messaging und ohne Last gilt als Machbarkeitsnachweis — dabei steckt genau dort die Arbeit. Entschieden wird, bevor überhaupt jemand die Abhängigkeiten inventarisiert hat. Und der verräterischste Punkt zum Schluss: Wenn es kein denkbares Szenario gibt, in dem das Ergebnis gegen die Migration ausfällt, dann war es nie eine Prüfung, sondern immer schon eine Ankündigung.

Übung

8:39 Zeit für die Praxis. Wir lernen jetzt die Anwendung kennen, die uns durch alle achtzehn Module begleitet — und nehmen als Erstes ihren Ausgangszustand auf. Unser Beispiel heißt Pfandkreis: ein Mehrweg-Pfandsystem für Gastronomiebetriebe mit Becherausgabe, Rücknahmestellen und monatlicher Abrechnung. Technisch ein ganz gewöhnlicher Spring-Boot-Dienst mit PostgreSQL, Kafka und Keycloak — also genau die Mischung, die in der Praxis überall steht.

9:06 Ihre Aufgabe ist keine Programmieraufgabe, sondern eine Urteilsaufgabe: Legen Sie drei Kennzahlen fest, die eine Migrationsentscheidung wirklich tragen würden, und halten Sie fest, unter welchen Bedingungen sie erhoben werden. Diese Bedingungen sind der unscheinbare, aber entscheidende Teil. Die vier Schritte führen von den Fakten zur Bewertung. Erst das Lastprofil: Wie oft startet der Dienst, wie viele Instanzen laufen?

9:31 Diese Zahlen stehen meist längst in Ihrer Monitoring-Oberfläche — holen Sie sie dort, statt zu schätzen. Dann die Spring-Bausteine jenseits von Web, DI und Data, denn dort verstecken sich später die Blocker. Dann die drei Kennzahlen. Und zum Schluss, ausdrücklich, mindestens zwei Argumente dagegen. Wer keine findet, hat noch nicht lange genug hingesehen.

9:53 Achten Sie bei dieser Übung besonders auf zwei Punkte. Erstens: Es wird fast immer das gemessen, was leicht zu messen ist — die Startzeit — und nicht das, was zählt, etwa der Speicherbedarf unter realer Last. Zweitens: Die Gegenargumente fallen unter den Tisch, weil die Entscheidung gefühlt schon feststeht. Genau die brauchen Sie aber später, wenn jemand kritisch nachfragt.

10:15 Und notieren Sie die Messbedingungen mit. In sechs Wochen erinnert sich niemand mehr daran, unter welcher Last diese Zahl entstanden ist — und dann ist sie wertlos.