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/