Christos Sotiriou, Backend Chapter Lead in Digital Engineering at Vodafone Greece, delivers a thorough presentation on how Vodafone Greece moved from Spring to Quarkus and the journey towards a cleaner & faster stack. The webinar was delivered on June 25, 2020.

1. Adopting Quarkus for the
Digital eXperience Layer
Presented by Christos Sotiriou
Backend Chapter Lead @ Vodafone Greece
25 June, 2020

2. Digital eXperience Layer
● Vodafone has a plethora of Digital Offerings
● Needed to speed up development & deployments
● Hide legacy SOAP Backends
● Hide enterprise complexity behind simple REST APIs
● Vodafone Group Initiative, Open Source across all markets

3. Digital eXperience Layer
● Cloud middleware based on Kubernetes (AWS)
● Aimed at speeding up data retrieval for VF’s Digital Services
● Currently 90 Microservices (1/3rd of full scope)
● Kafka, MongoDB, Apigee Gateway. REST APIs

4. ● Aggregation through REST
● SOAP Calls to backends
● MongoDB Cache
● Cache Invalidation through
GoldenGate & Kafka
DXL Architecture

5. Challenges

6. Business Model Needs
● Vodafone’s Business Model includes many campaigns
● Multiple and heavy traffic spikes throughout the day
● Microservices running analytics and heavy short-running tasks
● Mission - Critical services (like payments)
The ability to scale out fast is critical

7. CPU usage / Boot Time
● Mongo & Kafka connections slow boot times
● I/O threads consume CPU
● CPU is required for fast booting
High Ram Usage
● Logging per pod through Kafka
● Data transformation takes a toll in resource
consumption
● Large Dependency tree
● Threads also consume memory
Cluster Health

8. Cluster Health
Autoscaling fails due to slow boot times

9. Adopting Quarkus

10. Technology R&D
Finally chose Quarkus
● Performance benefits for JVM
● Quarkus extensions unlock many capabilities
● Hot Reloading
● Microprofile specification ( Java EE for microservices )
● Good Backing ( Red Hat )
● Tested NodeJS, Golang, Micronaut, Vert.x, Quarkus
● Examine how our common library infrastructure would translate
○ i/o
○ Resource Usage
● Performance metrics for our stacks (resource usage, ease of learning)

11. Adopting Quarkus
Rewrote our common libraries infrastructure
● Didn’t use Spring Compatibility Layer
● Used reactive streams and methods (initially RxJava, now Mutiny)
● MP REST Outbound Filters allowed better logging
● Microprofile specification ( Java EE for microservices )
○ REST Client
○ Reactive Streams
● 30% Less Code - discarded a lot of glue code

12. Adopting Quarkus
- All common logic inside common libraries.
- Reduce application-level logic as much as possible.
- Allow developers to care about their own business rules without caring about the ecosystem
- Created internal community where teams are considered to be users of those libraries and
contributors

13. One Year Later

14. Results
Spring Boot:
● 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:
● 360 MB RAM
● 300 mCPUs
● Boot time: 14 seconds
● 2-4 replicas
Faster boot times, resulted in a healthier
cluster
Use Case: User Information Microservice
Normal usage: 2-3 mil requests per day

15. Results
Deployed Quarkus ms
Released to 100% of user base
2 replicas
50% user base,
12 replicas

16. Lessons Learned / Future
- Performance is the developer’s currency
- Have a common infrastructure in place (libraries, procedures)
- Risks pay off more than staying on the safe side
- Replacing more SB microservices
- Testing benefits of JVM vs Native
- Expanding our business model to cover more areas of Vodafone

17. Thank You!