Sieben Entscheidungskriterien

Spring Boot oder Quarkus

0:00 Die Frage klingt harmlos, und sie kostet Teams trotzdem regelmäßig Wochen: Soll der nächste Java-Dienst mit Spring Boot entstehen oder mit Quarkus? Lohnt sich die Migration einer bestehenden Anwendung? Oder kostet ein Wechsel am Ende mehr, als er einbringt? Wer im Netz danach sucht, findet vor allem Balkendiagramme mit Startzeiten — und die beantworten die Frage nicht.

0:21 In den nächsten Minuten bekommen Sie stattdessen sieben Kriterien an die Hand, mit denen sich eine konkrete Anwendung bewerten lässt. Am Ende steht keine Rangliste, sondern eine Entscheidung, die Sie im Architekturkreis begründen können.

Warum Pauschalantworten nicht tragen

0:34 Bevor wir zu den Kriterien kommen, lohnt ein kurzer Blick darauf, warum die üblichen Antworten so wenig taugen. Denn die meisten Vergleiche, die man findet, vergleichen nicht die Dinge, auf die es ankommt. Sehen wir uns zuerst an, was beide Plattformen längst gemeinsam haben — und wo die Unterschiede wirklich liegen. Stellen Sie sich vor, Sie kaufen ein Auto und lesen dazu einen Test, der nur die Höchstgeschwindigkeit misst.

0:59 Für die meisten Menschen ist das die uninteressanteste Zahl überhaupt — sie fahren zur Arbeit, laden Kinder ein und parken in engen Lücken. Genau so verhält es sich mit Framework-Benchmarks. Was dieses Modul liefert, ist deshalb kein Testsieger, sondern ein Entscheidungsprofil: sieben Kriterien, die Sie für Ihre Anwendung durchgehen, und am Ende eine Empfehlung, die zu genau dieser Anwendung passt.

1:21 Für die nächste kann sie anders ausfallen — und das ist kein Widerspruch, sondern der Sinn der Sache. Das ist der Punkt, an dem viele Diskussionen eigentlich schon enden könnten. Aktuelle Java-Versionen, Container, Kubernetes, Testcontainers: alles auf beiden Seiten vorhanden. Observability über Micrometer und OpenTelemetry: hier wie dort.

1:42 Und auch das Argument, das man am häufigsten hört — Native Images — trägt nicht mehr, denn die baut Spring Boot inzwischen ebenfalls. Wer also nach einem Unterschied in dieser Liste sucht, wird keinen finden. Das ist keine schlechte Nachricht, im Gegenteil: Es bedeutet, dass Sie sich um diese Themen bei der Entscheidung gar nicht kümmern müssen. Die Unterschiede liegen woanders.

2:05 Vier Ebenen, und sie sind bewusst von oben nach unten gestapelt, weil die obere jeweils die darunter beeinflusst. Ganz oben das Programmier- und Laufzeitmodell: Quarkus verlagert vieles in die Build-Phase, Spring Boot löst mehr zur Laufzeit auf. Darunter die Ökosysteme — Starter und Spring Cloud auf der einen Seite, Extensions und MicroProfile auf der anderen.

2:26 Dann die dynamischen Frameworkfunktionen, also alles, was sich beim Bauen prinzipiell nicht auflösen lässt. Und ganz unten der Migrationsumfang, der sich aus den drei Ebenen darüber ergibt. Wer nur die unterste Ebene schätzt, ohne die oberen zu kennen, schätzt ins Blaue. Diese Tabelle veraltet schneller als alles andere in diesem Modul — trotzdem steht sie hier, und zwar wegen der letzten Zeile.

2:50 Denn die beiden Projekte pflegen ihre Versionen unterschiedlich. Spring Boot kennt im offenen Teil gar keinen LTS-Begriff, dort laufen einfach mehrere Linien parallel weiter. Quarkus dagegen veröffentlicht alle sechs Monate eine LTS-Linie und pflegt sie zwölf Monate. Das heißt aber auch: Es gibt immer zwei davon, und eine ist immer kurz vor dem Ende.

3:11 Zum Stichtag dieses Moduls läuft der Support für die Linie 3.27 in zehn Tagen aus. Wer auf einer LTS plant, schaut vorher aufs Enddatum. Diese vier Sätze fallen in fast jeder Diskussion, und keiner davon entscheidet etwas. Dass Quarkus Native Images kann, war vor Jahren ein Alleinstellungsmerkmal — heute kann Spring Boot das auch.

3:31 Dass Quarkus schneller startet, stimmt oft sogar; die Frage ist nur, ob Ihre Anwendung überhaupt häufig genug startet, dass es zählt. Dass Spring Boot der Standard sei, beschreibt die Vergangenheit, nicht Ihre Anforderung. Und der Hello-World-Benchmark misst zuverlässig alles außer dem, was Ihre Anwendung tatsächlich tut. Diese Argumente sind nicht falsch — sie sind nur nicht entscheidungsrelevant.

Plattform, Laufzeit und Abhängigkeiten

3:56 Jetzt zu den Kriterien selbst. Die ersten drei betreffen Dinge, die Sie größtenteils schon haben und nicht frei wählen können: Ihre Organisation, das Lastprofil Ihrer Anwendung und den Code, der bereits da ist. Fangen wir mit dem an, was am wenigsten technisch klingt — und am häufigsten den Ausschlag gibt. Die erste Frage lautet ausdrücklich nicht, welches Framework schneller ist, sondern welche Plattform zu Ihrer Organisation passt.

4:21 Das klingt weich, ist aber das härteste Kriterium von allen. Wenn im Unternehmen seit Jahren eigene Spring-Boot-Starter gepflegt werden, in denen Mandantenlogik, Logging-Konventionen und Sicherheitsvorgaben stecken, dann ist das kein Detail — das ist Infrastruktur, die jemand neu bauen müsste. Umgekehrt gilt dasselbe: Wenn das Plattformteam Quarkus bereits betreibt und Erfahrung damit hat, schlägt das manches technische Argument. Fragen Sie also zuerst, was schon da ist.

4:48 Die Gegenüberstellung ist bewusst nicht symmetrisch gemeint — Sie sollen nicht Zeilen zählen, sondern prüfen, welche Aussagen auf Sie zutreffen. Links stehen Anzeichen dafür, dass ein Wechsel teuer würde: eigene Starter, tief verankertes Spring Cloud, viel Erfahrung in Entwicklung und Betrieb. Rechts stehen Anzeichen dafür, dass Quarkus ohnehin schon Teil des Weges ist. Interessant wird es, wenn auf beiden Seiten etwas zutrifft.

5:13 Das ist kein Patt, sondern ein deutlicher Hinweis: Dann ist Quarkus womöglich richtig für neue Dienste und falsch für den Bestand. Beim zweiten Kriterium geht es um das, was in den Benchmarks eigentlich gemeint ist — aber jetzt an Ihrer Anwendung. Startet der Dienst einmal am Tag oder vierzigmal in der Stunde? Läuft er dauerhaft oder nur, wenn etwas anliegt? Wie viele Instanzen laufen parallel, und welche Speichergrenzen setzt Ihnen die Plattform?

5:39 Und dann die Frage, die am meisten klärt: Wo liegt eigentlich der Flaschenhals? Wenn Ihre Anwendung die meiste Zeit auf die Datenbank wartet, wird ein schnelleres Framework daran wenig ändern. Vier Felder, und drei davon sind Entwarnung. Oben links der Fall, in dem sich kurze Startzeiten unmittelbar auszahlen: viele kurzlebige Instanzen, die ständig kommen und gehen.

6:02 Daneben der häufigste Fall im Unternehmensalltag — ein Dienst, der dauerhaft läuft und moderat ausgelastet ist. Dort merken Sie von den Startzeiten schlicht nichts. Stark schwankende Last macht Scale-out-Geschwindigkeit zum Kostenfaktor, das ist ein echtes Argument. Und im vierten Feld liegt die Grenze gar nicht im Framework, sondern dahinter.

6:22 Suchen Sie also zuerst Ihr Feld, bevor Sie messen. Das dritte Kriterium ist das, bei dem Schätzungen am häufigsten daneben liegen. Eine Anwendung mit REST-Endpunkten, Dependency Injection und JPA lässt sich recht geradlinig übertragen — das sind Konzepte, für die es auf beiden Seiten eine Entsprechung gibt. Schwierig wird es dort, wo Spring seine eigene Infrastruktur ins Spiel bringt: Auto-Configuration, eigene Starter, direkter Zugriff auf den Application Context, BeanPostProcessor, dynamisch registrierte Beans.

6:53 Und der unangenehmste Punkt steht ganz unten: Auch eine Fremdbibliothek kann einen Application Context voraussetzen, ohne dass das irgendwo in Ihrem Code sichtbar wäre. Der Befehl selbst ist unspektakulär — interessant ist, was er verspricht und was nicht. Quarkus bietet eine ganze Reihe solcher Kompatibilitätsextensions an: für Spring Web, Spring DI, Spring Data JPA, dazu Spring Data REST, Spring Security, Spring Cache, Spring Boot Properties und Spring Cloud Config.

7:22 Sie erlauben, dass Sie vertraute Spring-Annotationen weiterverwenden, während darunter die Quarkus-Laufzeit arbeitet. Für eine schrittweise Migration ist das ein echter Gewinn: Sie müssen nicht alles auf einmal anfassen. Nur führt der Name leicht in die Irre — was genau hier passiert, zeigt die nächste Folie. Das ist der Satz, an dem die meisten Missverständnisse hängen, und er steht so in der Quarkus-Dokumentation: Es wird kein Spring Application Context gestartet, und es läuft keine einzige Spring-Infrastrukturklasse.

7:54 Die Spring-Klassen werden lediglich gelesen, um Metadaten auszuwerten. Anders gesagt: Quarkus versteht Ihre Annotationen, aber es führt Spring nicht aus. Ein Bild dafür — jemand liest Ihre Notizen und arbeitet danach, aber er benutzt nicht Ihre Werkzeuge. Alles, was Spring zur Laufzeit tut, tut hier eben Quarkus, auf seine Weise.

8:14 Und genau daraus entstehen die Lücken. Diese Liste sollten Sie nicht auswendig lernen, aber Sie sollten wissen, dass es sie gibt — und nach welchem Muster sie entsteht. Schauen Sie auf die dritte Zeile: Die Bedingungs-Annotation wird ignoriert, weil Dependency Injection schon beim Bauen aufgelöst wird. Dasselbe gilt für Klassenpfad-Scans.

8:34 Das ist kein Versäumnis, sondern die logische Folge des Build-Zeit-Modells von vorhin. Auf der Persistenzseite trifft es unter anderem QueryDSL und die native Query in der Query-Annotation. Besonders unangenehm ist die sechste Zeile: QueryByExample scheitert nicht beim Bauen, sondern erst zur Laufzeit. Der erste Punkt ist der teuerste Irrtum in diesem ganzen Modul: Spring-Kompatibilität ist nicht dasselbe wie Spring-Unterstützung.

8:59 Wer das gleichsetzt, plant eine Migration, die auf dem Papier zwei Wochen dauert und in Wahrheit an einer einzigen Repository-Funktion hängenbleibt. Genauso häufig: Die Analyse wird gründlich für den eigenen Code gemacht und hört an der Grenze zu den Abhängigkeiten auf. Dabei sitzen dort die Überraschungen. Nehmen Sie sich die Zeit für die Abhängigkeitsanalyse — sie ist vor jeder Migrationsentscheidung Pflicht, nicht Kür.

Entwicklung, Betrieb und Migration

9:24 Die ersten drei Kriterien haben Ihren Bestand vermessen. Die nächsten vier schauen nach vorn: auf den Arbeitsalltag Ihres Teams, auf die Betriebsvarianten, auf Monitoring und Sicherheit — und schließlich auf den Weg, der zwischen heute und dem Zielzustand liegt. Diese Tabelle liest man am besten nicht Zeile für Zeile, sondern als eine einzige Aussage: Für fast alles, was Sie aus Spring Boot kennen, gibt es auf der Quarkus-Seite eine Entsprechung.

9:49 Die Namen sind anders, das Prinzip ist oft dasselbe. Bemerkenswert ist die vorletzte Zeile. Dev Services starten die Infrastruktur, die Ihre Anwendung braucht — Datenbank, Kafka, einen Identity Provider —, ganz von selbst, sobald die passende Extension im Projekt liegt. Und sie treten ebenso selbstverständlich zurück, sobald Sie eine Verbindungsadresse konfigurieren.

10:11 Das ist gut gedacht, weil es in der Entwicklung hilft und in der Produktion nicht im Weg steht. Hier ist die Versuchung groß, sich von einer gut gemachten Demo überzeugen zu lassen. Nur arbeitet Ihr Team nicht in Demos. Was zählt, ist der ganze Ablauf: Wie lange dauert es lokal, bis Sie nach einer Änderung ein Ergebnis sehen? Wie verständlich ist die Konfiguration, wenn etwas nicht funktioniert?

10:35 Wie lange läuft die Testsuite, wie lange die CI-Strecke? Und die Frage, die am ehrlichsten antwortet: Wie lange braucht ein neues Teammitglied bis zum ersten zusammengeführten Beitrag? Diese Zahl kennt Ihr Team — sie steht in keinem Benchmark. „Native oder nicht" ist keine Frage mit zwei Antworten, sondern eine mit mindestens vieren. Es gibt die klassische JVM-Anwendung.

10:58 Es gibt den optimierten JVM-Container, der oft schon viel bringt und kaum etwas kostet. Es gibt die AOT-optimierte Variante, bei der ein Teil der Arbeit beim Bauen erledigt wird. Es gibt das vollständige Native Image. Und es gibt inzwischen Checkpoint and Restore auf der JVM, das einen dritten Weg zu schnellen Starts eröffnet.

11:18 Vergleichen Sie die Varianten, die für Sie überhaupt in Frage kommen — nicht die beiden Extreme. Zwei Spalten, und die rechte wird regelmäßig vergessen. Links stehen die Werte, die man erwartet: Startzeit, Speicher, Durchsatz, Latenz. Dazu ein Wert, der selten gemessen wird und oft wichtiger ist als die Startzeit selbst — die Zeit bis zur vollen Betriebsbereitschaft.

11:41 Rechts steht, was der Weg dorthin kostet: Build-Zeit, Ressourcen des Builds, Containergröße. Ein Native-Build, der auf dem Entwicklerrechner zwanzig Minuten braucht, verändert den Arbeitsalltag spürbar. Und ganz unten der Punkt, der sich erst im Störfall zeigt: Wie gut lässt sich das Ergebnis noch debuggen und überwachen?

12:01 Auch hier gilt, was für das ganze Modul gilt: Der Vergleich zeigt keine Lücke, sondern zwei Wege zum selben Ziel. Spring Boot bündelt Metriken und Traces unter Micrometer Observation und stellt über Actuator die Endpunkte bereit, mit denen der Betrieb arbeitet. Quarkus setzt auf Extensions und empfiehlt OTLP als einheitlichen Transportweg für alle Telemetriedaten.

12:23 Beide lassen sich lokal erproben — Quarkus sogar mit einer kompletten Grafana-Umgebung, die als Dev Service hochfährt. Technisch ist das also beides sauber gelöst. Die eigentliche Frage ist eine andere. Ob ein Framework Observability unterstützt, ist im Jahr 2026 keine Frage mehr — beide tun es. Die Frage ist, ob das, was Sie bereits betreiben, weiterläuft.

12:46 Bleiben Ihre Dashboards gültig, oder heißen die Metriken plötzlich anders? Greifen Ihre Alarme noch? Passen die Logformate zusammen, sodass Korrelation über Dienstgrenzen hinweg funktioniert? Lassen sich Ihre OAuth- und OpenID-Connect-Konfigurationen übertragen? Ein Frameworkwechsel ist eben nicht nur eine Sache des Quellcodes — er berührt Betriebsprozesse, die über Jahre gewachsen sind.

13:10 Rechnen Sie diesen Aufwand mit ein, sonst taucht er später auf. Das letzte Kriterium ist das, an dem Migrationen scheitern, obwohl der Zielzustand gut gewesen wäre. Entscheidend ist nämlich nicht, wie die Anwendung hinterher aussieht, sondern was der Weg dorthin kostet — an Codeänderungen, an Ersatz für nicht unterstützte Komponenten, an Tests und Testinfrastruktur.

13:32 Dazu kommen neue Betriebsprozesse, die Qualifizierung des Teams, womöglich Parallelbetrieb und eine Rückfallstrategie. Und dagegen rechnen Sie: die erwartete Ersparnis, die verbleibende Lebensdauer der Anwendung und ihre strategische Bedeutung. Für eine Anwendung, die in zwei Jahren abgelöst wird, fällt die Rechnung fast immer eindeutig aus.

13:52 Die Kette zeigt zwei Wege, die nebeneinanderliegen und nicht gegeneinander. Am Anfang steht immer die Analyse des Bestands — ohne sie ist alles Weitere geraten. Dann können Sie über die Kompatibilitätsextensions gehen, also zunächst nah am vertrauten Spring-Code bleiben. Oder Sie gehen direkt auf die Quarkus-eigenen APIs.

14:12 Die Dokumentation empfiehlt ausdrücklich, beides zu mischen: erst kompatibilitätsorientiert migrieren, um schnell lauffähig zu sein, und die Teile, die es lohnen, später auf native APIs umstellen. Der Pfeil bedeutet also nicht „entweder oder", sondern „nacheinander". Zum Schluss dieses Kapitels eine Zahl, die man kennen sollte.

14:33 Es gibt seit diesem Jahr einen Forschungsbenchmark namens ScarfBench, der genau diese Aufgabe untersucht: 204 Migrationsaufgaben zwischen Spring, Jakarta EE und Quarkus. Bewertet wird dabei nicht, ob der erzeugte Code kompiliert — bewertet wird, ob sich die Anwendung hinterher noch genauso verhält, geprüft gegen über dreizehnhundert Tests.

14:52 Und das Ergebnis ist ernüchternd: Selbst die stärksten Agenten bleiben unter zehn Prozent. Werkzeuge nehmen Ihnen die Fleißarbeit ab, und das ist viel wert. Die Architekturentscheidung und die Verhaltenstests nehmen sie Ihnen nicht ab.

Entscheidungsmatrix und typische Ergebnisse

15:07 Sie haben jetzt sieben Kriterien beisammen. Bleibt die Frage, wie daraus eine Entscheidung wird — und da gibt es eine Regel, die man kennen muss, weil sie der ersten Intuition widerspricht. Der wichtigste Schritt ist der erste, und er wird fast immer übersprungen: Stufen Sie die Kriterien ein, bevor Sie irgendetwas ankreuzen.

15:26 Was ist ein Muss, was wichtig, was nur wünschenswert? Wenn Sie das hinterher tun, richten Sie die Gewichtung unbewusst am Ergebnis aus, das Sie ohnehin wollten. Danach gehen Sie die Kriterien durch, kreuzen an und markieren die Stellen, an denen Sie nur vermuten statt zu wissen — diese Markierungen werden gleich noch wichtig.

15:44 Und am Ende schreiben Sie keine Punktzahl auf, sondern eine Empfehlung mit Begründung. Das ist das Arbeitsblatt, und es ist bewusst schlicht gehalten: sieben Zeilen, drei Spalten, Kästchen zum Ankreuzen. Nehmen Sie es mit in die Runde und füllen Sie es gemeinsam aus — Architektur, Entwicklung und Betrieb zusammen, nicht nacheinander.

16:04 Der Wert dieser Matrix liegt nämlich weniger im Ergebnis als im Gespräch, das beim Ausfüllen entsteht. Erfahrungsgemäß ist genau dort der Moment, in dem jemand sagt: „Moment, das mit den eigenen Startern stimmt so nicht mehr." Solche Sätze sind mehr wert als jede Messung. In der Praxis landen die meisten Bewertungen in einem dieser vier Felder.

16:25 Spring Boot behalten ist dabei ein vollwertiges Ergebnis und kein Scheitern — wenn die Anwendung tief im Ökosystem verankert ist und kein belastbarer Betriebsvorteil in Sicht, ist Bleiben die richtige Entscheidung. Quarkus für Neues ist der risikoärmste Einstieg überhaupt: ein abgegrenzter neuer Dienst ohne komplexe Spring-Abhängigkeiten.

16:43 Schrittweise migrieren setzt gute Modularisierung und tragfähige Tests voraus. Und wenn sich die Kriterien widersprechen, ist „erst messen" nicht Unentschlossenheit, sondern die sparsamste Antwort. Falls Sie im vierten Feld gelandet sind, hier die Bedingungen, unter denen ein Vergleichsprojekt überhaupt etwas beweist. Dieselbe Fachfunktion, dieselbe Datenbank, identische Schnittstellen, vergleichbare Containergrenzen, dieselben Lastprofile.

17:09 Sobald eine dieser Größen abweicht, messen Sie den Unterschied und nicht das Framework. Zwei Dinge gehören außerdem vor den Start: eine Kennzahl, die über Erfolg oder Misserfolg entscheidet, und ein Abbruchkriterium. Beides danach festzulegen ist menschlich verständlich und macht das Ergebnis wertlos. Der erste Punkt ist der wichtigste, deshalb noch einmal deutlich: Zählen Sie keine Kreuze.

17:32 Vier kleine Vorteile auf der einen Seite wiegen ein verletztes Muss-Kriterium auf der anderen nicht auf — wenn eine Bibliothek, ohne die die Anwendung nicht läuft, auf der Zielplattform nicht funktioniert, ist die Entscheidung gefallen, egal wie der Rest aussieht. Ebenso heikel: die Matrix auszufüllen, ohne den eigenen Bestand analysiert zu haben. Dann bewerten Sie Annahmen.

17:53 Und füllen Sie sie nicht allein im Architekturkreis aus — Betrieb und Entwicklung sehen andere Dinge.

Übung

17:59 Bleibt der Teil, der die sieben Kriterien von einer Liste zu einem Werkzeug macht: Wenden Sie sie an. Am besten auf einen Dienst, den Sie wirklich kennen — und wenn Sie gerade keinen zur Hand haben, stellen wir Ihnen einen. Tarifwerk ist ein erfundener Dienst, aber ein realistischer. Er berechnet Preisstaffeln für Energieverträge, läuft auf Spring Boot mit einer REST-Schnittstelle und PostgreSQL, und er bringt genau die Eigenschaften mit, die eine Entscheidung interessant machen.

18:27 Da ist ein eigener Firmen-Starter für Mandantenkennungen — der berührt Kriterium 1 und Kriterium 3 gleichzeitig. Und da sind rund vierzig Instanzen zur Lastspitze, was Kriterium 2 auf einmal relevant macht. Sie werden merken: Schon bei diesem kleinen Beispiel widersprechen sich die Kriterien. Genau darum geht es. Die Aufgabe klingt nach Schreibarbeit, und sie ist es auch — das ist Absicht.

18:50 Denn eine Entscheidung, die man aufschreiben muss, hält anderen Argumenten stand; eine, die man nur im Kopf hat, kippt beim nächsten Blogbeitrag über Startzeiten. Sie gehen alle sieben Kriterien durch und halten zu jedem fünf Angaben fest. Fertig sind Sie nicht, wenn Ihnen das Ergebnis gefällt, sondern wenn zu jedem Kriterium alle fünf Angaben dastehen.

19:11 Nehmen Sie sich dafür Zeit; im Live-Modul dauert genau dieser Teil rund vierzig Minuten. Die fünf Fragen bauen aufeinander auf. Die ersten beiden beschreiben, wo Sie stehen und wo Sie hinwollen. Die dritte ist die entscheidende: Welche Annahme müsste eigentlich erst ein Test belegen? Dort wird sichtbar, wie viel von Ihrer Einschätzung auf Wissen beruht und wie viel auf Gefühl.

19:33 Die vierte zwingt Sie zu einer Kennzahl statt zu einem Adjektiv — nicht „schneller", sondern „unter zweihundert Millisekunden". Und die fünfte fragt nach dem Ausschlusskriterium, also nach dem einen Fund, der die ganze Diskussion beenden würde. Zusammen ergibt das Ihren Prüfauftrag.

Und jetzt?

19:50 Fassen wir zusammen: Was am Ende dieses Moduls steht, ist ein Entscheidungsprofil für eine bestimmte Anwendung — keine Rangliste, die für alle gilt. Für den nächsten Dienst gehen Sie die sieben Kriterien noch einmal durch, und das Ergebnis darf anders ausfallen. Wenn Ihre Bewertung Richtung Quarkus zeigt, schließt das dreitägige Seminar „Quarkus für Spring-Boot-Teams" genau hier an und führt die Migration praktisch durch.

20:13 Besonders lohnt sich das, wenn Architektur, Entwicklung und Betrieb bei der Bewertung unterschiedlicher Meinung waren — denn dann fehlt nicht die Entscheidung, sondern die gemeinsame Grundlage dafür.