+ "content": "INTRODUCTION As a global telecommunications leader, has always been at the forefront of innovation. Along with Deutsche Telekom, Telefónica, and Vodafone, Orange co-founded the , an initiative aimed at simplifying the consumption of 5G APIs for third-party application developers. To achieve this goal, Orange needed a flexible and lightweight framework capable of handling constrained API exposure while ensuring compatibility with existing network core systems. After a rigorous evaluation of multiple frameworks and toolkits — including Quarkus, Ktor, Micronaut, and Vert.x — Orange selected Quarkus as the ideal solution. , software craftsman at Orange, told us why. WHY QUARKUS? A FRAMEWORK EVALUATION The team at Orange identified application startup time as a barrier to dynamic Kubernetes pod management. So they embarked on a comparative study to test alternatives to Spring Boot in a well-defined API wrapper exposure context. Key evaluation criteria included: * Learning Curve: How easily could a Spring developer transition? * Kotlin Compatibility: Could the framework work seamlessly with Kotlin? * Runtime footprint: Could it operate efficiently in a constrained environment? * Ease of Deployment: How smoothly could it be deployed on Kubernetes? After extensive testing, Quarkus stood out for multiple reasons: * Simplicity: A relatively simple learning curve, especially for those familiar with JAX-RS / Jakarta REST. * Dev Mode: Very fast startup, live reload and zero configuration Dev Services (Vault, Redis) result in great developer productivity. * Modularity: Only required dependencies were embedded, keeping applications lean. * Documentation: Well-organized, versioned documentation with working examples. * Native Compilation: The ability to generate compact native binaries for Kubernetes deployment. Despite the strong competition from a vibrant JVM ecosystem, these advantages made Quarkus the preferred choice for exposing 5G APIs at Orange. LESSONS LEARNED FROM ADOPTING QUARKUS MIGRATION & DEVELOPMENT EXPERIENCE Transitioning from Spring to Quarkus was not overly complex, especially for those familiar with JAX-RS / Jakarta REST. The significantly enhanced productivity in dev and test modes, but required careful consideration for their CI/CD environments, where no container runtime is available. The modular approach ensured applications remained lightweight but introduced a large number of small dependencies to manage. SPEC-FIRST API DEVELOPMENT As spec-first practitioners, integrating OpenAPI specification generation was a crucial requirement that Quarkus handled effectively. JAVA & KOTLIN INTEROPERABILITY While Quarkus supports Kotlin, writing full Kotlin extensions proved challenging at times. The team retained some Java code, and Java-Kotlin interoperability worked smoothly. NATIVE COMPILATION & PERFORMANCE Native compilation produced compact native executables, but the process of producing them was lengthy. The team reserved it for the final build stage when absolutely necessary. Some fine-tuning was required to prevent class pruning issues. When building native executables, the call tree is analyzed to determine which classes and methods are used. Everything that is not used is pruned to reduce the size of the executable and the RSS usage. In some cases, e.g. when using reflection, you will have to declare explicitly that a class is used so that it ends up being included in the native executable. Quarkus provides tooling to simplify this configuration. REACTIVE PROGRAMMING & MUTINY Having worked extensively with Reactor, the transition to Mutiny had a learning curve. While effective and more intuitive thanks to its navigable API, it was perceived as more verbose for the simple cases. ARCHITECTURE OVERVIEW Orange designed a microservices-based architecture to expose 5G APIs efficiently. MICROSERVICES & API WRAPPERS Each API wrapper was implemented as a dedicated microservice for better version control. The team leveraged Reactive APIs wherever possible, since there are a lot of time-consuming asynchronous tasks to be performed on the core network side and saving resources is a business goal. CI/CD & DEPLOYMENT Each microservice had its own GitLab repository with an independent build pipeline for its Docker image. Renovate was used to automate dependency upgrades. A dedicated deployment project pushed new Docker images to an OpenShift cluster using Kustomize + ArgoCD. INFRASTRUCTURE COMPONENTS Additional services included: * Vault for secrets management * Redis for caching * Neo4j for database operations * Kafka for messaging Vert.x HTTP Proxy was used for routing and backend protection. RESULTS & IMPACT After implementing Quarkus in production, Orange successfully deployed ten APIs across various 4G/5G network cores. Over time, the team performed multiple Quarkus version upgrades (2.11 → 3.14), all well-managed through Renovate with minimal code adaptation—except for necessary adjustments during the migration to Jakarta EE."
0 commit comments