Quarkus 101: Intro To Java Development With Quarkus
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61626 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023287 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Java appletPoint cloudServer (computing)Scheduling (computing)Software frameworkWorkloadMultiplication signSoftware developerTwitterDifferent (Kate Ryan album)Physical systemCartesian coordinate systemScaling (geometry)MathematicsComputer animation
03:20
Stack (abstract data type)Point cloudSupersonic speedJava appletStack (abstract data type)Maxima and minimaSemiconductor memoryPoint (geometry)2 (number)Cartesian coordinate systemMultiplication signGoodness of fitBitJava appletPoint cloudSoftware testingTerm (mathematics)Structural loadComputer animation
05:20
Instance (computer science)BitCartesian coordinate systemPoint cloudSpacetimeJava appletComputer animation
06:51
Data managementThread (computing)Endliche ModelltheorieCartesian coordinate systemMultiplication signSoftware frameworkStructural loadCompilation albumSocial classJava appletComputer fileMessage passingPanel painting
08:04
Service (economics)Software developerSoftware testingService (economics)Statement (computer science)Software testingEvent horizonCodeMultiplication signMathematicsFormal languageExpert systemSoftware developerExecution unitComputer programDatabaseVirtual machineUnit testingCartesian coordinate systemFeedback2 (number)Web browserSoftware frameworkBookmark (World Wide Web)Extension (kinesiology)Different (Kate Ryan album)Local ringAsynchronous Transfer ModeMereologyJava appletStandard deviationConfiguration spaceCompilation albumSocial classInstance (computer science)Imperative programmingInheritance (object-oriented programming)Medical imagingSemiconductor memoryComputer animation
15:05
Configuration spaceMappingCodeComputer animation
15:52
Compilation albumVirtual machineProfil (magazine)Java appletMultiplication signTerm (mathematics)WhiteboardCartesian coordinate systemBuildingDistribution (mathematics)Local ringComputer animation
17:35
Software developerSemiconductor memoryMaxima and minimaComputer animation
18:12
Java appletOperator (mathematics)Connectivity (graph theory)Software frameworkProcess (computing)Event-driven programmingMachine codeGroup actionBuildingFunctional (mathematics)Computer animation
19:08
Software developerSoftware developerDatabaseAsynchronous Transfer ModeCartesian coordinate systemTwitterDampingComputer animation
20:08
Medical imagingMultiplication signComputer animation
20:34
Multiplication signMaxima and minimaNumberSlide ruleGraph (mathematics)Computer animation
21:37
Spring (hydrology)Extension (kinesiology)Library (computing)CodeSoftware developer
22:57
Physical systemVirtual memoryStreaming mediaSoftware developerLocal GroupJava appletFile formatHill differential equationGamma functionCartesian coordinate systemSpring (hydrology)Sheaf (mathematics)Computer animation
23:34
Graphic designGamma functionPhysical systemLemma (mathematics)Formal grammarStreaming mediaJava appletLocal GroupVirtual memoryConvex hullKeyboard shortcutTerm (mathematics)CompilerComputer animation
25:06
Program flowchart
Transcript: English(auto-generated)
00:05
All right, welcome. How do you like our little Duke rock stars here? So there's stickers going around somewhere so you can get some of these stickers. I think we have four different rock stars or something.
00:23
Anyway, so let's talk about Quarkus, obviously. Who am I? I'm a developer advocate at Red Hat. My name is Kevin Dubois. You can find me on Twitter or Macedon and yeah.
00:45
So I know we've already talked in a few sessions today about traditional Java and the startup time and all that stuff so I'll do that some more. So we'll talk about traditional Java.
01:01
So traditional Java is, can I see the little hand? Traditional Java is designed for, let's say, at different times, not designed for cloud native workloads necessarily. It's designed for running kind of long time
01:22
and what's important in traditional Java is throughput at the expense of footprint. So footprint can be quite large, right? You typically have traditional Java applications running on pretty beefy servers and they're designed to be long running and you have dynamic loading and all that stuff
01:43
with mutable systems but in the cloud native world, your throughput, you get that mostly through scaling. Your workloads are ephemeral which means that, you know, like if you think of containers, when you scale up a container, when you start up a new application,
02:04
those containers are gonna start up and then maybe they're gonna get rescheduled on a different node and so containers kind of come and go. They're not gonna be around and if you change something in a container, that change is not gonna last, right? Because that container, whatever you change inside,
02:22
that's gonna be gone when that container gets removed. So in that sense, we have to think of Java in a different way. We need to think about the footprint of it because we want smaller containers that we can schedule across different servers.
02:44
If you are familiar with Kubernetes and clusters, there's usually multiple servers on which it schedules containers so we need to be able to handle that. And so that's where Quarkus started,
03:01
was kind of invented I guess because it's a framework that uses Java but we call it supersonic because it starts up very fast. Subatomic because it's very small like subatomic smaller than an atom and it's still Java.
03:21
So if we look at Quarkus in terms of startup time and in terms of memory usage, you can see here, this is a test that they did with a relatively small application running on a traditional cloud native stack. It took 136 megs of memory
03:44
running the same application with Quarkus. You already got pretty good gain in memory, right? And that's running on the JVM. So it's the exact same application running on the JVM. And then compiled down to a native,
04:01
with GraalVM you get of course even less memory usage and you can see here too, Quarkus starts up quite a bit faster than a traditional cloud native stack which is ideal when we're talking about cloud native, when we're talking about containers, talking about serverless where we need to start up really fast
04:21
so we can react quickly to changing loads. So startup time is one thing. There's also the warmup issue. I don't know if issue is the right word, but actually when an application starts up,
04:40
it takes a while with Java before you get your maximum throughput as well. So here we can see that, like a traditional Java application, this is actually the points and I think this is like 13 seconds or something before it's actually able to be working
05:02
at maximum throughput, which for this particular use case, it needed a certain amount of throughput to be able to handle the load enough. And then you can see here with Quarkus, it goes quite a bit faster. Now, Quarkus isn't just about fast startup time. It's not just about memory,
05:21
but it is kind of a nice feature of Quarkus. So if we think of containers and Kubernetes nodes, traditional Java applications running on EAP or WebSphere or whatever, running on a Kubernetes node, you can see they take up quite a bit of space. Let's say that in this case,
05:42
only four instances of the application can run, which isn't so ideal because if one of the pods, one of the containers goes down, that means you lose 25% of your workload, right?
06:01
If you look at Quarkus on the JVM, you already have quite a bit more density, which means that if one of these guys goes down or needs to be rescheduled or whatever, you still have, what is it? Maybe 70% or something. That's still up.
06:22
And we can compare that to Node.js or Go or something where Go has quite a smaller footprint. And with Quarkus Native, we can actually be very comparable with Go, which is nice because that means that we can use our Java skills
06:40
and not have to change languages and reinvent the wheel and still get all the benefits in the cloud native world of having fast startup and everything. So how does that work? So a traditional Java application, basically build time is when you do your packaging and then as it starts up, it loads config files
07:03
and then does class pass scanning and build kind of its model of the world and everything. But this is when it starts up. So if you think of containers again, that means that this all happens when the container starts up and that takes a while.
07:20
And then so with Quarkus, what we try to do is instead of doing all that at runtime, at startup time, we're trying to do all of this or as much as we can during build time before the application actually gets packaged, which means that during runtime,
07:41
we have a lot less to do, right? So it starts up quite a bit faster. So that's kind of the cool thing about Quarkus. And then, so you can use Quarkus on JVM or you can compile it down to native, of course, just like most other frameworks.
08:01
But there's some cool things about native compilation with Quarkus as well that we'll get into in just a second. So this is my favorite part about Quarkus. It's not necessarily, I mean, yes, it's nice that it starts at fast. It's nice that it has a small memory footprint, but what's really cool about Quarkus is that it has a bunch of different ways
08:22
of making the experience of working with Java and Quarkus a lot more fun. So one of them is, so of course it's based on standards. So Quarkus uses your Java EE standards,
08:40
the Java standards uses Vertex and all that good stuff. So if you're used to that, hey, great. You basically already know Quarkus for 99%. What's really cool with Quarkus is that there's this dev mode. Basically, you can start Quarkus
09:00
on your local machine in dev mode. It's gonna start up and it's gonna just keep checking to see if you make changes in the class path. And so every time you make a change, it's gonna automatically reload when you, let's say, go into your browser, whatever you make a new request, it's gonna automatically reload your application.
09:23
So you don't need to recompile, redeploy every time you wanna test something. Quarkus does that automatically. So you can just go to your browser, hit refresh, and it's there. So make a code change, refresh, it's there. Which if you're a developer of some other language
09:44
where that just happens, then that's not so cool. But in Java, that's pretty cool, right? So you got our little guy here that says, wait, so you just save it and your code is running and it's Java? And the guy says, I know, right, supersonic Java. So that's pretty cool.
10:03
Another cool thing with Quarkus is that it has this concept of developer services. So who knows test containers? So basically it uses test containers built into Quarkus. So let's say that I'm developing an application
10:21
and I'm adding an extension to use Postgres database or a Kafka topic or something. Actually, well, of course you have to have a Docker or Podman or something running on your local machine. But Quarkus will look and see,
10:41
hey, you've got this dependency on a database. Do you have something configured on your local machine? Do you have a database running on your local machine? Is that configured in your application properties? If not, no worries. I'm just gonna start up a container with that dependency,
11:01
for example, a Postgres database and wire that up. So it's gonna set the configuration so that it connects to that database automatically. And then you can even go and see what exactly that configuration is and then copy it down.
11:21
Anyway, so that's the developer services. So Kafka or, yeah, there's a whole bunch of different developer services that you can use just out of the box, which is pretty nice because otherwise having to configure a database on your local machine or, Lord forbid, a Kafka instance with all your zookeepers
11:42
and all that stuff, that's not so easy. You also, so you have live coding, you also have continuous testing. So kind of the same concept. So if you have unit tests, you start your continuous testing so every time you make a code change,
12:00
it knows, hey, this class is related to this unit test, so I'm gonna rerun this unit test every time I make a change here or vice versa. If you're making a change in a unit test, it knows this is what I need to rerun. So it gives you quick and immediate feedback every time
12:21
as you're developing, which yeah, again, it's pretty handy. It also has a dev UI, so it has a UI in your browser where you can go and look at all these different developer services that are running, what Quarkus is doing. So again, I was talking at the start about
12:45
Quarkus doing some optimization, right? So during the compilation time, so in the dev UI, you can actually see what it's doing, how it's optimizing and what it's gonna remove
13:02
from the class path because Quarkus does some introspection to make sure that, hey, this is used or this actually isn't used by your code so I'm gonna remove all that from the compilation. There's a Quarkus CLI, which again, it's not super
13:23
crazy, but so you can either use Quarkus with Gradle or Maven or you can just use the Quarkus CLI, which means that you can do like Quarkus dev or Quarkus build or whatever. You can even use, you can say Quarkus image build
13:44
or image push and it's gonna build your application, so build your application, build a container and you can even push it automatically all from one command, which is kind of handy, right?
14:02
And then one of the last but not least is unification of imperative and reactive programming. So Quarkus has a lot of reactive programming kind of built in underneath. Now me, for example, I'm not a super deep expert
14:23
in reactive programming, but what's nice with Quarkus too is that I can write imperative code, right? So just every statement gets handled one at a time and it blocks every time, whereas with reactive, you've got these event loops, but you can use both at the same time in the same, even in the same code
14:44
in the same class, so for those who are familiar with reactive, usually you kind of have to decide, hey, if I'm gonna build a reactive application, that means I have to decide before I start writing this code that this framework that I'm gonna use is reactive and I can't combine the both,
15:02
but with Quarkus, you can, which is nice. And best of all, it's still Java, right? So you get all these kind of features and at the end of the day, if you're familiar with Java, this is really not reinventing the wheel at all. So it uses micro profile, Vertex, REST easy,
15:24
and if you wanna add extensions, you can interact directly with Kubernetes. So you can push your code directly to Kubernetes. You can create config maps or secrets directly from Quarkus. You can work really easily with Kafka
15:46
and OpenShift, of course, Apache Camel and all that. So in terms of native compilation, I think we've already had a few sessions about that, so I'm not gonna go too deep into that
16:01
other than if you can run Quarkus on the JVM and probably for 70 to 80% of the use cases, that's probably a good way to go. If you really want to have the fastest startup time and the smallest footprint, then you can do a native build
16:23
of your Quarkus application. With Quarkus, by the way, that's really easy because if you create a new Quarkus application, it automatically has a native profile built in, so you can decide as you're doing your compilation whether you wanna do a native build or not.
16:43
But yeah, so Red Hat is on the GraalVM advisory board and then there's the Mandrel project, which is a downstream distribution of GraalVM, specifically for building Java native builds.
17:01
And that's what Quarkus uses too. For example, if I do a native build and I don't have GraalVM installed on my local machine, Quarkus will, again, pull down a container, it's really good at pulling down containers, to do a native build inside a container
17:21
on your local machine. So again, then you don't need to have GraalVM installed and configured on your local machine. So it really tries to make your life as easy as possible and kind of have the benefits of a lot of the things. So if you're thinking of, should I do a native build
17:42
or just run on the JVM, this is kind of an opinionated scoring. But if you want the maximum developer joy, the best and easiest monitoring, peak throughput and reduced max latency, then you wanna run it on the JVM.
18:01
If for you it's important to have the lowest memory footprint, a small packaging and a very fast startup time, then a native build is probably the way to go. So what do you wanna use? What can you use Quarkus for? Virtually anything.
18:21
So there are Quarkus-based Kubernetes operators. So there's an operator framework where you can create these automatic components in Kubernetes that manage resources in Kubernetes.
18:41
You can create GitHub actions with Quarkus. You can create just regular jobs. Yes, you can build traditional Java applications, even monoliths with it. But this is, of course, the sweet spot of Quarkus's cloud native application. So event-driven applications, reactive systems,
19:02
microservices and serverless and functions. So that's about it for my session. So if you wanna check out Quarkus more, developers.redhat.com has a ton of resources on Quarkus,
19:22
on a lot of developers' stuff. This dn.dev slash Quarkus tutorial is just a kind of a nice, lightweight introduction to Quarkus where you can create an application from scratch and then kind of add some components. As you go, you add a database
19:42
and then check out the live, the dev mode and all that stuff. So it's a pretty nice thing. Yeah, and like I said, if you wanna keep up to date, you can follow me on Twitter or Mastodon.
20:00
I try to post interesting stuff, but I don't know if that's really true, but we'll see. All right, and that's it for me. Thank you. Any questions? Yes. One of your first slides, you compared startup time
20:22
and peak performance and like the raw dn.dev image was only about 50% of peak performance of OpenJDK. So is that really true? Like I knew that it's slower, like peak performance, but just 50% seems.
20:42
I don't, yeah, I don't remember exactly the numbers on there. The yellow and red. Yeah, so that, yeah, so the, yeah, yeah, definitely. So the peak throughput time, there was a slide about the three graphs.
21:03
So yeah, I think with the native compilation, you're not gonna have necessarily more throughputs than on the JVM, but you do get the startup time, you know, like the time it takes to get to the maximum throughput is faster
21:22
when you're native. I get it, but if I end up at just 50%, that's just not acceptable. Like if it's like 80, 90%, okay, that's fine. Yeah, yeah, yeah, we can look at it later, yeah. Yes.
21:46
So you read that how easy it will be to migrate for a JVM? Yeah, that's it. Sorry, the library is.
22:06
Yeah, so the question was how easy is it to migrate to Quarkus from, for example, spring boots? So Quarkus has spring compatibility extensions and so that makes it relatively easy
22:22
because basically you're, for the most part, you won't have to change your code. You just have to add the, you know, add the spring extensions. Of course, in your POM, you're gonna need to make some changes, but it's fairly straightforward.
22:40
My colleague, Eric DeAndrea, he wrote a book on spring, let's say, Quarkus for spring developers and he does, he talks too, but if you want on that developers.redhat.com, you can find, you know, there's a section about books and you can find that book,
23:02
but it's, yeah, overall pretty straightforward. So like I said, there are extensions so that you can keep using your spring annotations. Now, would I recommend you just migrating your application and keeping all your spring dependencies?
23:24
Probably not, but it's kind of a nice way to migrate without too much work and then afterwards maybe migrate further. Any more questions?
23:57
So the question, if I understand correctly, right?
24:01
So the question is, why should you use native compilation?
24:20
Because on the JVM, you have all the kind of capabilities that the JVM brings, right? So in terms of garbage collection, in terms of throughput and everything, JVM is very optimized to do that. When you do a native build,
24:43
the GraalVM compiler is gonna do kind of an opinionated approach of how to do your native build, but then that's also it. It's not gonna be able to optimize afterwards like the JVM does, so kind of depends, yeah. I think we're out of time, but if anybody has any more questions.
25:02
Yeah, yeah.