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 <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 > > >
