In this inaugural post I am going to describe a bit about what made me choose to work with Camel and Karaf and what you gain and lose compared to its commercial competitors such as IBM Integration Bus. In essence, what things should you look out for when deciding on your integration platform?
Having worked with the IBM WebSphere Message Broker for more than 8 years you get used to its philosophy, concepts and tooling. Its when you step outside that you realize other tools work differently.
Most commercial tools follow a somewhat similar conceptual model but how they implement it can very significantly. However if you are about to start choosing an integration platform, here are some things you should look out for:
- If you are not familiar with the vendor landscape for integration, start with reading Gartner and Forrest reports to just get a feel. Don’t base your decision on them, rather use them to get a feel for who are the players and then use the list for an evaluation.
- Forget about fancy vendor demos. They are done in an idealized situation with an extremely simple scenario. No real life integration is like that. Demos are good to peak but not to base your decision on. Ideally, download their tooling and see how long or hard it is to create your own demo. Get a feel for the tooling yourself.
- Clearly understand your integration requirements. Talk to system owners and people who need integration to understand why and what role it will play.
- Understand your message formats and protocols, will it be used to connect to legacy systems or use modern REST and JSON?
- Cost is off course important. Try to do a total cost of ownership analysis to see how much your tooling, license, OS etc will cost in the next year, three years, and 5 years to see where it aligns with your budget.
- Is the vendor innovating its integration platform and attracting new customers?
- How does the licensing and support model of the vendor work?
The above are just a handful of questions you need to address before making a decision.
Now, now what about Camel?
Let us get one thing straight first and that is cost. Apache Camel is free. It does not cost you one dollar to use. IBM software usually costs a lot, probably more than 80 000 USD and the pricing model can be very complicated. Already you have one big difference.
However, the comparison is not fair even if there is a huge price difference. IBM’s Integration Bus is complicated piece of software that is the complete packaging, from routing, transformation to tooling and run-time. It contains all aspects of development and run-time administration. Apache Camel is first and foremost a framework and its strength lies in its simplicity and extensive routing capability. However due to its lightweight nature you are also responsible for the development tooling, finding a suitable run-time and handling monitoring and administration. Here the differences depends very highly on your needs. Camel places a far greater responsibility on the developer. It see the developer as the main person working with integrations.
I would say from personal experience that the biggest difference between the two is in the transformation part. I have never seen a better transformation tool than the Integration Bus message parsers. The concept of parsers and the ability to use them and refer to fields and messages in real time is highly helpful when you are developing mapping of data. In contrast Camel, being purely a programming language framework cannot use the concept of parsers and hence for transformation you need to either map to a java object (pojo) first or use external tools such as smooks or similar. For me, this is the single biggest difference and the one part of tooling you miss when you leave the IBM world.
I finally decide on the following components for the platform that I am working with:
- Apache Camel for routing and development. Why?
- It is free.
- Avoiding vendor locking.
- Simple to use.
- Based on java so easy to get started.
- The team innovates and fixes the framework and it is standard for integration in the open source world.
- Uses patterns based on Enterprise Integration Patterns book.
- Not tied to a specific run-time.
- There are many more reasons but one final one is that it is very lightweight but at the same time contains exception handling, error handling, testing, mocking and many more advanced features.
- Apache Karaf for OSGI run-time environment.
- Karaf is very light weight, just a zip file and you are good to go.
- It contains many advanced features missing in commercial tools.
- Deployment is extremely easy.
- It works with Camel in a relatively straightforward manner.
- The logging framework is great.
- Administrating bundles is also very easy. There are even specific camel commands so that makes life really nice when deploying camel routes.
- It supports installing Hawtio and Apache ActiveMQ inside its run-time.
- Hawtio for webconsole.
- Hawtio is great to debug, profile and view your camel routes. You can also view the Karaf logs, manage your camel routes and much more.
Finally, after having used Camel now for about one month, I have to see I am pleasantly surprised because it has a lot of functionality for being open source and even functionality not found in commercial software. One huge benefit I think working with Camel and its ecosystem is that you gain a more in-depth understand of software, development and get to hone your skills more. You are not just an expert at a specific vendor tool, instead you can I definitely need to read the documentation more and understand some best practice but one step at a time 😉 Thanks for tuning in.