Quarkus Native, JVM Mode und Startup-Strategien
Quarkus im JVM- und Native-Modus, Build-Time-Metadaten, Container-Images und Betriebsentscheidungen.
JVM Mode vs Native
JVM Mode ist oft die beste Wahl für Entwicklung, Debugging und maximale Kompatibilität. Native Mode kann bei Startup und Footprint helfen, verlangt aber konsequente Tests mit echten Extensions.
Build-Time Ansatz
Quarkus verschiebt viel Arbeit in die Build-Zeit. Das ist stark für Container, aber man muss verstehen, welche Reflection, Proxies und Ressourcen im Native Image verfügbar sind.
Betriebsentscheidung
| Kriterium | JVM Mode | Native Mode |
|---|---|---|
| Startzeit | gut | sehr gut |
| Memory Footprint | mittel | oft niedriger |
| Debugging | sehr vertraut | spezifischer |
| Kompatibilität | breiter | prüfen |
| CI-Zeit | kürzer | länger |
Praxisübertragung auf das V4-Beispielprojekt
Entscheidung
Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.
Code-Nachweis
Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.
Betrieb
Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.
Typische Fehlerbilder
- Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
- Technische Wiederholung wird nicht idempotent gemacht.
- Observability wird erst nach Produktionsproblem ergänzt.
- Tests prüfen nur Happy Path und keine Wiederanläufe.