Today Daniel Oh from Red Hat came to IQSS to tell us about Quarkus.

Backstory

There's some backstory to this. Last summer I was really fired up about Quarkus after hearing about it on various podcasts and then hearing Daniel give a talk about it at DevConf. (That talk is on YouTube and his slides are available.) I went home and tried Quarkus (and GraalVM) myself. It really worked. Awesome.

Shortly after, I sent the following message (slightly edited below) to the Dataverse internal mailing list. In short I was suggesting that we could rewrite a Django app into Quarkus.

From: Philip Durbin philip_durbin@harvard.edu
To: Dataverse Team
Subject: porting the dataverse-installations “map” app from Django to MicroProfile/Quarkus
Date: Fri, 30 Aug 2019 10:41:53 -0400

Dear Dataverse Team,

Last night I went to a great talk called Polyglot Java EE on the GraalVM.

A couple weekends ago I went to Quarkus brings Serverless to Java developers.

Both talks have given me yet another crazy idea.

We have a legacy Django “map” app inside Miniverse with various problems that powers the map of 46 Dataverse installations that we all love. We basically haven't made any improvements to it since the original developer left.

During the community meeting I extracted just the map app into a new git repo called dataverse-installations. This was because there was so much interest in enthusiasm in “installation personas.” I like the way Janet McDougall from the Australian Data Archive explains installation personas:

“Installation Personas can be used to describe and classify users’ needs, experiences, behaviours and goals. Within the community we are discovering that we want to identify installations that may have already implemented a configuration, or are working towards a similar outcome, to share or build on experiences.”

I figure eventually someone, maybe me, will brush up on my Django skills and hack the dataverse-installation app, fixing the security problems, etc.

But what if instead we switch dataverse-installations from Django to MicroProfile and Quarkus?

I was absolutely blown away by the Quarkus talk because of the increase in developer productivity he showed. And the nice thing is that what you are building is just a normal Java EE/Jakarta EE/MicroProfile app. You could use Quarkus to speed up your development time, but still just produce a standard war file if you don't want to use the fancy features of Quarkus such as compiling to a single fast binary (like Go does) for deployment.

Maybe you see where I'm going with this… Dataverse is also Java EE app but developer productivity is poor and getting worse: #5593

The idea, the hope is that we could learn a bit with a tiny app like dataverse-installations some tricks that we can bring into Dataverse some day.

Advantages of switching dataverse-installations from Django to MicroProfile/Quarkus:

• Learning MicroProfile APIs. I'm eager to learn the MicroProfile Configuration API (#5293) as well as the MicroProfile Metrics API. You get MicroProfile for free when you upgrade from Glassfish to Payara (#2628 ) or other MicroProfile application servers such as OpenLiberty, WildFly, or TomEE.
• Providing an easier on ramp for future contributors to Dataverse. Even if contributors have never touched Java or Java-related technologies we use in Dataverse such as JPA, new contributors could get comfortable in the tiny dataverse-installations app and later “graduate” to hacking on Dataverse itself.
• Investigating if moving Dataverse to Quarkus will increase developer productivity.

Disadvantages of switching dataverse-installations from Django to MicroProfile/Quarkus:

• It'll take some time to make the switch.
• Perhaps Python and Django are easier for contributors to hack on than Java and Microprofile?

Yet another thought is that Orran Krieger of Mass Open Cloud fame is actively looking for project ideas for his Cloud Computing Course that is starting very soon. So maybe I can team up with Dan McPherson again and get some students to do the work for us. I would just spend time mentoring and advising, doing code review, etc. The students would learn to deploy a real app to the cloud using cutting edge technology. Dan or other mentors from Red Hat would like it because Red Hat makes Quarkus.

This could also be a great talk for JavaOne. I mean, Oracle Code One. :)

I'd be happy to give an IQSS tech talk about all this. Or I could schedule a meeting just for anyone who's interested.

What do you think? :)

Phil

I ended up talking about Quarkus at tech hours (no demos) but I still though a tech talk would be nice.

Daniel Oh at IQSS

When Daniel gave his talk (again on YouTube) last summer, I asked a question at the end and chatted with him afterwards. Then I nagged him to put his slides up. Finally, I asked if he would like to give the tech talk. To my delight, he agreed.

It was fun to see his pictures of walking from the parking garage to our office today. He arrived plenty early and I introduced him to a number of people on my team.

His talk was titled “Faster, Easier, and More Natural: Cloud Native Java Apps with Quarkus” and here is the abstract:

Are you a Java developer? Have you been able to move your whole application stack to cloud-native microservices and/or serverless? I didn't think so. Well, your wait may be over: Quarkus, a Kubernetes Native Java stack tailored for GraalVM & OpenJDK HotSpot, based on the latest open-source Java libraries and standards is now available. Quarkus allows you to develop cloud-native microservices without a steep learning curve and build a native executable artifact that just needs milliseconds to start. Quarkus also offers a fast feedback loop for developers through its live coding feature.

The demo gods were with him and the main takeaways for me were:

• Java developers can have a fast feedback loop with Quarkus.
• By adding GraalVM, Quarkus apps can have an incredibly fast startup time.
• Quarkus apps can have a much smaller memory footprint than traditional Java apps.
• Quarkus enables a modern development approach that includes Docker and Kubernetes.

So what

The sense I got from team members after the talk is that Quarkus seems interesting and demos well for “hello world” apps but doesn't have much to do with Dataverse. It would probably take a lot of effort to move our 200,000 lines of code to Quarkus.

That said, there are perhaps some opportunities to use Quarkus if we decide to pull some functionality out of the Dataverse monolith into a microservice. During the talk we touched on how the ingest functionality of Dataverse is a potential candidate for this.

Oh, and by the way, even thought I thought it might be interesting to re-write the Dataverse “maps” app from Django to Quarkus, in the end I greatly simplified it by rewriting it from Django to a static site powered by Leaflet and a JSON file as data. But that's a story for another day.

Chatting with Daniel after his talk I realized he's a neighbor so there's a decent chance I'll bump into him. Plus he's absolutely willing to come back and spend more time with us. Thanks, Daniel!