+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 <o...@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 <lburgazz...@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 > > >
