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
