Quarkus to nowy gracz na rynku, jeśli chodzi o produktywność i wydajność tworzenia mikrousług (ang. microservices).
Czy wysoka produktywność i wydajność tego szkieletu to tylko przechwałki? A może kryje się za tym coś więcej?
Spróbujmy odpowiedzieć na te pytania.
Problem
W świecie Javy lider wśród szkieletów do budowania aplikacji web, czy też mikrousług, jest jeden. Jest to oczywiście Spring Boot.
Popatrzmy trochę na historię Springa. Jeszcze 10 – 12 lat temu sytuacja była trochę inna. Wówczas królowała Java EE. Spring powoli zyskiwał popularność jako lekki szkielet, który łamie zasady rynku. Stał się synonimem nowego ruchu, wprowadzającego świeży powiew dla programistów. Okazało się, że aplikacje korporacyjne wcale nie wymagały dużych serwerów aplikacyjnych zgodnych z Javą EE, tony deskryptorów wdrożeniowych i klas, których istnienie wynikało tylko z konieczności dostosowania się do nieelastycznych specyfikacji.
Z biegiem lat Spring również zaczął obrastać w różne zależności i powstało wokół niego mnóstwo projektów. Można by podsumować, że Spring zaczął być po prostu „duży”. Nieuchronnie zaczął zbliżać się do punktu, gdzie znajdowała się Java EE, gdy on sam pojawił się na rynku.
W tym momencie powstała fajna idea uelastycznienia szkieletu. Pojawił się Spring Boot, który stosując mocniej podejście Convention over Configuration, pozwolił developerom Javy na dużo łatwiejsze rozpoczynanie projektów, przy jednoczesnym wsparciu dla tworzenia aplikacji standalone.
Można by powiedzieć – czego chcieć więcej?
No właśnie kilku rzeczy, które właśnie wynikają z charakterystyki Spring Boot.
Produktywność
Co jest zmorą wszystkich developerów aplikacji Java w Spring Boot?
Myślę, że w top 3 znalazł by się temat odświeżania aplikacji. Zmieniliśmy linijkę kodu, restart. Zmieniliśmy drugą linijkę, restart. Trzecią, restart. I tak cały czas.
W teorii, jeśli masz odpowiedni sprzęt i aplikacja jest „raczej mała”, to trwa to tylko chwilę. Z drugiej jednak strony te parę sekund, kilkadziesiąt razy dziennie staje się denerwującym fragmentem rozwoju aplikacji.
Możemy to trochę złagodzić używając dev tools lub innych narzędzi, ale … nie oszukujmy się, nie jest to rozwiązanie idealne, ani bliskie ideałowi.
A jak robi to Quarkus?
Można by rzec, że podobnie. Ale dużo szybciej. Quarkus nie zależy wewnętrznie od typowego serwer aplikacyjnego, a przez to proces rekompilacji i uruchomienia jest o niebo szybszy.
Podczas rekompilacji aplikacja cały czas może przyjmować żądania. Dzięki temu mamy cały czas złudzenie, że system działa bez przerw. I jest to bardzo miła odmiana w porównaniu do restartowania Spring Boot.
Wydajność
Mała aplikacja, na przykład Spring Boot z obsługą bazy danych poprzez Hibernate to plik jar, którego rozmiar zaczyna się raczej od kilkudziesięciu megabajtów, plus minus 50 MB. Ile pamięci RAM może konsumować, gdy już zostanie uruchomiona?
Razem z maszyną wirtualną Javy możemy tutaj liczyć na ponad 200 MB.
Taka liczba nie napawa zbytnim optymizmem. Zwłaszcza, gdy chcemy wystawiać kilka, czy kilkaset, mikrousług, które powinny być dodatkowo skalowane za load balancerem.
Quarkus działający na JVM pozwala na zyskanie około 25% pamięci operacyjnej. Wydaje się, że 25% to liczba, która nie robi dużej różnych. Nie jest to skok jakościowy i nie sprawi, że nagle Quarkus zyska miano króla wydajności.
Gdzie jest magiczny haczyk?
Otóż Quarkus został zaprojektowany od razu jako narzędzie, które pozwoli na kompilację natywną pod naszą platformę. Jak wtedy mają się nasze dane?
Otóż okazuje się, że aplikacja oparta o Quarkus zyskuje tutaj około 90%. Zamiast 200 MB jej zużycie pamięci bliższe jest 20 MB. I to jest niewątpliwie efekt WOW.
Widać więc, że tutaj zyskujemy. A jako jest w przypadku startu aplikacji?
Ten element wcześniej wymienialiśmy jako jeden z kluczowych w kontekście produktywności. I tutaj też jest po prostu świetnie. Dane przedstawione na quarkus.io mówią o około 80% redukcji czasu przy uruchamianiu na JVM i uwaga … ponad 99% redukcji czasu tego uruchamiania dla aplikacji w trybie natywnym. WOW.
Widać, że hasło Quarkusa SUPERSONIC SUBATOMIC JAVA jest jak najbardziej na miejscu. Quarkus to produktywność i wydajność.
Podsumowanie
Czy to wszystko znaczy, że powinniśmy już teraz rzucić wszystko i przesiadać się na szkielety nowej generacji typu Qurkus?
Pewnie nie od razu. Ale z biegiem czasu w architekturach mikrousługowych powinien pojawić wyraźny trend odchodzenia od Spring Boot na rzecz nowych narzędzi. Quarkus pokazuje, że na polu, gdzie liczą się produktywność i wydajność jest dużo miejsca do popisu.
Spring Boot, jako obecny standard korporacyjny, na razie jeszcze będzie moim podstawowym narzędziem ogólnego zastosowania. Quarkus jednak dostanie niedługo szansę na pokazanie swoich zalet w nowych projektach.
Na koniec pytanie do Ciebie, drogi Czytelniku? Czy chciałbyś przeczytać więcej na temat Quarkusa? Odpowiedz w komentarzu 🙂
Dzięki Bartku za fajny artykuł.
Zaletami Springa są dla mnie stabilna firma stojąca za nim oraz rozszerzalność i cały jego ekosystem (tak jak napisałeś, to obecnie standard w branży). Wydaje mi się, że ucieczką przed częstym pełnym restartem mS przy dewelopmencie mogą być np. testy.
Zaciekawiłeś mnie tym tematem, zwłaszcza niską zasobożernoscią. A jakie widzisz braki/minusy w porównaniu Quarkus’a ze Springiem?
Pozdrawiam i cieszę się, że ruszyłeś dalej ostro z blogiem!
Hey Maciek. Dzięki za komentarz 🙂
Quarkus jest bardzo młody, a co za tym idzie nie jest jeszcze tak znany i wykorzystywany w aplikacjach produkcyjnych. Stojący za nim Red Hat to fajny prognostyk na przyszłość, zwłaszcza w kontekście chmury.
Ze Springiem jest tak, że możesz w nim napisać zarówno monolit z kilkuset tysiącami linii kodu, jak i mikrousługę dla konkretnego wydestylowanego kontekstu. Quarkus wydaje się dużo bardziej nakierowany na usługi. Minusy to mniej materiałów i mniej bibliotek. Spring jest jednak narzędziem, gdzie na każdą okazję znajdziesz już teraz kawałek gotowego rozwiązania.