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