Dlaczego Quarkus nie jest klonem Springa?

Quarkus został zaprezentowany światu w 2019 roku jako alternatywa dla frameworka Spring Boot.
Jego najważniejsze zalety to dostosowanie do środowisk skonteneryzowanych, niskie zużycie pamięci oraz szybki czas uruchamiania. W jakich projektach się sprawdzi?

Czym jest Quarkus?

Quarkus to projekt open source, który powstał, aby umożliwić programistom Java tworzenie aplikacji natywnych dla chmury. Tradycyjne frameworki Javy (np. Spring) wyewoluowały z dużych, monolitycznych aplikacji. W nich złożone zarządzanie zależnościami i łatwość konfiguracji zostały osiągnięte kosztem dużych wymagań dotyczących pamięci oraz długiego czasu uruchamiania. Quarkus jest inny. Jego głównym celem jest umożliwienie aplikacjom szybkiego skalowania (w górę i w dół) mikrousług oraz optymalizacji kontenerów poprzez lepsze wykorzystanie pamięci.

Kiedy wybrać Quarkusa?

Ponieważ napisano już wiele artykułów skupiających się na szybkości Quarkusa, ja spróbuję spojrzeć na niego z innej strony. Skupię się na tym, że przejście ze Springa może być dla programistów stresującą i nieatrakcyjną przygodą. Zrozumienie budowy Quarkusa i uzasadnienie niektórych wyborów architektonicznych może pomóc Ci w podjęciu decyzji, który framework będzie najlepszy dla Twoich nadchodzących projektów.

Czy Spring nadaje się do budowania mikrousług?

Spring i jego koncepcje są bardzo dojrzałe. Wywodzi się on ze środowisk współdzielonych, takich jak serwery aplikacji, w których każda aplikacja ma swój własny zestaw wymagań systemowych. Tradycyjnie koncentruje się na trójwarstwowej architekturze monolitycznej ze stopniową, wyważoną ewolucją i silnym naciskiem na kompatybilność wsteczną. Opiera się również w dużej mierze na dynamicznej logice środowiska uruchomieniowego z wykorzystaniem mechanizmów refleksji języka Java. Aplikacje oparte na platformie Spring zwykle cechują się jednak wysokim zużyciem pamięci RAM i wolniejszym czasem startu. Dlaczego? Ze względu na dużą ilość pracy potrzebnej do ich uruchomienia.

Quarkus natomiast, będąc frameworkiem zorientowanym na mikrousługi, implementuje specyfikacje MicroProfile. Jest to zestaw zasad opracowanych przez społeczność w celu optymalizacji Javy Enterprise dla architektury mikrousług. Ta platforma programistyczna powstała w 2016 roku przez IBM i do dziś się rozwija. Stale też jest aktualizowana o nowe wydania MicroProfile.

Radość z procesu developmentu

Na początku przygody z Quarkusem najbardziej wyróżniającą go cechą jest możliwość kodowania na żywo. Każda zmiana w kodzie jest natychmiast widoczna w interfejsie API. Czy to magia? Nie do końca, ale na pewno tak się to odczuwa. Po otrzymaniu zapytania HTTP na zdefiniowaną ścieżkę Quarkus wstrzymuje żądanie i sprawdza, czy w plikach źródłowych aplikacji nie zaszły jakieś zmiany. Jeśli coś się zmieniło, aplikacja zostaje w sposób przejrzysty skompilowana i ponownie wdrożona. Dopiero wtedy kontynuowane jest żądanie HTTP. Wszystkie, z wyjątkiem największych, są realizowane w okamgnieniu.

Nie bez wad

Jest jedna wada trybu deweloperskiego, którą zaobserwowałem, i którą możesz napotkać, jeśli Twoja usługa nie jest bezstanowa. W takim przypadku każde żądanie przeniesie nas z powrotem do nowego początku z każdą zmianą w kodzie źródłowym. Na szczęście w takich przypadkach możesz wyłączyć tryb programisty i użyć starego dobrego uruchomienia z wykorzystaniem jar.

Inne ułatwienia

Kodowanie na żywo to nie jedyne ułatwienie, jakie zapewnia tryb deweloperski. Jednym z nich jest przydatny interfejs użytkownika dołączany automatycznie do budowanej aplikacji. Umożliwia on deweloperowi wyświetlanie i zmienianie stanu aplikacji. To, co konkretnie możesz zmienić, zależy od rozszerzeń obecnych w projekcie. Niektóre z nich to: zmiana konfiguracji, uruchamianie skryptów migracji bazy danych, czyszczenie pamięci podręcznej lub uruchamianie zaplanowanych operacji.

Inne przydatne funkcje trybu deweloperskiego to: szczegółowe strony błędów, które upraszczają proces diagnozowania problemów i usługi deweloperskie zapewniające dostęp do bazy danych. Dostępne są też kolejki wiadomości, Keycloak i wielu innych usług całkowicie za darmo na starcie. Oprócz tego można korzystać z Mock mailera, który zapobiega wysyłaniu niechcianych wiadomości e-mail podczas programowania i testowania. To nie koniec, ponieważ lista jest długa. Mówiąc najprościej, zespół Quarkus robi wszystko, co w jego mocy, aby pomóc programiście skupić się na zadaniu i przyspieszyć proces otrzymywania informacji zwrotnych.

Podejście reaktywne

Innym powodem korzystania z Quarkusa może być sposób, w jaki obsługuje on w aplikacji zarówno architektury reaktywne, jak i imperatywne. Dzięki ścisłej integracji Quarkusa z Eclipse Vert.x możesz swobodnie wybierać między blokującymi i nieblokującymi bibliotekami oraz interfejsami API. W większości przypadków programiści są w stanie połączyć blokującą i reaktywną logikę w tych samych klasach. Quarkus upewnia się, że blokujące fragmenty kodu blokują się w razie potrzeby, podczas gdy reaktywne nadal nie są blokowane.

Inaczej jest, gdy korzystasz ze Springa. Tam decyzję o architekturze aplikacji musisz podjąć przed napisaniem choćby jednej linijki kodu. Taki wybór określa całkowitą liczbę bibliotek, które są dostępne podczas tworzenia aplikacji. Quarkus, który urodził się w epoce reaktywnej, był w stanie rozwiązać ten problem i pozostawia swobodę w prowadzeniu konkretnych interakcji na ostatnią chwilę.

Natywny Kubernetes

Coraz więcej aplikacji jest projektowanych z założeniem, że ich podstawową platformą wdrożeniową będzie Kubernetes. Aby osiągnąć najlepszą wydajność przy jak najniższych kosztach, należy wziąć pod uwagę szereg wymagań. Jakich? Są to m.in. niskie zużycie pamięci, szybkie uruchamianie, minimalizacja wątków systemowych, użycie Kubernetes ConfigMaps, ekspozycja ścieżek ze statusem stanu aplikacji.

Stworzony dla wydajności

Twórcy Quarkusa zaprojektowali go od podstaw z myślą o tych zasadach, z naciskiem na wydajność i szybki czas uruchamiania. Przetwarzanie jest kończone w miarę możliwości w czasie budowy. Klasy, które są używane tylko podczas uruchamiania aplikacji, są wywoływane w czasie kompilacji. Takie rozwiązanie pozwoliło wyeliminować ładowane ich do maszyny JVM środowiska uruchomieniowego, co zmniejsza rozmiar programu działającego na maszynie JVM, a ostatecznie jej zużycie pamięci.

Quarkus i Kubernetes

Ponieważ ta architektura od początku przewidywała natywną kompilację, Quarkus można opisać jako „natywny dla Kubernetesa”. Porównywalne natywne możliwości w Springu są nadal uważane za eksperymentalne, beta lub być może niedostępne w niektórych przypadkach. W ramach danego zestawu zasobów można wdrożyć więcej aplikacji Quarkus niż innych aplikacji Java lub Spring w połączeniu z platformą uruchomieniową taką jak Kubernetes.

Podsumowanie

Masz problem, który można rozwiązać za pomocą architektury mikroserwisowej, a swoją aplikację planujesz wdrożyć na Kubernetesie? Chcesz w pełni wykorzystać potencjał podejścia reaktywnego lub po prostu pobawić się czymś świeżym i „seksownym”? Zdecydowanie daj szansę Quarkusowi. Satysfakcja z wypróbowania nowości i odkrycia, że rozwiązanie to jest przemyślane, powinna Ci wystarczyć. Poza tym, jak wspomniałem na początku – Quarkus nie jest klonem Springa. Podobnie jak młotek i śrubokręt, oba są różnymi narzędziami, które warto mieć pod ręką i używać wtedy, gdy są potrzebne.

Odnośniki

• https://quarkus.io
• https://www.manning.com/books/kubernetes-native-microservices