Hi Ron, While I haven't refactored an existing solution to use Camel, I've build one from scratch and will be building another one (just a lot smaller) shortly. I've also worked on a good few systems that use custom built flow logic.
The pros I can see from Camel are: 1. Much easier flow configuration and management. It's all in your route builder for your routing logic, just don't try to shove everything into one route builder. 2. Very simple to integrate multiple types of endpoints (REST, file system, message broker, etc.) 3. Clear distinction of what is routing logic and what is processing logic 4. Dialling in consumers for your message broker is a doddle (RabbitMQ in my case) 5. Rerouting becomes very simple if your routes are designed for it. The cons where I wouldn't consider going with Camel: 1. If routing needs to be defined 'on-the-fly', especially if business users would be involved creating those routes. This would call for a more specific rules engine or a completely custom solution, depending on the use case. 2. If the integration points are 3 or less. I'd start considering a simple Camel app when I have to deal with more than 3 integration points (services/queues/folders I have to contact to get information from or send information to). 3. If there is no definable start or end of the information flows. In this case there is no need for any type of integration as the information sources are entirely unrelated to each other and integrating them would provide no benefit. Camel is meant to integrate things together so that they can fulfil a more complex task than each individual integration point (i.e. service) is providing. In your case below, if the microservices have routing logic in them or there are extra apps that cater for routing logic of requests, then that's where Camel routes can come in and do a much, much better job of it. The services should be just concerned about their own task and only their task (fetch product from DB, convert one type to another, provide API for a backend system, etc.). Hope this helps you out somewhat. Cheers, Valdis -----Original Message----- From: Ron Cecchini [mailto:roncecch...@comcast.net] Sent: 28 October 2019 13:44 To: users@camel.apache.org Subject: Pipelining : Camel routes vs. Microservice architecture CAUTION: This email originated from outside of Vhi. Do not click links or open attachments unless you know the content is safe. Hey, guys. It's kinda quiet here so I thought I'd ask for some thoughts... I recently got put on a relatively small project that's nicely utilizing a microservices architecture. There are about 8-10 services and they're using Kafka. The whole thing is about 10k lines of Kotlin, and they do use Camel but without any Spring whatsoever ("old school" Camel). Each service is containerized and deployed to the same node. This is the first time I've been exposed to Kotlin and (besides thinking Kotlin is the ugliest thing I've seen since Perl and that it's wicked over-hyped in terms of its supposed greatness over Java) I can't help but think that I could turn this entire pipeline into a single, Java-based, Spring Boot + Camel app in about a third of the code. I could effectively (and efficiently) recreate the pipeline with some simple Camel routes and processor/service/bean calls, and get rid of the message bus altogether. The Kotlin classes contain some simple logic branching based on the message type, and that could all be pulled out into the Camel routes as well. Has anyone done anything like this, refactored a multi-process MSA pipeline into a smaller, single Camel app? What are the pros and cons? The only "con" I can see is that the MSA approach can conceivably be scaled up depending on the data rates (i.e. use OpenShift to fire up more services as needed) whereas Camel can't (I think?) do that? Just curious... Happy Monday. Vhi Group DAC (Vhi) is a holding company for insurance and healthcare services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi Healthcare and Vhi Insurance DAC trading as Vhi Insurance are regulated by the Central Bank of Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for health insurance in Ireland which is underwritten by Vhi Insurance DAC. Vhi Healthcare is tied to Zurich Life Assurance plc for Vhi Life Term Insurance and Vhi Mortgage Protection which are underwritten by Zurich Life Assurance plc. Vhi Healthcare is tied to Collinson Insurance Solutions Europe Limited for MultiTrip Travel Insurance and Vhi Dental Insurance which are underwritten by Great Lakes Insurance SE and for Vhi International Health Insurance which is underwritten by Collinson Insurance Europe Limited. For more information about the Vhi Group please go to: https://www.vhi.ie/about-vhi. Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh seirbhísí árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC agus Vhi Investments DAC. Déanann Banc Ceannais na hÉireann rialáil ar Vhi Healthcare DAC, ag trádáil dó mar Vhi Healthcare, agus ar Vhi Insurance DAC, ag trádáil dó mar Vhi Insurance. Tá Vhi Healthcare ceangailte le Vhi Insurance DAC le haghaidh árachas sláinte in Éirinn, rud atá frithgheallta ag Vhi Insurance DAC. Tá Vhi Healthcare ceangailte le Zurich Life Assurance plc le haghaidh Árachais Saoil de chuid Vhi agus Árachas Cosanta Morgáiste de chuid Vhi atá frithgheallta ag Zurich Life Assurance plc. Tá Vhi Healthcare ceangailte le Collinson Insurance Solutions Europe Limited le haghaidh Árachas Taistil Ilturais agus Árachas Fiaclóireachta de chuid Vhi atá frithgheallta ag Great Lakes Insurance SE agus le haghaidh Árachas Sláinte Idirnáisiúnta de chuid Vhi atá frithgheallta ag Collinson Insurance Europe Limited. Chun tuilleadh faisnéise a fháil faoi Ghrúpa Vhi, tabhair cuairt ar: https://www.vhi.ie/about-vhi. This e-mail and any files transmitted with it contain information which may be confidential and which may also be privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unless you are the intended recipient you may not copy or use it, or disclose it to anyone else. Any opinions expressed are that of the individual and not necessarily that of the Vhi Group. If you have received this e-mail in error please notify the sender by return.
