camel-k: switch to Quarkus as default framework for integrations

[Luca Burgazzoli <lb...@gmail.com>]

Hello everyone,

When we started working on camel-k, we haven't found any runtime/framework
that could cope with the type of workloads we had in mind for camel-k so we
ended up rolling our own framework but later on the Quarkus project has
started and that has changed a little the landscape as the Quarkus goal is
to support the very same cloud native workload swe want to support so we
have added support for Quarkus in camel-k.

So as today we have two runtimes on which integrations can run:
- our in-house one based on camel-main
- a Quarkus based one that leverages the camel-quarkus project

Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
in-house framework and focus our effort on making Quarkus the foundation
for camel-k runtimes (the integrations) as:

1. Maintaining the two runtimes is becoming a challenge as a lot of
features we want are already provided by Quarkus and to make the runtimes
on par we need to develop the same set of features on our in-house
framework (think about health checks, integration with tracing and
monitoring, security, etc.). For the end-users it is also confusing as the
two runtimes have a different set of configuration options so even if
there's no difference between how routes are written using one or the other
runtime is not completely transparent.

2. Quarkus offers faster startup and reduced memory footprint by moving
some of the initialization at build time which copes perfectly with our
camel-k design as we can make optimized images once and re-use them for a
number of integrations.

3. Quarkus and the Camel Quarkus subproject can help us to leverage native
compilation when possible which fits perfectly with the serverless workload
we want camel-k to target.


What do you think ?






---
Luca Burgazzoli

Re: camel-k: switch to Quarkus as default framework for integrations

[Luca Burgazzoli <lb...@gmail.com>]

On Fri, Jun 5, 2020 at 4:14 PM Zheng Feng <zf...@redhat.com> wrote:

> +1 But it looks like not all of the camel components have been available on
> the camel-quarkus. Would this be a problem ?
>

I don't see this as a severe issue as it is just a matter of time and we
can at least generate a JVM only extension of every missing component.


> On Fri, Jun 5, 2020 at 7:51 PM Luca Burgazzoli <lb...@gmail.com>
> wrote:
>
> > Hello everyone,
> >
> > When we started working on camel-k, we haven't found any
> runtime/framework
> > that could cope with the type of workloads we had in mind for camel-k so
> we
> > ended up rolling our own framework but later on the Quarkus project has
> > started and that has changed a little the landscape as the Quarkus goal
> is
> > to support the very same cloud native workload swe want to support so we
> > have added support for Quarkus in camel-k.
> >
> > So as today we have two runtimes on which integrations can run:
> > - our in-house one based on camel-main
> > - a Quarkus based one that leverages the camel-quarkus project
> >
> > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > in-house framework and focus our effort on making Quarkus the foundation
> > for camel-k runtimes (the integrations) as:
> >
> > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > features we want are already provided by Quarkus and to make the runtimes
> > on par we need to develop the same set of features on our in-house
> > framework (think about health checks, integration with tracing and
> > monitoring, security, etc.). For the end-users it is also confusing as
> the
> > two runtimes have a different set of configuration options so even if
> > there's no difference between how routes are written using one or the
> other
> > runtime is not completely transparent.
> >
> > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > some of the initialization at build time which copes perfectly with our
> > camel-k design as we can make optimized images once and re-use them for a
> > number of integrations.
> >
> > 3. Quarkus and the Camel Quarkus subproject can help us to leverage
> native
> > compilation when possible which fits perfectly with the serverless
> workload
> > we want camel-k to target.
> >
> >
> > What do you think ?
> >
> >
> >
> >
> >
> >
> > ---
> > Luca Burgazzoli
> >
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Zheng Feng <zf...@redhat.com>]

+1 But it looks like not all of the camel components have been available on
the camel-quarkus. Would this be a problem ?

On Fri, Jun 5, 2020 at 7:51 PM Luca Burgazzoli <lb...@gmail.com>
wrote:

> Hello everyone,
>
> When we started working on camel-k, we haven't found any runtime/framework
> that could cope with the type of workloads we had in mind for camel-k so we
> ended up rolling our own framework but later on the Quarkus project has
> started and that has changed a little the landscape as the Quarkus goal is
> to support the very same cloud native workload swe want to support so we
> have added support for Quarkus in camel-k.
>
> So as today we have two runtimes on which integrations can run:
> - our in-house one based on camel-main
> - a Quarkus based one that leverages the camel-quarkus project
>
> Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> in-house framework and focus our effort on making Quarkus the foundation
> for camel-k runtimes (the integrations) as:
>
> 1. Maintaining the two runtimes is becoming a challenge as a lot of
> features we want are already provided by Quarkus and to make the runtimes
> on par we need to develop the same set of features on our in-house
> framework (think about health checks, integration with tracing and
> monitoring, security, etc.). For the end-users it is also confusing as the
> two runtimes have a different set of configuration options so even if
> there's no difference between how routes are written using one or the other
> runtime is not completely transparent.
>
> 2. Quarkus offers faster startup and reduced memory footprint by moving
> some of the initialization at build time which copes perfectly with our
> camel-k design as we can make optimized images once and re-use them for a
> number of integrations.
>
> 3. Quarkus and the Camel Quarkus subproject can help us to leverage native
> compilation when possible which fits perfectly with the serverless workload
> we want camel-k to target.
>
>
> What do you think ?
>
>
>
>
>
>
> ---
> Luca Burgazzoli
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Andrea Cosentino <an...@gmail.com>]

+1 on this, I believe it totally makes sense to default on quarkus.

Il giorno ven 5 giu 2020 alle ore 14:58 Omar Al-Safi <om...@oalsafi.com> ha
scritto:

> +1
> I think IMHO it would make sense to rely on Quarkus since this is what
> meant for. At the beginning, when I was getting into Camel-k, I was only
> confused about the runtimes being used there, hence I think it would make
> sense to reduce the runtimes in order to allow greater focus.
>
> Regards,
> Omar
>
> On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com>
> wrote:
>
> > Hello everyone,
> >
> > When we started working on camel-k, we haven't found any
> runtime/framework
> > that could cope with the type of workloads we had in mind for camel-k so
> we
> > ended up rolling our own framework but later on the Quarkus project has
> > started and that has changed a little the landscape as the Quarkus goal
> is
> > to support the very same cloud native workload swe want to support so we
> > have added support for Quarkus in camel-k.
> >
> > So as today we have two runtimes on which integrations can run:
> > - our in-house one based on camel-main
> > - a Quarkus based one that leverages the camel-quarkus project
> >
> > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > in-house framework and focus our effort on making Quarkus the foundation
> > for camel-k runtimes (the integrations) as:
> >
> > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > features we want are already provided by Quarkus and to make the runtimes
> > on par we need to develop the same set of features on our in-house
> > framework (think about health checks, integration with tracing and
> > monitoring, security, etc.). For the end-users it is also confusing as
> the
> > two runtimes have a different set of configuration options so even if
> > there's no difference between how routes are written using one or the
> other
> > runtime is not completely transparent.
> >
> > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > some of the initialization at build time which copes perfectly with our
> > camel-k design as we can make optimized images once and re-use them for a
> > number of integrations.
> >
> > 3. Quarkus and the Camel Quarkus subproject can help us to leverage
> native
> > compilation when possible which fits perfectly with the serverless
> workload
> > we want camel-k to target.
> >
> >
> > What do you think ?
> >
> >
> >
> >
> >
> >
> > ---
> > Luca Burgazzoli
> >
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Omar Al-Safi <om...@oalsafi.com>]

+1
I think IMHO it would make sense to rely on Quarkus since this is what
meant for. At the beginning, when I was getting into Camel-k, I was only
confused about the runtimes being used there, hence I think it would make
sense to reduce the runtimes in order to allow greater focus.

Regards,
Omar

On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com>
wrote:

> Hello everyone,
>
> When we started working on camel-k, we haven't found any runtime/framework
> that could cope with the type of workloads we had in mind for camel-k so we
> ended up rolling our own framework but later on the Quarkus project has
> started and that has changed a little the landscape as the Quarkus goal is
> to support the very same cloud native workload swe want to support so we
> have added support for Quarkus in camel-k.
>
> So as today we have two runtimes on which integrations can run:
> - our in-house one based on camel-main
> - a Quarkus based one that leverages the camel-quarkus project
>
> Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> in-house framework and focus our effort on making Quarkus the foundation
> for camel-k runtimes (the integrations) as:
>
> 1. Maintaining the two runtimes is becoming a challenge as a lot of
> features we want are already provided by Quarkus and to make the runtimes
> on par we need to develop the same set of features on our in-house
> framework (think about health checks, integration with tracing and
> monitoring, security, etc.). For the end-users it is also confusing as the
> two runtimes have a different set of configuration options so even if
> there's no difference between how routes are written using one or the other
> runtime is not completely transparent.
>
> 2. Quarkus offers faster startup and reduced memory footprint by moving
> some of the initialization at build time which copes perfectly with our
> camel-k design as we can make optimized images once and re-use them for a
> number of integrations.
>
> 3. Quarkus and the Camel Quarkus subproject can help us to leverage native
> compilation when possible which fits perfectly with the serverless workload
> we want camel-k to target.
>
>
> What do you think ?
>
>
>
>
>
>
> ---
> Luca Burgazzoli
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Luca Burgazzoli <lb...@gmail.com>]

Opened the following two issues:

- https://github.com/apache/camel-k/issues/1513
- https://github.com/apache/camel-k-runtime/issues/359

---
Luca Burgazzoli


On Mon, Jun 8, 2020 at 10:15 AM Otavio Rodolfo Piske <an...@gmail.com>
wrote:

> I think this is a good idea.
>
> +1
>
> On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > +1
> >
> > On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com>
> > wrote:
> > >
> > > Hello everyone,
> > >
> > > When we started working on camel-k, we haven't found any
> > runtime/framework
> > > that could cope with the type of workloads we had in mind for camel-k
> so
> > we
> > > ended up rolling our own framework but later on the Quarkus project has
> > > started and that has changed a little the landscape as the Quarkus goal
> > is
> > > to support the very same cloud native workload swe want to support so
> we
> > > have added support for Quarkus in camel-k.
> > >
> > > So as today we have two runtimes on which integrations can run:
> > > - our in-house one based on camel-main
> > > - a Quarkus based one that leverages the camel-quarkus project
> > >
> > > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > > in-house framework and focus our effort on making Quarkus the
> foundation
> > > for camel-k runtimes (the integrations) as:
> > >
> > > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > > features we want are already provided by Quarkus and to make the
> runtimes
> > > on par we need to develop the same set of features on our in-house
> > > framework (think about health checks, integration with tracing and
> > > monitoring, security, etc.). For the end-users it is also confusing as
> > the
> > > two runtimes have a different set of configuration options so even if
> > > there's no difference between how routes are written using one or the
> > other
> > > runtime is not completely transparent.
> > >
> > > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > > some of the initialization at build time which copes perfectly with our
> > > camel-k design as we can make optimized images once and re-use them
> for a
> > > number of integrations.
> > >
> > > 3. Quarkus and the Camel Quarkus subproject can help us to leverage
> > native
> > > compilation when possible which fits perfectly with the serverless
> > workload
> > > we want camel-k to target.
> > >
> > >
> > > What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > Luca Burgazzoli
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Otavio Rodolfo Piske <an...@gmail.com>]

I think this is a good idea.

+1

On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <cl...@gmail.com> wrote:

> +1
>
> On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com>
> wrote:
> >
> > Hello everyone,
> >
> > When we started working on camel-k, we haven't found any
> runtime/framework
> > that could cope with the type of workloads we had in mind for camel-k so
> we
> > ended up rolling our own framework but later on the Quarkus project has
> > started and that has changed a little the landscape as the Quarkus goal
> is
> > to support the very same cloud native workload swe want to support so we
> > have added support for Quarkus in camel-k.
> >
> > So as today we have two runtimes on which integrations can run:
> > - our in-house one based on camel-main
> > - a Quarkus based one that leverages the camel-quarkus project
> >
> > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > in-house framework and focus our effort on making Quarkus the foundation
> > for camel-k runtimes (the integrations) as:
> >
> > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > features we want are already provided by Quarkus and to make the runtimes
> > on par we need to develop the same set of features on our in-house
> > framework (think about health checks, integration with tracing and
> > monitoring, security, etc.). For the end-users it is also confusing as
> the
> > two runtimes have a different set of configuration options so even if
> > there's no difference between how routes are written using one or the
> other
> > runtime is not completely transparent.
> >
> > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > some of the initialization at build time which copes perfectly with our
> > camel-k design as we can make optimized images once and re-use them for a
> > number of integrations.
> >
> > 3. Quarkus and the Camel Quarkus subproject can help us to leverage
> native
> > compilation when possible which fits perfectly with the serverless
> workload
> > we want camel-k to target.
> >
> >
> > What do you think ?
> >
> >
> >
> >
> >
> >
> > ---
> > Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Otavio R. Piske
http://orpiske.net

Re: camel-k: switch to Quarkus as default framework for integrations

[Alex Dettinger <al...@gmail.com>]

+1

On Sat, Jun 6, 2020 at 11:53 AM Federico Valeri <fe...@gmail.com>
wrote:

> +1
>
> On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <cl...@gmail.com> wrote:
> >
> > +1
> >
> > On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com>
> wrote:
> > >
> > > Hello everyone,
> > >
> > > When we started working on camel-k, we haven't found any
> runtime/framework
> > > that could cope with the type of workloads we had in mind for camel-k
> so we
> > > ended up rolling our own framework but later on the Quarkus project has
> > > started and that has changed a little the landscape as the Quarkus
> goal is
> > > to support the very same cloud native workload swe want to support so
> we
> > > have added support for Quarkus in camel-k.
> > >
> > > So as today we have two runtimes on which integrations can run:
> > > - our in-house one based on camel-main
> > > - a Quarkus based one that leverages the camel-quarkus project
> > >
> > > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > > in-house framework and focus our effort on making Quarkus the
> foundation
> > > for camel-k runtimes (the integrations) as:
> > >
> > > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > > features we want are already provided by Quarkus and to make the
> runtimes
> > > on par we need to develop the same set of features on our in-house
> > > framework (think about health checks, integration with tracing and
> > > monitoring, security, etc.). For the end-users it is also confusing as
> the
> > > two runtimes have a different set of configuration options so even if
> > > there's no difference between how routes are written using one or the
> other
> > > runtime is not completely transparent.
> > >
> > > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > > some of the initialization at build time which copes perfectly with our
> > > camel-k design as we can make optimized images once and re-use them
> for a
> > > number of integrations.
> > >
> > > 3. Quarkus and the Camel Quarkus subproject can help us to leverage
> native
> > > compilation when possible which fits perfectly with the serverless
> workload
> > > we want camel-k to target.
> > >
> > >
> > > What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > Luca Burgazzoli
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>

Re: camel-k: switch to Quarkus as default framework for integrations

[Federico Valeri <fe...@gmail.com>]

+1

On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> +1
>
> On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com> wrote:
> >
> > Hello everyone,
> >
> > When we started working on camel-k, we haven't found any runtime/framework
> > that could cope with the type of workloads we had in mind for camel-k so we
> > ended up rolling our own framework but later on the Quarkus project has
> > started and that has changed a little the landscape as the Quarkus goal is
> > to support the very same cloud native workload swe want to support so we
> > have added support for Quarkus in camel-k.
> >
> > So as today we have two runtimes on which integrations can run:
> > - our in-house one based on camel-main
> > - a Quarkus based one that leverages the camel-quarkus project
> >
> > Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> > in-house framework and focus our effort on making Quarkus the foundation
> > for camel-k runtimes (the integrations) as:
> >
> > 1. Maintaining the two runtimes is becoming a challenge as a lot of
> > features we want are already provided by Quarkus and to make the runtimes
> > on par we need to develop the same set of features on our in-house
> > framework (think about health checks, integration with tracing and
> > monitoring, security, etc.). For the end-users it is also confusing as the
> > two runtimes have a different set of configuration options so even if
> > there's no difference between how routes are written using one or the other
> > runtime is not completely transparent.
> >
> > 2. Quarkus offers faster startup and reduced memory footprint by moving
> > some of the initialization at build time which copes perfectly with our
> > camel-k design as we can make optimized images once and re-use them for a
> > number of integrations.
> >
> > 3. Quarkus and the Camel Quarkus subproject can help us to leverage native
> > compilation when possible which fits perfectly with the serverless workload
> > we want camel-k to target.
> >
> >
> > What do you think ?
> >
> >
> >
> >
> >
> >
> > ---
> > Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: camel-k: switch to Quarkus as default framework for integrations

[Claus Ibsen <cl...@gmail.com>]

+1

On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <lb...@gmail.com> wrote:
>
> Hello everyone,
>
> When we started working on camel-k, we haven't found any runtime/framework
> that could cope with the type of workloads we had in mind for camel-k so we
> ended up rolling our own framework but later on the Quarkus project has
> started and that has changed a little the landscape as the Quarkus goal is
> to support the very same cloud native workload swe want to support so we
> have added support for Quarkus in camel-k.
>
> So as today we have two runtimes on which integrations can run:
> - our in-house one based on camel-main
> - a Quarkus based one that leverages the camel-quarkus project
>
> Here I'm proposing that after camel-k 1.0.0 we'll drop support for the
> in-house framework and focus our effort on making Quarkus the foundation
> for camel-k runtimes (the integrations) as:
>
> 1. Maintaining the two runtimes is becoming a challenge as a lot of
> features we want are already provided by Quarkus and to make the runtimes
> on par we need to develop the same set of features on our in-house
> framework (think about health checks, integration with tracing and
> monitoring, security, etc.). For the end-users it is also confusing as the
> two runtimes have a different set of configuration options so even if
> there's no difference between how routes are written using one or the other
> runtime is not completely transparent.
>
> 2. Quarkus offers faster startup and reduced memory footprint by moving
> some of the initialization at build time which copes perfectly with our
> camel-k design as we can make optimized images once and re-use them for a
> number of integrations.
>
> 3. Quarkus and the Camel Quarkus subproject can help us to leverage native
> compilation when possible which fits perfectly with the serverless workload
> we want camel-k to target.
>
>
> What do you think ?
>
>
>
>
>
>
> ---
> Luca Burgazzoli



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2