nicolaferraro commented on issue #1196: Performance Question On Camel-K URL: https://github.com/apache/camel-k/issues/1196#issuecomment-574416039 I can try to give some ideas to reason on, but there's no general rule valid for all scenarios. You can run multiple routes in the same JVM, just with `kamel run Routes1.java Routes2.java RoutesN.java --name routes-pack`. The question is when you want to do that and why. I think you should apply the same reasoning that people use when dealing with microservices architectures, where the big integration containing 1000 routes is the `monolith`. E.g. do you want independent scalability of some integration flows? So deploy them separately in order to set the number of replicas independently. If you use Knative they will scale automatically depending on the load, but if you have a single fat integration containing all routes, you need to scale the whole stuff which is heavyweight (takes more time to startup and uses much more resources than needed). E.g. do you have multiple teams? If so you probably want each team to be responsible for their own deployments and not having to synchronize with other teams. You also may want that each update on one single integration not to interfere with other integrations already running (but they will do if they are on the same JVM). I think many other principles that apply to microservices apply also here. You'll end up somewhere in the middle between a single fat integration and an integration per route. The long-term goal of Camel K is to allow you to split based on domain logic rather than resource utilization, by drastically reducing the amount of resource needed. We've already done some work on reducing the amount of resources used in the cluster and we'll do a lot more. What you've now: - Knative services available for HTTP based endpoints: they shut down the JVM when not used - CronJob (fresh #1197): they activate a JVM only when they need to run What we're working on: - Quarkus native compilation: so you don't run a full JVM but a tiny binary for each integration which uses resources comparable to that of a golang application - Keda autoscalers: to run integration only when they need to process data and stop them when idle In particular, Quarkus is a game changer. The [Camel-quarkus](https://github.com/apache/camel-quarkus/tree/master/extensions) repository already contains a lot of Camel components that can compile to native (Camel K will be able to compile to native transparently in one of next releases, we're working on it). If I had to run 1000 integration flows, the first thing I would consider would be to check if camel components I need to use are in the list of Quarkus extensions and contribute what's missing.. That would allow me to care less about non-functional requirements and focus on business logic and maintainability.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
