Hello. Thank you very much for your very detailed response. Knowing the active community around Camel-K will strengthen our commitment to studying a future redesign of our ESB system.
Still making slow progress in discovering new concepts, I already have many questions. I'll soon take a look at Zulip, where we'll certainly exchange ideas again. Thanks again. Regards. Le lun. 6 oct. 2025 à 12:40, Pasquale Congiusti < [email protected]> a écrit : > 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, > > >
