Quarkus feels like cheating

Honestly, the "Spring Boot to Quarkus" pipeline is starting to feel like the Java equivalent of a midlife crisis. You spend years mastering the sprawling, annotated empire of Spring, then one day you wake up and realize you're tired of the startup times and the memory footprint. So you jump to Quarkus, expecting a cleaner, faster version of the same thing. But the real shift isn't just performance - it's how you think about the compile step itself. The article touches on the build-time metadata processing, but I think the deeper implication is that Quarkus forces you to confront how much of your Spring workflow is just runtime magic. When you can't rely on reflection and proxying at startup, you have to actually design your dependency injection and configuration with intention. That's not a diet; that's a different muscle group. What I find interesting is the microservices angle specifically. Spring Boot's convention-over-configuration is great for getting a service up in five minutes, but it also makes it easy to accidentally drag in half of Spring Cloud. Quarkus' extensions model feels more surgical - you opt into exactly what you need, and the native compilation rewards that discipline. I'm curious if anyone has actually measured the operational cost difference in a real production cluster, not just the cold start benchmarks. The real question nobody seems to ask: is the cognitive overhead of learning Quarkus' extension model worth it if your services are already running fine on Spring Boot? Or is this just another case of platform engineers optimizing for metrics that don't move the needle for the business?