Cloud Native Development With Quarkus (GOTO masterclass)

Cloud native development means running on the cloud (obviously), releasing on a rapid cadence, and automated testing, so that you have the confidence to release often. Traditional Java didn’t make this particularly easy, but Quarkus does.

This masterclass introduces Quarkus, and shows how develop, test, and deploy a microservices application. Along the way we’ll cover TDD with Quarkus, contract testing, developer services, REST applications, Hibernate and persistence, authentication with JWT and keycloak, native compilation, GraalVM, packaging, troubleshooting, how to integrate with Kubernetes, health checks, metrics, and observability. If time permits, we will cover custom extensions and reactive programming.

Here’s what you’ll learn:

How to be cloud native

The test pyramid and beyond

TDD with Quarkus

Writing a Quarkus REST application

Persistence with Hibernate and Panache

Microservices with Quarkus

JWT and Keycloak

Deciding between native and Java compilation

Deploying Quarkus apps to Kubernetes

Troubleshooting + observability

Transcript

1. May 25, 2023 Cloud Native Development with Quarkus Holly Cummins Red Hat @holly_cummins
2. hi!
3. @holly_cummins #RedHat how today works: 08:00: Registration and breakfast 
 09:00: Masterclass starts 
 10:30-10:45: Coffee break 
 12:00-13:00: Lunch 
 14:30-14:45: Coffee break 
 16:00: Masterclass ends
4. @holly_cummins #RedHat how today works: • Quark-what? • How to be cloud native • The test pyramid and beyond • TDD with Quarkus • Writing a Quarkus REST application • Persistence with Hibernate and Panache • Microservices with Quarkus • Contract testing • JWT and Keycloak • Deciding between native and Java compilation • Deploying Quarkus apps to Kubernetes • Troubleshooting + observability • Q&A + wrap up + retrospective
5. @holly_cummins #RedHat how today works: • I do • We do • You do
6. @holly_cummins #RedHat how today works: • I do • We do • You do • I talk
7. @holly_cummins #RedHat who are you? • what’s your name? • who do you work for? • what’s your role? • what’s in your tech stack?
8. @holly_cummins #RedHat background check! spring boot?
9. @holly_cummins #RedHat https://developers.redhat.com/e-books/quarkus-spring-developers
10. @holly_cummins #RedHat background check! cdi?
11. @holly_cummins #RedHat background check!
12. @holly_cummins #RedHat background check! cloud?
13. @holly_cummins #RedHat background check! cloud? kubernetes?
14. @holly_cummins #RedHat interest check! test-driven-development?
15. @holly_cummins #RedHat background check! quarkus?
16. @holly_cummins #RedHat interest check! test-driven-development?
17. @holly_cummins #RedHat background check! reactive?
18. @holly_cummins #RedHat interest check! reactive?
19. @holly_cummins #RedHat background check! native?
20. @holly_cummins #RedHat interest check! native?
21. @holly_cummins #RedHat background check! quarkus?
22. quark-what?
23. @holly_cummins #RedHat advantages of quarkus?
24. @holly_cummins #RedHat disadvantages of quarkus?
25. $18,000 Sun Sparc App Server Box (4 CPUs, 2GB of RAM) + $60,000 BEA Weblogic + $92,000 Sun Sparc DB Server Box (8 CPUs) + $243,000 Oracle RDBMS + $50,000 Symantec Visual Café for 10 developers -------------------------------------------------- $463,000 (capex) + ~$80,000 annual maint (opex) Cost of a Java-based Web App circa 1999
26. Historical Enterprise Java Stack Operating System + Hardware/VM Java Virtual Machine (Hotspot) Application Server App App App App App Dynamic Application Frameworks Architecture: Monoliths 
 
 Deployment: multi-app, 
 appserver App Lifecycle: Months Memory: 1GB+ RAM Startup Time: 10s of sec
27. 2000 RED HAT LINUX 2007 KVM 2009 DEVOPS
29. Modern Enterprise Java Stack Java Virtual Machine (Hotspot) Application Server App Dynamic Application Frameworks Architecture: Microservices 
 
 Deployment: Single App 
 
 App Lifecycle: Days Memory: 100 MB + RAM Startup Time: Seconds No Change QUARKUS WORKSHOP
30. Quarkus - Optimizing the Stack Java Virtual Machine (Hotspot) App (Imperative / Reactive) Optimized Application Frameworks Architecture: Microservices, 
 Serverless 
 
 Deployment: Single App 
 
 App Lifecycle: Minutes/Days Memory: 10 MBs + RAM Startup Time: Milliseconds Optional QUARKUS WORKSHOP
31. Source: https://newrelic.com/resources/ebooks/serverless-benchmark-report-aws-lambda-2020 Languages used on AWS Lambda 38% 6% Node.js 51% Python Java
33. Designed for Throughput
34. Designed for Throughput At the expense of footprint
36. Designed to be long-running
37. Designed to be long-running At the expense of startup speed
39. Rich dynamic behavior built for mutable systems
40. Rich dynamic behavior built for mutable systems Yet containers are primarily immutable
41. An Open Source stack to write Java apps Cloud Native Microservices Serverless
42. Kubernetes-Native Development with Quarkus Solid Foundation Java consistently ranks in the Top 3 of programming languages in use today with a community of 7-10 million developers. Stunning Performance Optimized to provide native-level memory footprint and startup time, allowing for increased density, performance and elasticity at lower cost. Toolchain End-to-end toolchain including OpenShift Developer Console, Code Ready Workspaces, project generators in IDE and web, live- reload for lightning fast inner loop workflow, and CI/CD integration. Community Massive catalog of extensions connects your applications with best of breed-technologies including Camel, Jaeger, Prometheus, Istio, Kafka and more. TIOBE : #1 IEEE : #1 SlashData : #2 RedMonk : #2
43. Quarkus Brings Real Developer Joy A cohesive platform for optimized developer joy: • Based on standards, but not limited • Unified configuration • Reactive & Imperative, all in one • Zero config, live reload in the blink of an eye • Streamlined code for the 80% common usages, flexible for the 20% • No hassle native executable generation
44. Quarkus + GraalVM 13 MB Quarkus + OpenJDK 74 MB Traditional Cloud-Native Stack 140 MB REST https://quarkus.io/blog/runtime-performance/ Quarkus Improves Memory Utilization
45. Quarkus Improves Startup Time Quarkus + GraalVM 0.014 Seconds REST REST + CRUD Quarkus + OpenJDK 0.75 Seconds Quarkus + GraalVM 0.055 Seconds Quarkus + OpenJDK 2.5 Seconds Traditional Cloud-Native Stack 9.5 Seconds Traditional Cloud-Native Stack 4.3 Seconds https://quarkus.io/blog/runtime-performance/
46. Quarkus Unifies Imperative and Reactive • Combines both Reactive and imperative development in the same application • Reactive Messaging - Apache Kafka, MQTT, AMQP… • Reactive Services @Inject SayService say; @GET @Produces(MediaType.TEXT_PLAIN) public String hello() { return say.hello(); } @Inject @Stream(”kafka”) Publisher<String> reactiveSay; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Publisher<String> stream() { return reactiveSay; }
47. Quarkus uses Best of Breed Frameworks & Standards Eclipse Vert.x Hibernate RESTEasy Apache Camel Eclipse MicroProfile Netty Kubernetes OpenShift Jaeger Prometheus Apache Kafka Infinispan Flyway Neo4j MongoDB MQTT KeyCloak Apache Tika
48. 40 They load way too many classes They are way too dynamic / reflective They perform a lot of initialization at Runtime What is Wrong with Java Frameworks
49. @
 @ </> Packaging
 (maven, gradle…) Build Time Runtime How does a framework start?
50. @
 @ </> Load and parse config files, properties, yaml, xml, etc. Build Time Runtime How does a framework start?
51. @
 @ </> Classpath scanning and annotation discovery Attempt to load class to enable/disable features Build Time Runtime How does a framework start?
52. @
 @ </> Build its metamodel of the world. Build Time Runtime How does a framework start?
53. @
 @ </> Start thread pools, IO, etc. Build Time Runtime How does a framework start?
54. Do the work once, not at each start Get rid of all bootstrap classes Less time to start, less memory needed Less or no reflection nor dynamic proxies What if we Initialize at Build time?
55. @
 @ </> Build Time Do the work once, not at each start Get rid of all bootstrap classes Less time to start, less memory needed Less or no reflection nor dynamic proxies What if we Initialize at Build time?
56. @
 @ </> Runtime Build Time Do the work once, not at each start Get rid of all bootstrap classes Less time to start, less memory needed Less or no reflection nor dynamic proxies What if we Initialize at Build time?
57. The Quarkus Way enables Native compilation Native @
 @ </> JV M Build Time
58. The Traditional vs. Quarkus Ways @
 @ </> Build Time Runtime
59. @
 @ </> The Traditional vs. Quarkus Ways @
 @ </> Build Time Runtime Build Time
60. @
 @ </> The Traditional vs. Quarkus Ways @
 @ </> Build Time Runtime Runtime Build Time
61. demo
63. @holly_cummins #RedHat a note on the localization
64. https://hollycummins.com/quarkus-workshops/ to the code!
65. how to be cloud native
66. @holly_cummins #RedHat what is cloud native?
67. @holly_cummins #RedHat what is cloud native?
68. @holly_cummins #RedHat containers?
69. @holly_cummins #RedHat microservices?
70. @holly_cummins #RedHat Capabilities of a Cloud Native Application Architectures? The benefits of cloud native application architectures enable speed of development and deployment, flexibility, quality, and reliability. More importantly, it allows developers to integrate the applications with the latest open source technologies without a steep learning curve. While there are many ways to build and architect cloud native applications following are some great ingredients for consideration: • Runtimes - More likely to be written in the container first or/and Kubernetes native language, which means runtimes such as Java, Node.js, Go, Python, and Ruby, etc. • Security - Deploying and maintaining applications in a multi cloud, hybrid cloud application environment, security becomes of utmost importance and should be part of the environment. • Observability - The ability to observer applications and their behavior in the cloud. Tools that can give realtime metrics, and more information about the use e.g., Prometheus, Grafana, Kiali, etc. • Efficiency - Focused on tiny memory footprint, small artifact size, and fast booting time to make portable applications across hybrid/multi-cloud platforms. Primarily, it will leverage an expected spice in production via rapid scaling with consuming minimal computing resources. • Interoperability - Easy to integrate cloud native apps with the latest open source technologies such as Infinispan, MicroProfile, Hibernate, Apache Kafka, Jaeger, Prometheus, and more for building standard runtimes architecture. • DevOps/DevSecOps - Designed for continuous deployment to production in line with the minimum viable product (MVP), with security as part of the tooling together with development, automating testing, and collaboration.
71. @holly_cummins #RedHat Capabilities of a Cloud Native Application Architectures? The benefits of cloud native application architectures enable speed of development and deployment, flexibility, quality, and reliability. More importantly, it allows developers to integrate the applications with the latest open source technologies without a steep learning curve. While there are many ways to build and architect cloud native applications following are some great ingredients for consideration: • Runtimes - More likely to be written in the container first or/and Kubernetes native language, which means runtimes such as Java, Node.js, Go, Python, and Ruby, etc. • Security - Deploying and maintaining applications in a multi cloud, hybrid cloud application environment, security becomes of utmost importance and should be part of the environment. • Observability - The ability to observer applications and their behavior in the cloud. Tools that can give realtime metrics, and more information about the use e.g., Prometheus, Grafana, Kiali, etc. • Efficiency - Focused on tiny memory footprint, small artifact size, and fast booting time to make portable applications across hybrid/multi-cloud platforms. Primarily, it will leverage an expected spice in production via rapid scaling with consuming minimal computing resources. • Interoperability - Easy to integrate cloud native apps with the latest open source technologies such as Infinispan, MicroProfile, Hibernate, Apache Kafka, Jaeger, Prometheus, and more for building standard runtimes architecture. • DevOps/DevSecOps - Designed for continuous deployment to production in line with the minimum viable product (MVP), with security as part of the tooling together with development, automating testing, and collaboration. lots of words
72. @holly_cummins #RedHat rapid release cadence
73. @holly_cummins #RedHat independently deployable microservices
74. @holly_cummins #RedHat how do you know if you’re decoupled?
75. can you deploy independently? v5.1.4 v5.1.4 v5.1.4 v5.1.4
76. can you deploy independently? v6.2.8 v65.7 v5.1.4 v1.0.5
77. @holly_cummins #RedHat can you deploy at all?
78. @holly_cummins #RedHat confidence allows releasing automation allows confidence
79. @holly_cummins #RedHat cloud native is culture, not containers - or runtimes
80. TDD with Quarkus
81. @holly_cummins #RedHat TDD
82. @holly_cummins #RedHat TDD: improves quality
83. @holly_cummins #RedHat TDD: an excellent design tool
84. @holly_cummins #RedHat
85. @holly_cummins #RedHat the real reason to do TDD:
86. @holly_cummins #RedHat the real reason to do TDD:
87. @holly_cummins #RedHat the real reason to do TDD: gamified testing
88. @holly_cummins #RedHat the first module has TDD instructions the rest do not challenge in each module, scroll forward, find the tests, and work backwards.!
89. the test pyramid and beyond
90. @holly_cummins #RedHat the test pyramid
91. @holly_cummins #RedHat the test pyramid (you can TDD at every level)
92. @holly_cummins #RedHat the test pyramid
93. @holly_cummins #RedHat the test pyramid end-to-end tests
94. @holly_cummins #RedHat the test pyramid end-to-end tests integration tests
95. @holly_cummins #RedHat the test pyramid end-to-end tests unit tests integration tests
96. @holly_cummins #RedHat the test pyramid end-to-end tests unit tests integration tests low effort
97. @holly_cummins #RedHat the test pyramid end-to-end tests unit tests integration tests low effort high realism
98. @holly_cummins #RedHat the test pyramid end-to-end tests unit tests integration tests low effort high realism high value
99. @holly_cummins #RedHat all models are wrong some are useful
100. @holly_cummins #RedHat tools evolve end-to-end tests unit tests integration tests low effort high realism
101. @holly_cummins #RedHat tools evolve end-to-end tests unit tests integration tests low effort high realism tests with application server
102. @holly_cummins #RedHat tools evolve end-to-end tests unit tests integration tests low effort high realism tests with application server test REST endpoints
103. @holly_cummins #RedHat tools evolve end-to-end tests unit tests integration tests low effort high realism tests with application server test REST endpoints
104. writing a Quarkus REST application
105. @holly_cummins #RedHat https:/ /hollycummins.com/quarkus-workshops/#rest
106. persistence with hibernate and panache
107. 79 @Entity public class Todo extends PanacheEntity { // id is inherited public String title; public boolean completed; public String url; @Column(name = "ordering") public int order; public static List<Todo> search(String query) { return list("completed = ?1 and title like ?2", false, query); } public static List<Todo> findNotCompleted() { return list("completed", false); } public static long deleteCompleted() { return delete("completed", true); } } Define entity with Panache
108. 80 @GET public List<Todo> getAll() { return Todo.listAll(Sort.by("order")); } @POST @Transactional public void addTodo(@Valid Todo todo) { return todo.persist(); } @GET @Path("/search/{query}") public List<Todo> search(@PathParam("query") @NotBlank String query) { return Todo.search(query); } Accessing entities with Panache Convenient methods for lazy people (aka good devs)
109. @holly_cummins #RedHat https:/ /hollycummins.com/quarkus-workshops/#rest-transaction-orm
110. reactive programming
111. @holly_cummins #RedHat quarkus supports both blocking and reactive • it easier to become blocking on a reactive core than to become non- blocking on a blocking core
112. @holly_cummins #RedHat background check! node.js?
113. @holly_cummins #RedHat Uni<Something> • returning a Uni makes a method non- blocking* • a Uni is like a node.js promise • Unis mix nicely with lamdas for chaining • you can mix blocking and non-blocking in an application, but be careful how finely you mix * there are limitations - you can get some subtle bugs!
114. @holly_cummins #RedHat https:/ /hollycummins.com/quarkus-workshops/#reactive
115. microservices with Quarkus
116. @holly_cummins #RedHat https:/ /hollycummins.com/quarkus-workshops/#microservices
117. contract testing
118. @holly_cummins #RedHat the limitations of unit tests “why do my colleagues tell me my code is broken, even though my unit tests all pass?”
119. @holly_cummins #RedHat their code our code why unit tests aren’t enough
120. @holly_cummins #RedHat their code our code why mocks aren’t enough
121. @holly_cummins #RedHat their code our code why stubs aren’t enough
122. @holly_cummins #RedHat our code our mock why mocks aren’t enough
123. @holly_cummins #RedHat our code our mock tests ✔ why mocks aren’t enough
124. @holly_cummins #RedHat our code our mock our code their actual code tests ✔ why mocks aren’t enough
125. @holly_cummins #RedHat our code our mock our code their actual code tests ✔ reality ✘ why mocks aren’t enough
126. @holly_cummins #RedHat our code their code why mocks aren’t enough
127. @holly_cummins #RedHat our code their code contract test why mocks aren’t enough
128. @holly_cummins #RedHat our code their code contract test mock why mocks aren’t enough
129. @holly_cummins #RedHat our code their code contract test mock functional test why mocks aren’t enough
130. @holly_cummins #RedHat our code their code contract test mock functional test our tests ✔ their tests ✔ reality ✔ why mocks aren’t enough
131. @holly_cummins #RedHat our code their code contract test mock functional test why mocks aren’t enough
132. @holly_cummins #RedHat our code their code contract test mock functional test our tests ✔ their tests ✘ reality ✘ why mocks aren’t enough
133. @holly_cummins #RedHat our code their code contract test mock functional test why mocks aren’t enough
134. @holly_cummins #RedHat our code their code contract test mock functional test our tests ✘ their tests ✔ reality ✘ why mocks aren’t enough
135. @holly_cummins #RedHat
136. @holly_cummins #RedHat contract-first is a great way to TDD
137. @holly_cummins #RedHat contract-first is a great way to TDD (and a great design tool)
138. #RedHat @holly_cummins • consumer-driven contract testing can save your bacon • pact is a mock for the consumer • pact is a functional test for the producer • shared json contracts aligns expectations across services
139. @holly_cummins #RedHat pitfalls of contract testing: • we have to talk to the other team • our consumers can break our CI?! • versions • pact is hard to grok • testing the mock • but I’ve invested in wiremock • duplicated tests is overhead
140. @holly_cummins #RedHat contract testing options: • pact.io • spring contract • OpenAPI schema validation + mock generation • prism • schemathesis
141. @holly_cummins #RedHat pact can exercise • input parameters • state
142. @holly_cummins #RedHat the story of the 204
143. @holly_cummins #RedHat https:/ /hollycummins.com/quarkus-workshops/#contract-testing
144. deciding between native and java compilation
145. @holly_cummins #RedHat use case for native • low workload (so throughput isn’t the bottleneck) • resource-constrained or old hardware (especially memory) • high re-deploy rate (applications never get warmed up before being spun down) • serverless (of course) 
 use case for JVM • high workload (you need lots of throughput) • long-lived processes (the rapid start of native doesn’t save you much over the lifetime) • stable workload or very little elasticity in underlying orchestration is native better?
146. @holly_cummins #RedHat is there a sustainability aspect? yes … and it’s just as depend-y! optimising • cost • application performance will also be optimising carbon
147. @holly_cummins #RedHat native vs JVM is not an either-or • consider hybrid deployment models • a strength of Quarkus is application code is the same for native and JVM
148. deploying Quarkus apps to Kubernetes
149. @holly_cummins #RedHat • Kubernetes extension • uses dekorate under the covers • OpenShiftExtension • s2i
150. @holly_cummins #RedHat • Kubernetes extension • uses dekorate under the covers • OpenShiftExtension • s2i
151. … so in conclusion
152. @holly_cummins #RedHat what did we all think?
153. Customers using Quarkus Today “We could run 3 times denser deployments without sacrificing availability and response times of service” “When you adopt Quarkus, you will be productive from day one since you don’t really need to learn new technologies.” “Quarkus seemed to provide the performance boost we needed while at the same time having a good backer (Red Hat) and relying on battle- tested technologies” Thorsten Pohl Lufthansa Technik AVIATAR Product Owner Automation & Platform Architect Roberto Cortez Talkdesk Principal Architect Christos Sotiriou DXL technical lead at Vodafone Greece
154. @holly_cummins #RedHat https:/ /delawen.com/2022/07/bungee-jumping-into-quarkus/ the gotchas
155. @holly_cummins #RedHat
156. Continue your Journey code.quarkus.io red.ht/try-quarkus red.ht/idc-quarkus-study
157. thank you @holly_cummins https://hollycummins.com/cloud-native-quarkus-workshop-goto-aarhus/