Yep, Quarqus has definitely exploded just few weeks ago. As one of my friends said, it was marketing lvl8080! Just listen to the slogan – “Supersonic Subatomic Java!”. “A Kubernetes Native Java stack tailored for GraalVM & OpenJDK HotSpot, crafted from the best of breed Java libraries and standards”. Damn, so many buzzwords in one place! The twitter literally exploded as well. Literally everybody twitted about Quarkus.
I said – nah! Yet another microservices framework. There are many available now. The choice is really big. So, I almost ignored it. I’m honest here. Still the last Sunday I’ve downloaded it and played with some examples. My first experience was a failed build. I’ve submitted an issue in GitHub, and it turned to be my local maven issue. The fix was just to upgrade it. But as result this issue opened a discussion, and very same Sunday a maven version enforcer was added. The power of OSS! There are no weekend in OSS! Kudos to the team!
The twit flow nevertheless continued to appear in my feed. This somehow forced to open the Quarkus website and explore more. There was one logo that grabbed my attention:
I said – mmm MicroProfile. Lovin’ it! So it looks like I may try to pack a microservice (which is not Spring) in a GraalVM native image.
Ok, I need to try! This thought came to my mind about 3 a.m. this Thursday. Well, technically it was Friday already…
Luckily enough about a month ago we have deployed some CSV aggregation service. Yet another stage of some fancy bloody enterprise infinite process to generate some invoices. We have made it the most modern way using only MicroProfile specs, on WildFly server, running in some OpenShift pods (yes, we have a lot of RedHat licences). Mmm, a loot of cool buzzwords as well!
The service itself was completely stateless. With three rest clients we gather some data from there other services, mash them up in some CSV and serve it as a plain text on rest request! Technically it is insanely stupid! … making it the perfect candidate to be tested with Quarkus. By the way, all of the pipeline is still under development, so thus we’re not going to ruin someone’s bill and invoice.
Still the service has to work under some pressure. Thus OpenShift scales by adding pods. Since the service is stateless, we are totally ok with that! We also don’t have to care about rest providers from the other side. It’s their responsibility to scale 🙂
So, now comes the fun part!!! I’ve started a new project by copying some of the Quarkus quick–starters. Yes, I can generate a pom from an architype.. but I’m lazy.
I then just copy-pasted the code from my old project.. and it shined red.. Especially the the MicroProfile annotations.. ah. What’s wrong? 3 minutes of googling told me that for the MicroProfile stuff I need to add some Smallrye Quarkus extentions.. Ok, copy–pasted in the pom.xml.. Yay, the red is gone.
mvn clean package
… and BUILD SUCCESSFUL!
Ok, you made me sweat! Now let us:
mvn quarkus:dev
.. and .. http://localhost:8080/api/v1/invoicingRXT/1253211 (some contract)
AND I HAVE THE RESULT! That’s a WOW!!! This was one the fastest migrations I’ve ever done! I LOVE STANDARDS! Long live MicroProfile!!!
Ok, I have earned my coffee. It took me.. 17 minutes. Yes, this was mostly copy–paste, but look how cool is that!
… But, thats not over! Quarkus documentation says if I add -Pnative to the maven build command it’ll produce a native image! Let’s do it! Luckily I had already setup the GraalVM installation.
mvn clean package -Pnative
Waiting.. 1 minute… 2 minutes.. BUILD SUCCESSFUL! Lovely! Yes, it takes some time to build an image! I should admit, that the business logic code was written in quite straightforward way, without any fancy constructions, just some POJOs. There were no GraalVM specific issues.
Now let us just run the executable:
./invoicingRTXApp-runner
and the service is up and running in about a second! Although the console says the startup time is 0,212 sec. Technically from the run command to running service is about 2 seconds. THAT DOESN’T COMPARE to ~49 seconds startup time of the WildFly server..
Ok, now lets go to http://localhost:8080/api/v1/invoicingRXT/1253211 and what I see:
“”,””,””,””,””
Something went wrong!!! Why the example from the quick-starters work? Hmm… It looks like I’m missing one annotation over some classes – @RegisterForReflection. Reflection works a little different in GraalVM. Building it once again. Waiting another two minutes. Oh, how can two minutes can last so long..
Good! BUILD SUCCESSFUL! Now lets go to http://localhost:8080/api/v1/invoicingRXT/1253211 and what I see:
data1,data2,data3
IT WORKED!!! (Now imagine the famous Dexter from Dexter’s lab cartoon shouting this loud). That is so damn cool!!!
Nice! It’s been 42 minutes since the beginning of the experiment (coffee break included)!
Ok, now let us go back to the OpenShift setup. It will be nice to see if it’s ok in our test environments under some pressure. After making some yaml permutations I’ve rerouted 10% of the traffic to go the new native image pod. After 4 hours watching it work I see no errors! Only sometimes I receive some messages from surprised testers like “Something’s wrong, some pods start in 3 seconds only…”. And I say “Haha! This is magic.”
Now some intermediate conclusions:
– WildFly 78 Mb image, Native 21 Mb image;
– WildFly ~49 seconds start-up, Native ~2 seconds start-up time;
– WildFly ~300 ms per request, Native ~270 ms per request (we are dependent on other services).
– Wildfly ~359 Mb RAM (serving 1 request), Native ~22 Mb RAM (serving 1 request)
Lovely! Just, Lovely!
What can I say – Quarkus is definitely a good thing to play with. It showed extremely well in (almost) production code. Yes, I know the example is really stupid, but that’s a real world demand. The migration took me about 40 minutes by just copy–paste. I love standards!
The coming Monday I’ll make a full native setup, we’ll see how it goes! May be even in production soon..
Disclaimer: Sorry, I can’t share the code. It’s corporate..