Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cloud Native Development With Quarkus (GOTO masterclass)

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

Holly Cummins

October 14, 2022
Tweet

More Decks by Holly Cummins

Other Decks in Programming

Transcript

  1. October 7, 2022 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

  28. None
  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
  32. None
  33. Designed for Throughput

  34. Designed for Throughput At the expense of footprint

  35. None
  36. Designed to be long-running

  37. Designed to be long-running At the expense of startup speed

  38. None
  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

  62. None
  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-copenhagen/