Camel runtime

[ski n <ra...@gmail.com>]

In a big organization, we have a discussion on Camel runtimes.

When looking at the website, there are options like

- Main/JVM
- Karaf
- Wildfly/EAP
- Spring Boot
- Quarkus
- Knative

The Camel project seems to be neutral towards various runtimes, which make
the choice dependent on:

- technologies that are currently in use
- knowledge about certain technologies
- architectural preferences
- personal preferences

The discussion started, because one team with OSGi knowledge started using
Camel with Karaf (on Fuse 6.x), another team started with Wildfly/EAP (on
Fuse 7.x). They also use Assimbly Gateway which is Spring Boot based. And
now are setting up an OpenShift cluster where KamelK and Quarkus are used.

Now this is a big organization, so some choices were made independently of
each other and without even knowing about other Camel initiatives.

Now, the discussion goes along these lines:

1) CamelK/Quarkus team: It's clear that K8/OpenShift is the future. It has
a microservice approach that is easily scalable. Karaf/Wildfly
tend to put too many integrations in one place, and scaling with multiple
instances takes too much effort. In general OSGi is dead, and Karaf and
ServiceMix don't get any attention anymore from the Camel Community. Same
count for Wildfly. It's clear that CamelK/Kamelets gets the most
development effort and is the easiest to develop new integrations. It can
run natively with Quarkus and without JVM. Thus, it makes it the
easiest and the fastest option as a runtime.

2)  Karaf team: OSGi is the most modular and clear architectural approach.
It's a proven way and works from the very start of Camel 1.x until today.
We tried to use Wildfly, but found it a mess and hard to get working.
OpenShift is also very complex, besides it only works in cloud use cases.
We moved towards Fuse 7.x with WildFly, but returned to Karaf. This seems
to be the best option over the years.

3) WildFly team: Initially we found it hard to setup, but when it's setup
you easily can throw any Java project in it without changing a lot.
No need to adapt code to OSGi or KNative. We can work relatively with plain
Java and can put in Camel and other Java stuff in it easily. Besides
WildFly is still actively developed, with version 27 around the corner and
also available on OperatorHub.

4) Spring Boot/Assimbly team: Spring Boot can work on premise, on Docker or
K8 without problems. It's the most used and proved runtime in the Java
world. It's easy, there are lots of documentation and StackOverflow pages.
They also work on Spring Boot which will natively and JDK17. It's pretty
plain Java and the convention over configuration approach of Spring Boot
saves time. It's the best middle ground for all runtimes, besides you can
always change the servlet server
between Jetty, Undertow and Tomcat.


I as an independent consultant together with the Architect for now keep a
"DevOps/Choose your own technology" approach together with using common
message technologies like REST API, Kafka and ActiveMQ as middleware layers
in between.

Still, I am wondering from the Camel community what their reasons were for
choosing a particular runtime.

1) What were your reason for selecting your runtime?
2) When you pick a runtime today, which one would it be?
3) What runtime is the most future-proof in your opinion?
4) Do you agree with one of the teams, should we stick to one or two
runtime only?
5) Do you think there should be choosing guide? Or an even select a
preferred runtime?

Re: Camel runtime

[Romain Manni-Bucau <rm...@gmail.com>]

Hi,

Hoping it helps a bit, my feedback is that it depends who and what.

1. & 2. All the mentionned technologies are good (and you can add a bunch
like TomEE, Meecrowave, micronaut, uship, plain standalone too, ...) but a
choice of technology is rarely relevant regarding the technology itself but
more regarding the people using and deploying it so if teams are not
homogeneous it is not bad to pick different technologies while it is not a
one man choice for a company.
With k8s (openshift is not a game changer there but the orchestrator is),
OSGi or not will not change much in terms of features thanks the rollout
capabilities of the runtime whatever the way the app is developped so it is
more about deploying or not heterogeneous (incompatible ;)) libraries in
the same runtime (for gateway or resource optimization purposes for ex),
rest is faith ;).

3. Any cloud friendly runtime is future-proof (spring boot, JakartaEE,
OSGi/Karaf, meecrowave-core, uship, standalone, but I would avoid
microprofile like runtime since the API are very unstable).

4. About 4 it is mainly about who is handling the runtime. If the strategy
is each team owns its runtime, let it be. If it is one transversal team
handling the runtimes of the other teams then you should normalize it and
likely make it the lightest possible to ensure it covers the most of the
other teams (consumers).

5. theorically yes but in practise nobody will respect it ;)

Hope it helps even if it is not a "do that" answer ;)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 9 janv. 2022 à 17:19, Jean-Baptiste Onofre <jb...@nanthrax.net> a
écrit :

> Hi,
>
> I’m not sure I’m the right person to provide advice about the runtime (I
> might by biased ;)).
>
> The only thing that I can share is that I plan to propose karamel
> (tooling/runtime for camel-karaf upgrading to karaf 5).
> I hope to have some time in the coming weeks to share some details.
>
> Regards
> JB
>
> > Le 9 janv. 2022 à 13:04, ski n <ra...@gmail.com> a écrit :
> >
> > In a big organization, we have a discussion on Camel runtimes.
> >
> > When looking at the website, there are options like
> >
> > - Main/JVM
> > - Karaf
> > - Wildfly/EAP
> > - Spring Boot
> > - Quarkus
> > - Knative
> >
> > The Camel project seems to be neutral towards various runtimes, which
> make
> > the choice dependent on:
> >
> > - technologies that are currently in use
> > - knowledge about certain technologies
> > - architectural preferences
> > - personal preferences
> >
> > The discussion started, because one team with OSGi knowledge started
> using
> > Camel with Karaf (on Fuse 6.x), another team started with Wildfly/EAP (on
> > Fuse 7.x). They also use Assimbly Gateway which is Spring Boot based. And
> > now are setting up an OpenShift cluster where KamelK and Quarkus are
> used.
> >
> > Now this is a big organization, so some choices were made independently
> of
> > each other and without even knowing about other Camel initiatives.
> >
> > Now, the discussion goes along these lines:
> >
> > 1) CamelK/Quarkus team: It's clear that K8/OpenShift is the future. It
> has
> > a microservice approach that is easily scalable. Karaf/Wildfly
> > tend to put too many integrations in one place, and scaling with multiple
> > instances takes too much effort. In general OSGi is dead, and Karaf and
> > ServiceMix don't get any attention anymore from the Camel Community. Same
> > count for Wildfly. It's clear that CamelK/Kamelets gets the most
> > development effort and is the easiest to develop new integrations. It can
> > run natively with Quarkus and without JVM. Thus, it makes it the
> > easiest and the fastest option as a runtime.
> >
> > 2)  Karaf team: OSGi is the most modular and clear architectural
> approach.
> > It's a proven way and works from the very start of Camel 1.x until today.
> > We tried to use Wildfly, but found it a mess and hard to get working.
> > OpenShift is also very complex, besides it only works in cloud use cases.
> > We moved towards Fuse 7.x with WildFly, but returned to Karaf. This seems
> > to be the best option over the years.
> >
> > 3) WildFly team: Initially we found it hard to setup, but when it's setup
> > you easily can throw any Java project in it without changing a lot.
> > No need to adapt code to OSGi or KNative. We can work relatively with
> plain
> > Java and can put in Camel and other Java stuff in it easily. Besides
> > WildFly is still actively developed, with version 27 around the corner
> and
> > also available on OperatorHub.
> >
> > 4) Spring Boot/Assimbly team: Spring Boot can work on premise, on Docker
> or
> > K8 without problems. It's the most used and proved runtime in the Java
> > world. It's easy, there are lots of documentation and StackOverflow
> pages.
> > They also work on Spring Boot which will natively and JDK17. It's pretty
> > plain Java and the convention over configuration approach of Spring Boot
> > saves time. It's the best middle ground for all runtimes, besides you can
> > always change the servlet server
> > between Jetty, Undertow and Tomcat.
> >
> >
> > I as an independent consultant together with the Architect for now keep a
> > "DevOps/Choose your own technology" approach together with using common
> > message technologies like REST API, Kafka and ActiveMQ as middleware
> layers
> > in between.
> >
> > Still, I am wondering from the Camel community what their reasons were
> for
> > choosing a particular runtime.
> >
> > 1) What were your reason for selecting your runtime?
> > 2) When you pick a runtime today, which one would it be?
> > 3) What runtime is the most future-proof in your opinion?
> > 4) Do you agree with one of the teams, should we stick to one or two
> > runtime only?
> > 5) Do you think there should be choosing guide? Or an even select a
> > preferred runtime?
>
>

Re: Camel runtime

[Jean-Baptiste Onofre <jb...@nanthrax.net>]

Hi,

I’m not sure I’m the right person to provide advice about the runtime (I might by biased ;)).

The only thing that I can share is that I plan to propose karamel (tooling/runtime for camel-karaf upgrading to karaf 5).
I hope to have some time in the coming weeks to share some details.

Regards
JB

> Le 9 janv. 2022 à 13:04, ski n <ra...@gmail.com> a écrit :
> 
> In a big organization, we have a discussion on Camel runtimes.
> 
> When looking at the website, there are options like
> 
> - Main/JVM
> - Karaf
> - Wildfly/EAP
> - Spring Boot
> - Quarkus
> - Knative
> 
> The Camel project seems to be neutral towards various runtimes, which make
> the choice dependent on:
> 
> - technologies that are currently in use
> - knowledge about certain technologies
> - architectural preferences
> - personal preferences
> 
> The discussion started, because one team with OSGi knowledge started using
> Camel with Karaf (on Fuse 6.x), another team started with Wildfly/EAP (on
> Fuse 7.x). They also use Assimbly Gateway which is Spring Boot based. And
> now are setting up an OpenShift cluster where KamelK and Quarkus are used.
> 
> Now this is a big organization, so some choices were made independently of
> each other and without even knowing about other Camel initiatives.
> 
> Now, the discussion goes along these lines:
> 
> 1) CamelK/Quarkus team: It's clear that K8/OpenShift is the future. It has
> a microservice approach that is easily scalable. Karaf/Wildfly
> tend to put too many integrations in one place, and scaling with multiple
> instances takes too much effort. In general OSGi is dead, and Karaf and
> ServiceMix don't get any attention anymore from the Camel Community. Same
> count for Wildfly. It's clear that CamelK/Kamelets gets the most
> development effort and is the easiest to develop new integrations. It can
> run natively with Quarkus and without JVM. Thus, it makes it the
> easiest and the fastest option as a runtime.
> 
> 2)  Karaf team: OSGi is the most modular and clear architectural approach.
> It's a proven way and works from the very start of Camel 1.x until today.
> We tried to use Wildfly, but found it a mess and hard to get working.
> OpenShift is also very complex, besides it only works in cloud use cases.
> We moved towards Fuse 7.x with WildFly, but returned to Karaf. This seems
> to be the best option over the years.
> 
> 3) WildFly team: Initially we found it hard to setup, but when it's setup
> you easily can throw any Java project in it without changing a lot.
> No need to adapt code to OSGi or KNative. We can work relatively with plain
> Java and can put in Camel and other Java stuff in it easily. Besides
> WildFly is still actively developed, with version 27 around the corner and
> also available on OperatorHub.
> 
> 4) Spring Boot/Assimbly team: Spring Boot can work on premise, on Docker or
> K8 without problems. It's the most used and proved runtime in the Java
> world. It's easy, there are lots of documentation and StackOverflow pages.
> They also work on Spring Boot which will natively and JDK17. It's pretty
> plain Java and the convention over configuration approach of Spring Boot
> saves time. It's the best middle ground for all runtimes, besides you can
> always change the servlet server
> between Jetty, Undertow and Tomcat.
> 
> 
> I as an independent consultant together with the Architect for now keep a
> "DevOps/Choose your own technology" approach together with using common
> message technologies like REST API, Kafka and ActiveMQ as middleware layers
> in between.
> 
> Still, I am wondering from the Camel community what their reasons were for
> choosing a particular runtime.
> 
> 1) What were your reason for selecting your runtime?
> 2) When you pick a runtime today, which one would it be?
> 3) What runtime is the most future-proof in your opinion?
> 4) Do you agree with one of the teams, should we stick to one or two
> runtime only?
> 5) Do you think there should be choosing guide? Or an even select a
> preferred runtime?