Wer Microservices in Java baut, kennt das alte Vorurteil: langsamer Start, hoher Speicherverbrauch, schwergewichtige Application-Server. Quarkus räumt damit auf — und bleibt dabei überraschend nah an den Standards, die Java-Entwickler ohnehin kennen.
Startzeit in Millisekunden
Quarkus verlagert viel Arbeit in die Build-Zeit statt in die Laufzeit. Dependency Injection, Konfiguration, Proxy-Erzeugung — was klassische Frameworks beim Start erledigen, ist bei Quarkus schon vorberechnet. Das Ergebnis: Services, die in Millisekunden starten und sich in Containern natürlich skalieren lassen.
Standards statt Speziallösungen
Statt eigener APIs setzt Quarkus konsequent auf Bewährtes:
- Jakarta REST für REST-Endpunkte (früher JAX-RS)
- CDI/ArC für Dependency Injection
- Hibernate ORM mit Panache für den Datenzugriff
Wer diese Standards kennt, ist sofort produktiv. Und wer sie noch nicht kennt, lernt gleich das Richtige — kein Framework-Spezialwissen, das anderswo nutzlos ist.
Imperativ und reaktiv im selben Paket
Ein Detail, das oft überrascht: reaktive und imperative Programmierung liegen bei
Quarkus in derselben Extension — quarkus-rest. Du musst dich nicht von Anfang an
festlegen und kannst pro Endpunkt entscheiden, was besser passt. Nur der
Datenzugriff muss mitziehen: Reaktiv funktioniert nur durchgängig, ein einziger
blockierender Aufruf in der Kette kostet den gesamten Vorteil.
Die Infrastruktur startet mitgeliefert
Der Punkt, der im Alltag am meisten Zeit spart, steht in keiner Featureliste weit oben: Dev Services. Liegt eine Datenbank-Extension im Projekt und ist keine Verbindung konfiguriert, startet Quarkus die Datenbank beim Entwickeln selbst — im Container, im Hintergrund. Dasselbe gilt für Kafka, AMQP und RabbitMQ. Aus dem klassischen halben Onboarding-Tag wird ein Befehl, und alle im Team arbeiten gegen dieselbe Version.
Mehr dazu im Seminar
Wie das konkret aussieht — vom ersten @Path-Endpunkt bis zum reaktiven Messaging —
zeigt das Seminar Modul für Modul, auf dem Stand von Quarkus 3.33 LTS.