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 <angusyo...@gmail.com> wrote: > I think this is a good idea. > > +1 > > On Sat, Jun 6, 2020 at 7:57 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > > > +1 > > > > 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 > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > -- > Otavio R. Piske > http://orpiske.net >
