Orange API management user story

Author: tsegismont

_data/authors.yaml

@@ -586,3 +586,9 @@ melloware:
   emailhash: "50d0c0653cd1a798bcc5ba1cbfc70ded"
   job_title: "Chief Technology Officer"
   bio: "Chief Technology Officer at KSM Technology Partners LLC"
+tsegismont:
+  name: "Thomas Segismont"
+  email: "tsegismont"
+  emailhash: "6ba99aebb0acd409215e7cdbfb561b7f"
+  job_title: "Principal Software Engineer"
+  bio: "Principal Software Engineer at Red Hat and Vert.x team member"

_posts/2025-03-12-orange-telco-core-network-api-management-with-quarkus.adoc

@@ -0,0 +1,110 @@
+---
+layout: post
+title: 'How Orange leverages Quarkus for seamless access to Telco network capabilities'
+date: 2025-03-12
+tags: user-story
+synopsis: Learn how Orange successfully deployed APIs across various 4G/5G network cores.
+author: tsegismont
+thumbnailimage: /assets/images/posts/quarkus-user-stories/orange/orange-logo.png
+---
+
+:imagesdir: /assets/images/posts/quarkus-user-stories/orange
+
+= How Orange leverages Quarkus for seamless access to Telco network capabilities
+
+image::orange-logo.png[alt=Orange,align=center,width=256]
+
+== Introduction
+
+As a global telecommunications leader, https://www.orange.com[Orange] has always been at the forefront of innovation.
+Along with Deutsche Telekom, Telefónica, and Vodafone, Orange co-founded the https://camaraproject.org[Camara Project], 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.
+
+https://www.linkedin.com/in/patriceconil/[Patrice Conil], software craftsman at Orange, told us why.
+
+== Why Quarkus? A Framework Evaluation
+
+The team at Orange 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 https://quarkus.io/guides/dev-services[Dev Services] significantly enhanced productivity in dev and test modes, but required careful consideration for their CI/CD environments, where no container runtime is availabe.
+
+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.
+
+=== 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.