Join Red Hat and Vodafone for an exciting presentation on the benefits of Quarkus over competing technologies. Hear from Vodafone's experts about their successful transition to Quarkus from Spring and discover how Quarkus can help your organization cut cloud costs, improve cluster stability, and achieve better performance. A live demo will showcase the power of Quarkus through examples of HTTP requests, security approaches, exception handling, logging, and more. In summary, this informative session will provide you valuable insights into the benefits of using Quarkus while also getting real world performance and development time numbers from Vodafone, information which can and should influence your next decisions on what Server Side Java technology to choose!

1. Battle of the frameworks : Quarkus
vs SpringBoot

2. C1 Public
2
Introduction
Georgios Andrianakis
Princpal Software Engineer
Red Hat
Christos Sotiriou
Principal Architect, Platforms Design
Vodafone

3. C1 Public
3
• Quarkus 3.0 released!
• Expands on the existing State Of The Art infrastructure
with performance improvements and new features
– Hibernate ORM 6.2
– New Dev UI
– Management interface
– Redis Cache
– Info endpoint
– Pact integration
• Java 11 and 17
• Jakarta EE APIs and Microprofile 6
• Perfect blending of Reactive and Imperative worlds
Red Hat Quarkus: Current state

4. C1 Public
4
• DXL – Digital eXperience Layer
– The backbone of Vodafone’s modern digital services
– Intended as a caching, high-performance middleware, but then it grew
• 160+ Microservices
– Reactive programming model
• AWS hosting
• Initially in Spring, switched early to Quarkus in 2019
– Also examined NodeJS, GoLand, plain Vert.x
• DXL’s missions: Sheer API Performance and feature deliverability
– Goal: 2.5 secs max API latency, previously some API calls would take 30 seconds
– Achievent: 529ms average API latency
Vodafone Greece: Current state

5. C1 Public
5
Modern microservices middleware requirements
Caching (DDS)
Data holder File Management
Payments
Content
• Enterprize integration
– SOAP messages as well as REST
– Fault Tolerance, high resilience
– Config-first approach (12-factor
applications)
– Built to handle potentially big payloads
• High Throughput, low boot times
• Integration with cloud-native and
modern systems
– REST apis, MongoDB, Kubernetes, Kafka,
Redis, etc
• Fast development times
– Good programming models, and integration
with reactive frameworks
• Initially chose Spring, moved to
Quarkus in March 2019

6. C1 Public
6
A short story
January 2020 refactored
MyVodafone app release:
- Campaign released pointing
users to the new app.
- Response times suddenly
peaked to ~50 seconds.
One microservice was overloaded.
Quarkus
Deployment
Spring Boot (MVC):
● 800 MB RAM
● 500 mCPUs
● Boot time: 40 seconds
● 2 - 12 replicas
Slow boot times (40 seconds)
resulted in slow auto-scaling in
production.
Quarkus (plain RESTEasy, non-reactice)
● 360 MB RAM
● 300 mCPUs
● Boot time: 12 seconds
● 2-4 replicas
Faster boot times, resulted in a healthier
cluster

7. Performance and Developer
Experience
7

8. C1 Public
Performance
• Quarkus performs much better in
restrictive environments
– The less resources to the pod, the
bigger the difference between
Quarkus and Spring
– Quarkus performs very well under
pressure with limited resources
• Quarkus is adapting faster after boot
– Quarkus is reaching max throughput
in less time than Spring Boot in all
situations, especially with limited
resources
– Compile-time optimizations are
probably the cause
8
0
50000
100000
150000
200000
250000
Cold app Warmed Up
# Requests sustained in 30 seconds,
300mCPUs, 300MB RAM, 10 VUs
Spring Boot Quarkus
0
50000
100000
150000
200000
250000
Cold app Warmed Up
# Requests sustained in 30 seconds, 1CPU,
1GB RAM, 10VUs
Spring Boot Quarkus
0
100000
200000
300000
400000
500000
Cold app Warmed Up
# Requests sustained in 60 seconds,
300mCPUs, 300MB RAM, 30 VUs
Spring Boot Quarkus
• More RAM and CPU will narrow
the gap
• Spring, however will take more
time to reach its maximum
throughput than Quarkus
Tests conducted on Microk8s, Running on M1
Pro, with a total of 4 cpus and 6GB total RAM

9. C1 Public
9
• You will always limit your pod usage in real-life.
– K8s makes better decisions with deterministic resource allocation
– You will need control over your scaling and resource consumption (CPU / RAM)
– You must perform tests inside containers with limited CPU and RAM
• “The more you add, the slower it gets”
– The more dependencies and code you add to an app, the slower it gets,
especially in boot time (initial setup, setting up connections, etc)
– Quarkus’ boot times increase only logarithmically
– Quarkus seems to make AOT optimizations
• Comparing apples-to-apples
– Vodafone initially (2019) compared Quarkus non-reactive with Spring MVC
– Their reactive counterparts (Resteasy Reactive and Webflux) are much faster
– …but there is still a difference in performance and boot time especially in
microservices with many cross-cutting concerns
Performance

10. C1 Public
10
• Performance is the developer’s currency
– Less time on optimizations -> More time on building your
business logic
• Resilience
– Boot times improve resilience to traffic spikes
– Lower resource consumption increases the number of
replicas you can run in parallel at the same time
• Low resource consumption means better
horizontal scaling
– More replicas per microservice
– Kubernetes can manage replicas with more flexibility
Performance
Monolith

11. C1 Public
Cluster Scaling (Spring Boot)
11
Low-traffic hours
High Traffic hours

12. C1 Public
Cluster Scaling (Quarkus)
12
High Traffic hours Low-traffic hours
More microservices in the same quotas allows for more aggressive
scaling and faster cluster adaptiveness during high-traffic spikes

13. C1 Public
13
• Hot module replacement out of the box
• Microprofile specification was very simple
– Filters in outbout requests
– Simple Kafka and messaging implementation
– Microprofile Health and Fault Tolerance proved to be great assets
– Widespread adoption
– Our Spring developers felt at home
• Simple and lean programming model
– Reactive approaches work very good
• Developer-first choices
– Remote development is a plus
– Dev Services (added later) also sped up development
• Experienced Spring developers found it very easy to migrate
• Depending on the situation, dev performance improves 30% - 40%
– Measured in Agile Sprints
Developer Experience – Microprofile Spec

14. C1 Public
14
• Why reactive?
– Serve more than one operation per-thread
– Allows better granularity in parallelism and i/o
– It’s one of the reasons of Vodafone’s DXL’s low-latency
• Requires mentality shift
– Callback mechanism
– Asynchronous thinking
– Reactive frameworks to the rescue (Mutiny, Reactor, RxJava)
• Quarkus vs Spring reactive implementations
– Resteasy Reactive marries the Reactive and Imperative world perfectly
– Can use both interchangeable, with little to no mentality shift
– Spring needs to use a different stack altogether
– One needs to use WebFlux, and loses much flexibility with context propagation and
dependency injection
– Spring trafeoff: Peformance vs Flexibility
Developer Experience – Reactive

15. C1 Public
15
• JVM perks
– JVM has much higher throughput
– JVM can process large quantities of data with less memory than
native due to JIT
– JVM is very easily debuggable
– Native compilation requires a strong machine and much time
• Native app Perks
– Extremely low boot time
– Low Resource Consumption *
– … for smaller workloads
– System-components (like kubernetes operators)
– Useful for Lambda
– Useful for short-lived components
To Native or not to Native?
Monolith

16. Conclusion / Q&A
16

17. C1 Public
Want To know/learn/watch more?
17
• Stream processing app. with Kafka and Quarkus (12:20-13:00, MC2)
• Quarkus on AWS Lambda (14:10-14:25, MC3)
• Why and when to write a Quarkus extension (14:35-14:50, MC3)
• Quarkus Community BOF (15:05-16:05, MC3)
• Contract testing with Pact and Quarkus (16:35-17:15, MC3)
• OpenId Connect and JWT Security in Quarkus (17:30-18:10, MC2)
• A DXL Journey by Vodafone Greece (Friday, 15:35-15:50, MC3)