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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

lburgazzoli
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
Reply | Threaded
Open this post in threaded view
|

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

Omar Al-Safi
+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 <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

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

Andrea Cosentino-3
+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 <[hidden email]> 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 <[hidden email]>
> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Zheng Feng
In reply to this post by lburgazzoli
+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 <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

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

lburgazzoli
On Fri, Jun 5, 2020 at 4:14 PM Zheng Feng <[hidden email]> 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 <[hidden email]>
> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
In reply to this post by lburgazzoli
+1

On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Alex Dettinger
+1

On Sat, Jun 6, 2020 at 11:53 AM Federico Valeri <[hidden email]>
wrote:

> +1
>
> On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <[hidden email]> wrote:
> >
> > +1
> >
> > On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Otavio Rodolfo Piske
In reply to this post by Claus Ibsen-2
I think this is a good idea.

+1

On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <[hidden email]> wrote:

> +1
>
> On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

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

lburgazzoli
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 <[hidden email]>
wrote:

> I think this is a good idea.
>
> +1
>
> On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <[hidden email]> wrote:
>
> > +1
> >
> > On Fri, Jun 5, 2020 at 1:45 PM Luca Burgazzoli <[hidden email]>
> > 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
>