Slide 1
Slide 1 text
May 25, 2023
Cloud Native Development
with Quarkus
Holly Cummins
Red Hat
@holly_cummins
Slide 2
Slide 2 text
hi!
Slide 3
Slide 3 text
@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
Slide 4
Slide 4 text
@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
Slide 5
Slide 5 text
@holly_cummins #RedHat
how today works:
• I do
• We do
• You do
Slide 6
Slide 6 text
@holly_cummins #RedHat
how today works:
• I do
• We do
• You do
• I talk
Slide 7
Slide 7 text
@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?
Slide 8
Slide 8 text
@holly_cummins #RedHat
background check!
spring boot?
Slide 9
Slide 9 text
@holly_cummins #RedHat
https://developers.redhat.com/e-books/quarkus-spring-developers
Slide 10
Slide 10 text
@holly_cummins #RedHat
background check!
cdi?
Slide 11
Slide 11 text
@holly_cummins #RedHat
background check!
Slide 12
Slide 12 text
@holly_cummins #RedHat
background check!
cloud?
Slide 13
Slide 13 text
@holly_cummins #RedHat
background check!
cloud?
kubernetes?
Slide 14
Slide 14 text
@holly_cummins #RedHat
interest check!
test-driven-development?
Slide 15
Slide 15 text
@holly_cummins #RedHat
background check!
quarkus?
Slide 16
Slide 16 text
@holly_cummins #RedHat
interest check!
test-driven-development?
Slide 17
Slide 17 text
@holly_cummins #RedHat
background check!
reactive?
Slide 18
Slide 18 text
@holly_cummins #RedHat
interest check!
reactive?
Slide 19
Slide 19 text
@holly_cummins #RedHat
background check!
native?
Slide 20
Slide 20 text
@holly_cummins #RedHat
interest check!
native?
Slide 21
Slide 21 text
@holly_cummins #RedHat
background check!
quarkus?
Slide 22
Slide 22 text
quark-what?
Slide 23
Slide 23 text
@holly_cummins #RedHat
advantages of quarkus?
Slide 24
Slide 24 text
@holly_cummins #RedHat
disadvantages of quarkus?
Slide 25
Slide 25 text
$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
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
2000
RED HAT
LINUX
2007
KVM
2009
DEVOPS
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
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
Slide 30
Slide 30 text
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
Slide 31
Slide 31 text
Source: https://newrelic.com/resources/ebooks/serverless-benchmark-report-aws-lambda-2020
Languages used on AWS Lambda
38%
6%
Node.js
51%
Python
Java
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
Designed for
Throughput
Slide 34
Slide 34 text
Designed for
Throughput
At the expense
of footprint
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
Designed
to
be
long-running
Slide 37
Slide 37 text
Designed
to
be
long-running At the
expense
of startup
speed
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
Rich dynamic behavior
built for mutable
systems
Slide 40
Slide 40 text
Rich dynamic behavior
built for mutable
systems
Yet containers
are primarily
immutable
Slide 41
Slide 41 text
An Open Source
stack to write Java apps
Cloud Native Microservices Serverless
Slide 42
Slide 42 text
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
Slide 43
Slide 43 text
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
Slide 44
Slide 44 text
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
Slide 45
Slide 45 text
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/
Slide 46
Slide 46 text
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;
}
Slide 47
Slide 47 text
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
Slide 48
Slide 48 text
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
Slide 49
Slide 49 text
@
@
>
Packaging
(maven,
gradle…)
Build Time
Runtime
How does a framework start?
Slide 50
Slide 50 text
@
@
>
Load and parse config files,
properties, yaml, xml, etc.
Build Time
Runtime
How does a framework start?
Slide 51
Slide 51 text
@
@
>
Classpath scanning and
annotation discovery
Attempt to load class to
enable/disable features
Build Time
Runtime
How does a framework start?
Slide 52
Slide 52 text
@
@
>
Build its metamodel
of the world.
Build Time
Runtime
How does a framework start?
Slide 53
Slide 53 text
@
@
>
Start thread pools,
IO, etc.
Build Time
Runtime
How does a framework start?
Slide 54
Slide 54 text
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?
Slide 55
Slide 55 text
@
@
>
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?
Slide 56
Slide 56 text
@
@
>
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?
Slide 57
Slide 57 text
The Quarkus Way enables Native compilation
Native
@
@
>
JV
M
Build Time
Slide 58
Slide 58 text
The Traditional vs. Quarkus Ways
@
@
>
Build Time
Runtime
Slide 59
Slide 59 text
@
@
>
The Traditional vs. Quarkus Ways
@
@
>
Build Time
Runtime
Build Time
Slide 60
Slide 60 text
@
@
>
The Traditional vs. Quarkus Ways
@
@
>
Build Time
Runtime
Runtime
Build Time
Slide 61
Slide 61 text
demo
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
@holly_cummins #RedHat
a note on the localization
Slide 64
Slide 64 text
https://hollycummins.com/quarkus-workshops/
to the code!
Slide 65
Slide 65 text
how to be cloud native
Slide 66
Slide 66 text
@holly_cummins #RedHat
what is cloud native?
Slide 67
Slide 67 text
@holly_cummins #RedHat
what is cloud native?
Slide 68
Slide 68 text
@holly_cummins #RedHat
containers?
Slide 69
Slide 69 text
@holly_cummins #RedHat
microservices?
Slide 70
Slide 70 text
@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.
Slide 71
Slide 71 text
@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
Slide 72
Slide 72 text
@holly_cummins #RedHat
rapid release cadence
Slide 73
Slide 73 text
@holly_cummins #RedHat
independently deployable microservices
Slide 74
Slide 74 text
@holly_cummins #RedHat
how do you know if
you’re decoupled?
Slide 75
Slide 75 text
can you deploy
independently? v5.1.4
v5.1.4
v5.1.4
v5.1.4
Slide 76
Slide 76 text
can you deploy
independently? v6.2.8
v65.7
v5.1.4
v1.0.5
Slide 77
Slide 77 text
@holly_cummins #RedHat
can you deploy at all?
Slide 78
Slide 78 text
@holly_cummins #RedHat
confidence allows releasing
automation allows confidence
Slide 79
Slide 79 text
@holly_cummins #RedHat
cloud native is culture, not containers - or runtimes
Slide 80
Slide 80 text
TDD with Quarkus
Slide 81
Slide 81 text
@holly_cummins #RedHat
TDD
Slide 82
Slide 82 text
@holly_cummins #RedHat
TDD: improves quality
Slide 83
Slide 83 text
@holly_cummins #RedHat
TDD: an excellent design tool
Slide 84
Slide 84 text
@holly_cummins #RedHat
Slide 85
Slide 85 text
@holly_cummins #RedHat
the real reason to do TDD:
Slide 86
Slide 86 text
@holly_cummins #RedHat
the real reason to do TDD:
Slide 87
Slide 87 text
@holly_cummins #RedHat
the real reason to do TDD:
gamified testing
Slide 88
Slide 88 text
@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.!
Slide 89
Slide 89 text
the test pyramid and beyond
Slide 90
Slide 90 text
@holly_cummins #RedHat
the test
pyramid
Slide 91
Slide 91 text
@holly_cummins #RedHat
the test
pyramid
(you can TDD
at every level)
Slide 92
Slide 92 text
@holly_cummins #RedHat
the test
pyramid
Slide 93
Slide 93 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
Slide 94
Slide 94 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
integration tests
Slide 95
Slide 95 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
unit tests
integration tests
Slide 96
Slide 96 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
unit tests
integration tests
low effort
Slide 97
Slide 97 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
unit tests
integration tests
low effort
high realism
Slide 98
Slide 98 text
@holly_cummins #RedHat
the test
pyramid end-to-end tests
unit tests
integration tests
low effort
high realism
high value
Slide 99
Slide 99 text
@holly_cummins #RedHat
all models are wrong
some are useful
Slide 100
Slide 100 text
@holly_cummins #RedHat
tools
evolve end-to-end tests
unit tests
integration tests
low effort
high realism
Slide 101
Slide 101 text
@holly_cummins #RedHat
tools
evolve end-to-end tests
unit tests
integration tests
low effort
high realism
tests with
application
server
Slide 102
Slide 102 text
@holly_cummins #RedHat
tools
evolve end-to-end tests
unit tests
integration tests
low effort
high realism
tests with
application
server
test REST
endpoints
Slide 103
Slide 103 text
@holly_cummins #RedHat
tools
evolve end-to-end tests
unit tests
integration tests
low effort
high realism
tests with
application
server
test REST
endpoints
Slide 104
Slide 104 text
writing a Quarkus REST application
Slide 105
Slide 105 text
@holly_cummins #RedHat
https:/
/hollycummins.com/quarkus-workshops/#rest
Slide 106
Slide 106 text
persistence with hibernate and panache
Slide 107
Slide 107 text
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
Slide 108
Slide 108 text
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)
Slide 109
Slide 109 text
@holly_cummins #RedHat
https:/
/hollycummins.com/quarkus-workshops/#rest-transaction-orm
Slide 110
Slide 110 text
reactive programming
Slide 111
Slide 111 text
@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
Slide 112
Slide 112 text
@holly_cummins #RedHat
background check!
node.js?
Slide 113
Slide 113 text
@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!
Slide 114
Slide 114 text
@holly_cummins #RedHat
https:/
/hollycummins.com/quarkus-workshops/#reactive
Slide 115
Slide 115 text
microservices with Quarkus
Slide 116
Slide 116 text
@holly_cummins #RedHat
https:/
/hollycummins.com/quarkus-workshops/#microservices
Slide 117
Slide 117 text
contract testing
Slide 118
Slide 118 text
@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?”
Slide 119
Slide 119 text
@holly_cummins #RedHat
their code
our code
why unit tests
aren’t enough
Slide 120
Slide 120 text
@holly_cummins #RedHat
their code
our code
why mocks
aren’t enough
Slide 121
Slide 121 text
@holly_cummins #RedHat
their code
our code
why stubs
aren’t enough
Slide 122
Slide 122 text
@holly_cummins #RedHat
our code our mock
why mocks
aren’t enough
Slide 123
Slide 123 text
@holly_cummins #RedHat
our code our mock
tests ✔
why mocks
aren’t enough
Slide 124
Slide 124 text
@holly_cummins #RedHat
our code our mock
our code their actual code
tests ✔
why mocks
aren’t enough
Slide 125
Slide 125 text
@holly_cummins #RedHat
our code our mock
our code their actual code
tests ✔
reality ✘
why mocks
aren’t enough
Slide 126
Slide 126 text
@holly_cummins #RedHat
our code their code
why mocks aren’t
enough
Slide 127
Slide 127 text
@holly_cummins #RedHat
our code their code
contract test
why mocks aren’t
enough
Slide 128
Slide 128 text
@holly_cummins #RedHat
our code their code
contract test
mock
why mocks aren’t
enough
Slide 129
Slide 129 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
why mocks aren’t
enough
Slide 130
Slide 130 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
our tests ✔
their tests ✔
reality ✔
why mocks aren’t
enough
Slide 131
Slide 131 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
why mocks aren’t
enough
Slide 132
Slide 132 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
our tests ✔
their tests ✘
reality ✘
why mocks aren’t
enough
Slide 133
Slide 133 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
why mocks aren’t
enough
Slide 134
Slide 134 text
@holly_cummins #RedHat
our code their code
contract test
mock functional test
our tests ✘
their tests ✔
reality ✘
why mocks aren’t
enough
Slide 135
Slide 135 text
@holly_cummins #RedHat
Slide 136
Slide 136 text
@holly_cummins #RedHat
contract-first is a great way to TDD
Slide 137
Slide 137 text
@holly_cummins #RedHat
contract-first is a great way to TDD
(and a great design tool)
Slide 138
Slide 138 text
#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
Slide 139
Slide 139 text
@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
Slide 140
Slide 140 text
@holly_cummins #RedHat
contract testing options:
• pact.io
• spring contract
• OpenAPI schema validation + mock generation
• prism
• schemathesis
Slide 141
Slide 141 text
@holly_cummins #RedHat
pact can exercise
• input parameters
• state
Slide 142
Slide 142 text
@holly_cummins #RedHat
the story of the 204
Slide 143
Slide 143 text
@holly_cummins #RedHat
https:/
/hollycummins.com/quarkus-workshops/#contract-testing
Slide 144
Slide 144 text
deciding between native and java compilation
Slide 145
Slide 145 text
@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?
Slide 146
Slide 146 text
@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
Slide 147
Slide 147 text
@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
Slide 148
Slide 148 text
deploying Quarkus apps to Kubernetes
Slide 149
Slide 149 text
@holly_cummins #RedHat
• Kubernetes extension
• uses dekorate under the covers
• OpenShiftExtension
• s2i
Slide 150
Slide 150 text
@holly_cummins #RedHat
• Kubernetes extension
• uses dekorate under the covers
• OpenShiftExtension
• s2i
Slide 151
Slide 151 text
… so in conclusion
Slide 152
Slide 152 text
@holly_cummins #RedHat
what did we all think?
Slide 153
Slide 153 text
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
Slide 154
Slide 154 text
@holly_cummins #RedHat
https:/
/delawen.com/2022/07/bungee-jumping-into-quarkus/
the gotchas
Slide 155
Slide 155 text
@holly_cummins #RedHat
Slide 156
Slide 156 text
Continue your Journey
code.quarkus.io
red.ht/try-quarkus
red.ht/idc-quarkus-study
Slide 157
Slide 157 text
thank you
@holly_cummins
https://hollycummins.com/cloud-native-quarkus-workshop-goto-aarhus/