„Czemu jeszcze nie przepisaliśmy tego na Quarkusa?”
To pytanie padło na spotkaniu technologicznym, które miało być spokojnym podsumowaniem roadmapy. Zamiast tego rozpoczęło jedną z bardziej emocjonalnych dyskusji od czasu, gdy ktoś zaproponował wprowadzenie GraphQL.
Zacznijmy od początku.
Spring Boot – działa od 2014
Jeśli napisałeś w Javie więcej niż Hello World i nie używałeś nigdy Springa, to nie wiem, gdzie się uchowałeś. Ale nawet wtedy debugowałeś pewnie chociaż stack trace wygenerowany przez Spring Boota.
Ten framework nie próbuje być sexy. Nie próbuje być lean. Chcesz jedną małą rzecz, on wciąga do Twojej aplikacji setki kilobajtów kodu. Ale działa. I to w 99% przypadków wystarczy. Miliony blogpostów, tysiące przykładów na StackOverflow, setki rozszerzeń – to wszystko sprawia, że Spring jest jak stary wygodny fotel: trochę wytarty, trochę trzeszczy, ale wiesz, gdzie co jest.
Quarkus – działa w 0.04 sekundy
A potem pojawia się on – Quarkus. Młody, szybki, zgrabny. Wchodzi, robi swoje, znika. Czas startu w trybie natywnym? 0.04s. Spring może o tym tylko pomarzyć. RAM? Żre mniej niż przeglądarka z otwartym StackOverflow. Integracja z GraalVM? Wbudowana.
Brzmi jak marzenie. Prawda?
Ok, ale jak to wygląda w kodzie?
Weźmy przykład z życia wzięty: REST-owy endpoint zwracający zamówienia z bazy. Brzmi jak CRUD? Bo to CRUD.
Spring Boot
@RestController
@RequestMapping("/orders")
public class OrderController {
private final OrderRepository repository;
public OrderController(OrderRepository repository) {
this.repository = repository;
}
@GetMapping
public List<Order> getAll() {
return repository.findAll();
}
}public interface OrderRepository extends JpaRepository {}Odpalasz, działa. H2 w pamięci, logi śmigają, jak coś nie działa, to marudzi już przy starcie, więc nie przeoczysz tego.
Czas uruchomienia? ~1.5s.
Quarkus
@Path("/orders")
public class OrderResource {
@Inject
EntityManager em;
@GET
@Produces(MediaType.APPLICATION_JSON)
public List<Order> getAll() {
return em.createQuery("from Order", Order.class).getResultList();
}
}
Zero Spring Data. Zero magii. Wszystko jawnie. ORM działa, ale jesteś bliżej metalu. Trochę czujesz, że trochę wróciłeś do czasów Hibernate 3 i pisania SQL-a na kartce.
Czas uruchomienia? ~0.9s w JVM, ~0.04s w natywie. No robi wrażenie.
A co z testami?
W Springu wrzucasz @SpringBootTest i modlisz się, żeby test wstał przed kawą. Ale masz wszystko: kontekst, wstrzykiwanie, nawet MockMvc.
W Quarkusie masz @QuarkusTest. W teorii działa jak SpringBootTest. W praktyce… działa, ale czasem trzeba przeklikać dokumentację. I nie wszystko działa tak samo.
Środowiska enterprise
Jeśli pracujesz w dużej organizacji, gdzie proces release’u ma więcej kroków niż Twój test end-to-end, a każda nowa technologia wymaga pięciu podpisów, to Spring Boot jest bezpiecznym wyborem. Większość aplikacji w korporacjach i tak już działa na Springu. Migracja do Quarkusa w takim miejscu najczęściej kończy się na Proof of Concept – jeśli w ogóle ktoś pozwoli go napisać.
Spring Boot daje coś, co w enterprise ma ogromną wartość: przewidywalność.
Każdy nowy developer, konsultant, audytor czy architekt wie, czego się spodziewać. Spring Data, konfiguracja YAML, klasyczny podział warstw – standard, który skraca onboarding i minimalizuje ryzyko.
Framework dobrze integruje się z narzędziami klasy enterprise: monitoringiem (Actuator + Prometheus/Grafana), systemami logowania, brokerami wiadomości (Kafka, RabbitMQ), systemami autoryzacji (OAuth2, Keycloak), a także korporacyjnymi politykami bezpieczeństwa (czyt. braku internetu na build machine).
Czas startu aplikacji? W tym środowisku to nie problem – ważniejsze, że działa w sposób powtarzalny. Restart mikroserwisu trwa 2 sekundy dłużej? Nikt tego nawet nie zauważy, bo i tak jest za reverse proxy i load balancerem.
Startupy
W startupie liczy się czas. Czas wejścia na rynek, czas testowania hipotezy, czas dostarczenia działającego MVP. Framework ma pomóc, a nie przeszkadzać. I tu sprawa robi się ciekawsza.
Jeśli zespół zna Springa – to naturalny wybór. Dużo robi się samo: migracje schematów, walidacje, serializacja, dokumentacja (Springdoc/OpenAPI). Mało konfiguracji, dużo gotowych rozwiązań. Dobrze nadaje się do szybkiego prototypowania, o ile ktoś nie zacznie komplikować na siłę (patrz: custom autokonfiguracja w trzecim tygodniu sprintu).
Ale jeśli zespół ma doświadczenie z cloud-native, zna Dockera, Kubernetes, GraalVM – Quarkus staje się realną alternatywą. Mniejsze zużycie pamięci, krótszy czas uruchamiania, natywne buildy do deployowania na FaaS (np. AWS Lambda) – wszystko to może dać oszczędności w środowisku, gdzie skaluje się przez mnożenie kontenerów.
Oczywiście: brakuje „magii Springa”, więc część rzeczy trzeba napisać samemu. Ale startupy często i tak piszą własne rozwiązania – tylko szybciej. Tu Quarkus dobrze się wpasowuje: mniej domyślności, więcej jawności. Nie zawsze lepiej, ale bardziej świadomie.
Mikroserwisy
Jeśli myślisz o mikroserwisach jako o 30 kopiach tej samej aplikacji z innym endpointem – to Spring Boot wystarczy. Ale jeśli naprawdę projektujesz system rozproszony, z osobnymi cyklami życia serwisów, wysoką skalowalnością i optymalizacją zasobów – tu Quarkus zaczyna być realną opcją.
Czas startu i zużycie pamięci w Quarkusie to nie tylko ciekawostka z benchmarku – to konkretna oszczędność przy dużej liczbie instancji. W środowisku serverless (FaaS, autoscaling, KNative) różnice robią się zauważalne. Aplikacja, która startuje w 40 ms zamiast 1.5 s i zużywa 70 MB zamiast 200 MB? Na poziomie kilkuset kontenerów dziennie to są wymierne liczby.
Z drugiej strony: mikroserwisy to nie tylko runtime. To też: testy kontraktowe, logowanie skorelowane po traceId, health checki, obsługa błędów, retry, circuit breakers. Spring Boot ma to wszystko gotowe w Spring Cloud. W Quarkusie musisz to poskładać ręcznie – można, ale trzeba wiedzieć jak.
W skrócie:
- Spring Boot to dobry wybór do mikroserwisów klasy „REST + baza + monitoring”, szybko wdrażanych, łatwo rozwijanych.
- Quarkus warto rozważyć przy większej skali, automatycznym skalowaniu, FaaS lub bardzo wysokich wymaganiach dotyczących czasu reakcji i zużycia zasobów.
Co warto wiedzieć porównując oba rozwiązania?
| Kryterium | Spring Boot | Quarkus |
|---|---|---|
| Czas uruchamiania | Dość szybki | Błyskawiczny (natywny tryb robi robotę) |
| Dojrzałość ekosystemu | Absolutna dominacja | Jeszcze rośnie, ale ambitnie |
| Wsparcie w community | Od „jak to zrobić” po „czemu nie działa” | Trochę dziki zachód |
| Wersja Hello World | Jedna adnotacja i leci | Trochę więcej dłubania |
| Sytuacje awaryjne | StackOverflow cię nie zawiedzie | Czasem trzeba pogrzebać głębiej |
| Próg wejścia | Niski (albo przynajmniej znajomy) | Trochę wyższy |
| Praca w zespole | Każdy to zna | Ktoś musi „nauczyć resztę” |
A co z realnymi projektami?
Nie widziałem jeszcze dużego polskiego software house’u, który produkcyjnie przeszedł w 100% na Quarkusa. Startupy? Tak. MVP, mikroserwisy, funkcje w chmurze – idealne środowisko. Ale w bankowości, telco czy e-comie? Spring króluje. Bo „działa” jest nadal ważniejsze niż „działa szybko”.
Co więc wybrać?
- Jeśli masz do utrzymania system z legacy i 10 letnią historią – Spring Boot.
- Jeśli tworzysz mikroserwis na serverless z AWS Lambda – Quarkus.
- Jeśli chcesz szybko dowieźć coś w zespole, który zna Springa – nie kombinuj.
- Jeśli lubisz eksperymentować i nie boisz się, że trzeba będzie coś napisać samemu – spróbuj Quarkusa.
Czy warto przechodzić z Spring Boot na Quarkusa?
W większości projektów – nie. Quarkus nie jest „zamiennikiem” Springa. To framework dla innych przypadków użycia. Tam, gdzie dominują serwisy krótkotrwałe, działające w chmurze i uruchamiane setki razy dziennie – różnica w czasie startu i zużyciu pamięci może mieć znaczenie biznesowe. W projektach korporacyjnych, z rozbudowaną infrastrukturą CI/CD, monitoringiem i długim czasem życia procesów – przewaga Springa nadal jest wyraźna.
