Hello, I initially looked into Camel K a few years ago, but at the time, our teams weren't ready to integrate it into our Kubernetes (K8s) clusters.
We now have a more stable K8s infrastructure and our ESB applications are running on a robust stack. We successfully migrated our frameworks and roughly 100 exchange modules from Fuse 6 to a containerized, simplified stack: Karaf 4 + Camel 3. To mitigate risk, we maintained the existing design pattern: an OSGi services network where application bundles are blueprints embedding Camel contexts, packaged as feature repositories. The framework's services directly provide application bundles with common utility functions (data access, security, token management, tracing, etc.). Crucially, the majority of these services are used to instrument all our Camel routes with event notifiers. These notifiers meticulously track all exchange executions, providing both technical and business monitoring. Our main endpoint types are files, JMS (ActiveMQ) queues, and HTTP. As part of our strategy to leverage our K8s platforms, Camel K appears to be a very valuable approach. We plan to relaunch a technical testing phase to validate the solution and determine how to integrate it into both our application design and DevOps toolchain. In parallel, we'd like to confirm this architectural choice based on several key considerations: * The complexity of migrating our existing applications to a new pattern. * The feasibility of reproducing virtually all our current framework's services (especially the monitoring instrumentation). * The resource overhead (running 100+ Camel K integrations versus 1 Karaf pod with 100 features). * The current Camel K adoption level and available user feedback. We would greatly appreciate your opinions, feedback, and advice on these points. Thank you in advance. Regards,
