Hello and thanks for the interest shown in Camel K. I don't have a direct familiarity to OSGI, but I'll try to give you some clarification about what kind of use case Camel K wants to cover.
The idea is to have a Kubernetes product (the Camel K operator) which helps the user to deploy and operate Camel applications in the cloud. Of course, the target is cloud native application, so, you need to understand the gap between what you have and what's desired to consider cloud native. It seems many of those features that you should get from deploying on the cloud (security, tracing, ...) could be different from how you would expect on the cloud. About the considerations, I'll try to give my personal opinion: > * The complexity of migrating our existing applications to a new pattern. This could be challenging. If you have tiny applications that can be described in a single yaml or Java class, then, it will result easier. If you have more complex applications, then, you'll need to evaluate how difficult it really could be to move from your runtime to a more suitable cloud native runtime. Quarkus should be the target if you can. You may also consider to build directly from Git source in Camel K [1]. Try with some application and see what it really takes to go. > * The feasibility of reproducing virtually all our current framework's services (especially the monitoring instrumentation). IMO, if you're moving to the cloud, then, you need to embrace as much as you can from the cloud native instrumentation available. I am aware that reusing services could seem the shortest path, but the reality is that it is the longest because you'll end up doing design compromise and adding tech debt that you will regret in the future. > * The resource overhead (running 100+ Camel K integrations versus 1 Karaf pod with 100 features). I guess you will have to pay this off. I am not familiar with how much resources you need in Karaf. In the cloud, each application is a separate instance, so, normally you will have more resources required upfront. You can fine tune each app, but you probably will have a higher total amount. On the converse you need to consider the possibility to scale up and down (even serverless when using Knative or KEDA) and in general the easier way to automate the workloads. So, this one would be a tradeoff to consider. You let it go something for something else. > * The current Camel K adoption level and available user feedback. The community is healthy and we have many active users asking for support and features. You may engage us through here or on zulip chat [2] and see the kind of conversations we're having more recently. I hope it helps you make any further evaluation. Feel free to ask any further questions or share with us any analysis or investigation you'll be doing. [1] https://camel.apache.org/camel-k/next/running/build-from-git.html [2] https://camel.zulipchat.com/#narrow/channel/257299-camel-k On Mon, Oct 6, 2025 at 9:02 AM Ephemeris Lappis <[email protected]> wrote: > 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, >
