Session

Serverless Search for My Blog With Java, Quarkus, & AWS Lambda

What You'll Learn

1Hear about Quarkus, what it is and how it helps.

2Learn how to build a serverless application with Quarkus.


A Serverless app? With Java?! Absolutely!

We’ll discuss when Serverless is a great fit (and when it isn’t!) and why you don’t need to leave the Java platform when going Serverless. Based on the real-world example of a Serverless blog search, you’ll learn how Quarkus and GraalVM help you with building apps for AWS Lambda, which are blazing fast to start up and are memory-efficient at the same time. We’ll explore

  • Which options Quarkus provides for creating AWS Lambda apps, making noticeable cold-start delays a thing of the past 
  • What it takes to enable existing libraries like Apache Lucene to be used in GraalVM native binaries
  • How to build Serverless apps which are portable across platforms, avoiding lock-in into specific cloud providers

Join us for this session to stop worrying about cold-starts and exploding costs, and learn how to love Serverless -- Java style!

What's the work that you're doing nowadays?

I work as a software engineer at Red Hat, where I'm focusing on Debezium. Debezium is a tool and a platform for change data capture. This means it taps into the transaction log of your database and then whenever there's insert or an update or delete, Debezium will capture this change event and propagate it to any sort of consumers, typically through Apache Kafka. This enables all sorts of interesting use cases like data replication, updating search indexes, filling a cache, maybe exchanging data between microservices, all those kinds of things. Another project I am involved with is called Quarkus. Quarkus Is essentially a stack for building cloud-native microservices.

What I'm going to talk about at QCon is how you could use Quarkus for implementing a serverless application running on AWS Lambda.

Can you give a quick overview of Quarkus, does it come with its own web stack or does it build on servlets or is it completely custom?

The story behind Quarkus is that at some point smart folks realized that Java is a bit at risk of falling behind when it comes to things like Serverless or having this notion of rapidly scaling up and scaling down in cloud-native environments. The reason for this was that Java sometimes is perceived as a bit heavyweight. It can take long to start up, it uses lots of memory, which is not desirable if you think for instance about dense packing in cloud environments. And Quarkus is really a framework which aims at improving those things.

Quarkus has this notion called “compile-time boot”, which aims at doing things once at build time, which your traditional stack would do each time the application starts up. Just to give one example, it would scan your classpath to find all your JPA entities, so a framework like Hibernate can process them. Within Quarkus, all those things don't happen at application startup time, but they already happen at build time. Then essentially information about this is recorded into bytecode structures. This means that when the application starts up, it doesn't have to do classpath scanning. It doesn't have to do the processing of all sorts of deployment descriptors like a web.xml and others. This means it starts up very fast and it also uses less memory because if for instance you don't need to parse any XML descriptors, you don't need to load the XML parser classes. Quarkus does that for the JVM, but also for GraalVM. So if you want to go to the next level and start up really quickly in terms of milliseconds, then you would look into native binaries and ahead of time compilation, and Quarkus helps with that, too.

Coming back to this question, what kind of stacks does it include? The idea is it enables all sorts of popular and best of breed libraries and application stacks. There’s things like Vert.x, JAX-RS, Hibernate, Kafka clients, all the specs from the Microprofile ecosystem, and much more. Quarkus integrates all these libraries and specifications and makes them easily usable in native binaries.

I guess the key contribution is the compile time startup. That's what makes it fast and efficient, I guess?

These improvements around start up time and memory consumption definitely are a key contribution. But there's many things more to be said about Quarkus. For instance, there's a very strong focus on the notion of developer joy. As a developer, it should be fun for you to work with this. It has what’s called the “dev mode”: which allows for very fast feedback while you’re working on your application.

You just keep working on the code in your editor and then you save the file. Let's say you have a REST endpoint implementation, you save the file and then Quarkus will automatically pick up this change and reload everything. If you call the API, you will now get the updated response.

There's those things around developer joy, but also it puts a very strong focus on making things just work when it comes to things like config maps, building container images very efficiently, and more. The idea is to make it a pleasure to work on such an application and then deploy it to the cloud.

With Graal I get an extra boost by not having to run the JVM?

GraalVM is many things, but really here we are talking about the notion of ahead of time compilation. So it just means you don't have to start a virtual machine and do JIT compilation. Everything gets compiled ahead of time .This comes with some implications. First of all, this is based on a 'whole world' assumption. What you could typically do in Java, like adding stuff to the classpath at runtime or assembly time, you cannot do this with GraalVM and native binaries because there everything needs to be known upfront. But then typically, if you think about your microservices and these things, you look at immutable software to begin with. So this 'whole world' assumption, that definitely applies there. This means GraalVM can apply all kinds of optimizations. It can eliminate lots of dead code, which actually isn't invoked. It doesn't need to carry around all the infrastructure of the JIT compiler. That way it is able to start up really in, let's say, tens of milliseconds typically, and it will use a very small amount of memory. So, for instance, now it also becomes feasible to implement CLI applications in Java, which is something we typically would not have done before. But now actually you can do this because you have this fast start up and you have this smaller memory consumption.

What do you want people to take away from your talk?

The key take-away is how to build Serverless applications using Java and Quarkus, based on the real-world example of a blog search. I have a personal blog and every now and then I write there about technical stuff. At some point, I wanted to have a search feature for my website so people don't have to go to a search engine, but instead they can go to my blog and they have a local search right there. So I wanted to implement this, and I wondered, "how do I do this"? My blog is a static web site, it is deployed to GitHub Pages. That means there's no application server running. Those kinds of dynamic features like a search are tricky to do then. The notion of Serverless computing came in very handy for that, because I just have to put a search input field on my blog. And then whenever somebody puts in a search request, the serverless function running on AWS Lambda is invoked. It probably started up just at that point in time. It runs the search and then it returns the result back to the user.

And that’s what I'm going to talk about: how is this implemented? Also, why did I use a serverless implementation to begin with? Why didn't I look at, let's say, running this on a traditional application server? And then, of course, how is this actually working? I'm using Apache Lucene, which is, I would say, the standard search engine in Java. And now in order to use this in a native binary through GraalVM, you need to be aware of some limitations. You cannot use things like reflection or method handles. I will tell people how you can go about this, how you can take a library and then run this in a Graal VM native binary.

Then there’s the question of how you can build this using Quarkus; there's different ways you can go about serverless applications with Quarkus. I will compare them, when you would use which one, and people could decide for themselves what would be the best approach for their situation.

Lastly, there's also practical matters. This is a personal blog, and I don't have any operator which runs this thing for me 24/7. I need to be really sure that there's not what I call a 'denial of wallet' attack: somebody's just going to my search and invoking it a gazillion of times. With Serverless, you pay per request and this could add up. Maybe I'm on holiday and I don't check back with the console of AWS, and then I would have a bad surprise and I would have to pay lots of money. I will explain how you can make sure that this doesn’t happen.


SPEAKER

Gunnar Morling

Open Source Software Engineer @RedHat

Gunnar Morling is a software engineer and open-source enthusiast by heart. He is leading the Debezium project, a tool for change data capture (CDC). He is a Java Champion, the spec lead for Bean Validation 2.0 (JSR 380) and has founded multiple open source projects such as Deptective and MapStruct. Prior to joining Red Hat, Gunnar worked on a wide range of Java EE projects in the logistics and retail industries. He's based in Hamburg, Germany.

Find Gunnar Morling at:
DATE

Tuesday Nov 17 / 10:00AM PST (40 minutes )

TRACK Modern Data Engineering ADD TO CALENDAR Add to calendar SHARE

3 weeks of live software engineering content designed around your schedule.

Don’t miss out! Save your seat now

Register
TOP