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

May 23, 2023
Tweet

More Decks by Holly Cummins

Other Decks in Programming

Transcript

  1. May 25, 2023


    Cloud Native Development
    with Quarkus


    Holly Cummins


    Red Hat


    @holly_cummins

    View Slide

  2. hi!

    View Slide

  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

    View Slide

  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

    View Slide

  5. @holly_cummins #RedHat
    how today works:
    • I do


    • We do


    • You do

    View Slide

  6. @holly_cummins #RedHat
    how today works:
    • I do


    • We do


    • You do
    • I talk

    View Slide

  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?

    View Slide

  8. @holly_cummins #RedHat
    background check!
    spring boot?

    View Slide

  9. @holly_cummins #RedHat
    https://developers.redhat.com/e-books/quarkus-spring-developers

    View Slide

  10. @holly_cummins #RedHat
    background check!
    cdi?

    View Slide

  11. @holly_cummins #RedHat
    background check!

    View Slide

  12. @holly_cummins #RedHat
    background check!
    cloud?

    View Slide

  13. @holly_cummins #RedHat
    background check!
    cloud?
    kubernetes?

    View Slide

  14. @holly_cummins #RedHat
    interest check!
    test-driven-development?

    View Slide

  15. @holly_cummins #RedHat
    background check!
    quarkus?

    View Slide

  16. @holly_cummins #RedHat
    interest check!
    test-driven-development?

    View Slide

  17. @holly_cummins #RedHat
    background check!
    reactive?

    View Slide

  18. @holly_cummins #RedHat
    interest check!
    reactive?

    View Slide

  19. @holly_cummins #RedHat
    background check!
    native?

    View Slide

  20. @holly_cummins #RedHat
    interest check!
    native?

    View Slide

  21. @holly_cummins #RedHat
    background check!
    quarkus?

    View Slide

  22. quark-what?

    View Slide

  23. @holly_cummins #RedHat
    advantages of quarkus?

    View Slide

  24. @holly_cummins #RedHat
    disadvantages of quarkus?

    View Slide

  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

    View Slide

  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

    View Slide

  27. 2000
    RED HAT
    LINUX
    2007
    KVM
    2009
    DEVOPS

    View Slide

  28. View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  32. View Slide

  33. Designed for
    Throughput

    View Slide

  34. Designed for
    Throughput
    At the expense
    of footprint

    View Slide

  35. View Slide

  36. Designed
    to
    be
    long-running

    View Slide

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

    View Slide

  38. View Slide

  39. Rich dynamic behavior
    built for mutable
    systems

    View Slide

  40. Rich dynamic behavior
    built for mutable
    systems
    Yet containers
    are primarily
    immutable

    View Slide

  41. An Open Source


    stack to write Java apps
    Cloud Native Microservices Serverless

    View Slide

  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

    View Slide

  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


    View Slide

  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

    View Slide

  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/

    View Slide

  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 reactiveSay;
    @GET
    @Produces(MediaType.SERVER_SENT_EVENTS)
    public Publisher stream() {
    return reactiveSay;
    }

    View Slide

  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

    View Slide

  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

    View Slide

  49. @

    @
    >
    Packaging

    (maven,
    gradle…)
    Build Time
    Runtime
    How does a framework start?

    View Slide

  50. @

    @
    >
    Load and parse config files,
    properties, yaml, xml, etc.
    Build Time
    Runtime
    How does a framework start?

    View Slide

  51. @

    @
    >
    Classpath scanning and
    annotation discovery
    Attempt to load class to
    enable/disable features
    Build Time
    Runtime
    How does a framework start?

    View Slide

  52. @

    @
    >
    Build its metamodel
    of the world.
    Build Time
    Runtime
    How does a framework start?

    View Slide

  53. @

    @
    >
    Start thread pools,
    IO, etc.
    Build Time
    Runtime
    How does a framework start?

    View Slide

  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?

    View Slide

  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?

    View Slide

  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?

    View Slide

  57. The Quarkus Way enables Native compilation
    Native
    @

    @
    >
    JV
    M
    Build Time

    View Slide

  58. The Traditional vs. Quarkus Ways
    @

    @
    >
    Build Time
    Runtime

    View Slide

  59. @

    @
    >
    The Traditional vs. Quarkus Ways
    @

    @
    >
    Build Time
    Runtime
    Build Time

    View Slide

  60. @

    @
    >
    The Traditional vs. Quarkus Ways
    @

    @
    >
    Build Time
    Runtime
    Runtime
    Build Time

    View Slide

  61. demo

    View Slide

  62. View Slide

  63. @holly_cummins #RedHat
    a note on the localization

    View Slide

  64. https://hollycummins.com/quarkus-workshops/
    to the code!

    View Slide

  65. how to be cloud native

    View Slide

  66. @holly_cummins #RedHat
    what is cloud native?

    View Slide

  67. @holly_cummins #RedHat
    what is cloud native?

    View Slide

  68. @holly_cummins #RedHat
    containers?

    View Slide

  69. @holly_cummins #RedHat
    microservices?

    View Slide

  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.

    View Slide

  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

    View Slide

  72. @holly_cummins #RedHat
    rapid release cadence

    View Slide

  73. @holly_cummins #RedHat
    independently deployable microservices

    View Slide

  74. @holly_cummins #RedHat
    how do you know if
    you’re decoupled?

    View Slide

  75. can you deploy
    independently? v5.1.4
    v5.1.4
    v5.1.4
    v5.1.4

    View Slide

  76. can you deploy
    independently? v6.2.8
    v65.7
    v5.1.4
    v1.0.5

    View Slide

  77. @holly_cummins #RedHat
    can you deploy at all?

    View Slide

  78. @holly_cummins #RedHat
    confidence allows releasing


    automation allows confidence

    View Slide

  79. @holly_cummins #RedHat
    cloud native is culture, not containers - or runtimes

    View Slide

  80. TDD with Quarkus

    View Slide

  81. @holly_cummins #RedHat
    TDD

    View Slide

  82. @holly_cummins #RedHat
    TDD: improves quality

    View Slide

  83. @holly_cummins #RedHat
    TDD: an excellent design tool

    View Slide

  84. @holly_cummins #RedHat

    View Slide

  85. @holly_cummins #RedHat
    the real reason to do TDD:

    View Slide

  86. @holly_cummins #RedHat
    the real reason to do TDD:

    View Slide

  87. @holly_cummins #RedHat
    the real reason to do TDD:
    gamified testing

    View Slide

  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.!

    View Slide

  89. the test pyramid and beyond

    View Slide

  90. @holly_cummins #RedHat
    the test
    pyramid

    View Slide

  91. @holly_cummins #RedHat
    the test
    pyramid
    (you can TDD
    at every level)

    View Slide

  92. @holly_cummins #RedHat
    the test
    pyramid

    View Slide

  93. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests

    View Slide

  94. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests
    integration tests

    View Slide

  95. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests
    unit tests
    integration tests

    View Slide

  96. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests
    unit tests
    integration tests
    low effort

    View Slide

  97. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests
    unit tests
    integration tests
    low effort
    high realism

    View Slide

  98. @holly_cummins #RedHat
    the test
    pyramid end-to-end tests
    unit tests
    integration tests
    low effort
    high realism
    high value

    View Slide

  99. @holly_cummins #RedHat
    all models are wrong


    some are useful

    View Slide

  100. @holly_cummins #RedHat
    tools
    evolve end-to-end tests
    unit tests
    integration tests
    low effort
    high realism

    View Slide

  101. @holly_cummins #RedHat
    tools
    evolve end-to-end tests
    unit tests
    integration tests
    low effort
    high realism
    tests with
    application
    server

    View Slide

  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

    View Slide

  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

    View Slide

  104. writing a Quarkus REST application

    View Slide

  105. @holly_cummins #RedHat
    https:/
    /hollycummins.com/quarkus-workshops/#rest

    View Slide

  106. persistence with hibernate and panache

    View Slide

  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 search(String query) {
    return list("completed = ?1 and title like ?2", false, query);
    }
    public static List findNotCompleted() {
    return list("completed", false);
    }
    public static long deleteCompleted() {
    return delete("completed", true);
    }
    }
    Define entity with Panache

    View Slide

  108. 80
    @GET
    public List getAll() {
    return Todo.listAll(Sort.by("order"));
    }
    @POST @Transactional
    public void addTodo(@Valid Todo todo) {
    return todo.persist();
    }
    @GET @Path("/search/{query}")
    public List search(@PathParam("query") @NotBlank String query) {
    return Todo.search(query);
    }
    Accessing entities with Panache
    Convenient methods for lazy people
    (aka good devs)

    View Slide

  109. @holly_cummins #RedHat
    https:/
    /hollycummins.com/quarkus-workshops/#rest-transaction-orm

    View Slide

  110. reactive programming

    View Slide

  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

    View Slide

  112. @holly_cummins #RedHat
    background check!
    node.js?

    View Slide

  113. @holly_cummins #RedHat
    Uni
    • 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!

    View Slide

  114. @holly_cummins #RedHat
    https:/
    /hollycummins.com/quarkus-workshops/#reactive

    View Slide

  115. microservices with Quarkus

    View Slide

  116. @holly_cummins #RedHat
    https:/
    /hollycummins.com/quarkus-workshops/#microservices

    View Slide

  117. contract testing

    View Slide

  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?”

    View Slide

  119. @holly_cummins #RedHat
    their code
    our code
    why unit tests
    aren’t enough

    View Slide

  120. @holly_cummins #RedHat
    their code
    our code
    why mocks
    aren’t enough

    View Slide

  121. @holly_cummins #RedHat
    their code
    our code
    why stubs
    aren’t enough

    View Slide

  122. @holly_cummins #RedHat
    our code our mock
    why mocks
    aren’t enough

    View Slide

  123. @holly_cummins #RedHat
    our code our mock
    tests ✔


    why mocks
    aren’t enough

    View Slide

  124. @holly_cummins #RedHat
    our code our mock
    our code their actual code
    tests ✔


    why mocks
    aren’t enough

    View Slide

  125. @holly_cummins #RedHat
    our code our mock
    our code their actual code
    tests ✔


    reality ✘
    why mocks
    aren’t enough

    View Slide

  126. @holly_cummins #RedHat
    our code their code
    why mocks aren’t
    enough

    View Slide

  127. @holly_cummins #RedHat
    our code their code
    contract test
    why mocks aren’t
    enough

    View Slide

  128. @holly_cummins #RedHat
    our code their code
    contract test
    mock
    why mocks aren’t
    enough

    View Slide

  129. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    why mocks aren’t
    enough

    View Slide

  130. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    our tests ✔


    their tests ✔


    reality ✔


    why mocks aren’t
    enough

    View Slide

  131. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    why mocks aren’t
    enough

    View Slide

  132. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    our tests ✔


    their tests ✘


    reality ✘


    why mocks aren’t
    enough

    View Slide

  133. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    why mocks aren’t
    enough

    View Slide

  134. @holly_cummins #RedHat
    our code their code
    contract test
    mock functional test
    our tests ✘


    their tests ✔


    reality ✘


    why mocks aren’t
    enough

    View Slide

  135. @holly_cummins #RedHat

    View Slide

  136. @holly_cummins #RedHat
    contract-first is a great way to TDD

    View Slide

  137. @holly_cummins #RedHat
    contract-first is a great way to TDD
    (and a great design tool)

    View Slide

  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

    View Slide

  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

    View Slide

  140. @holly_cummins #RedHat
    contract testing options:


    • pact.io


    • spring contract


    • OpenAPI schema validation + mock generation


    • prism


    • schemathesis

    View Slide

  141. @holly_cummins #RedHat
    pact can exercise


    • input parameters


    • state

    View Slide

  142. @holly_cummins #RedHat
    the story of the 204

    View Slide

  143. @holly_cummins #RedHat
    https:/
    /hollycummins.com/quarkus-workshops/#contract-testing

    View Slide

  144. deciding between native and java compilation

    View Slide

  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?

    View Slide

  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

    View Slide

  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

    View Slide

  148. deploying Quarkus apps to Kubernetes


    View Slide

  149. @holly_cummins #RedHat
    • Kubernetes extension


    • uses dekorate under the covers


    • OpenShiftExtension


    • s2i

    View Slide

  150. @holly_cummins #RedHat
    • Kubernetes extension


    • uses dekorate under the covers


    • OpenShiftExtension


    • s2i

    View Slide

  151. … so in conclusion


    View Slide

  152. @holly_cummins #RedHat
    what did we all think?

    View Slide

  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

    View Slide

  154. @holly_cummins #RedHat
    https:/
    /delawen.com/2022/07/bungee-jumping-into-quarkus/
    the gotchas

    View Slide

  155. @holly_cummins #RedHat

    View Slide

  156. Continue your Journey
    code.quarkus.io
    red.ht/try-quarkus
    red.ht/idc-quarkus-study

    View Slide

  157. thank you


    @holly_cummins
    https://hollycummins.com/cloud-native-quarkus-workshop-goto-aarhus/

    View Slide