No-code and low-code integrations with Camel and Kaoto

Apache Camel and the Kaoto graphical editor can work together to provide a no-code or low-code environment to simplify the integration of services into Kubernetes applications. Integrations with microservices and containers can be complex. This article introduces criteria for a no-code environment and shows how Apache Camel and Kaoto achieve this goal for microservices and containers.

The right director for your symphony

Several criteria have to be considered when choosing an integration framework:

• Functionality: The most obvious criterion is a framework that's as complete as possible. Our framework should feature not only Enterprise Integration Patterns, but also a wide range of connectors to different protocols and formats. We want to be able to extract, transform, and load data in a painless way. We would prefer not to write code or custom scripts to complement the framework.

• Connector extensibility: If we need to connect to some protocol or use some data format not currently supported by the framework, will we be able to extend it to cover our use case? What if we need to connect to services with noninteroperable authentication systems? Can we add custom building blocks to our orchestration workflow?

• Decoupling: A good integration framework must keep the interactions between components to a minimum so that the technical debt doesn't grow exponentially. We need to be able to upgrade the framework without breaking our services. And we want to be able to modify, extend, upgrade, and improve our services without worrying whether the integration will work.

• Usability: Ease of use, especially if we have complex use cases to maintain, helps keep our software architecture clean. But usability should never be detrimental to the functionality or extensibility of the framework. Sacrificing features in favor of user experience will make you hit the ceiling of your application's potential faster.

  If you want good usability, you can't tolerate bad documentation. Users want to have some reference to fall back on when something doesn't work as expected.

• Size: We don't want to drag a heavyweight dependency into our project, especially if the integration makes our application slower or imposes a bigger footprint on our hardware.

  Having a lightweight dependency usually also means less source code, and less source code means fewer opportunities to bring bugs into your software ecosystem.

• Multiple languages: We don't want to be tied to a specific language like Java or Python. Our library should be able to interact with a varied range of components and services.

  This flexibility is especially important if our citizen integrators or users come from different backgrounds, or are not very tech-savvy. We want them to feel comfortable in whatever language they need to orchestrate.

• Technical support: What if we have a problem? Is there someone we can pay for support—or maybe multiple someones? Having a wide range of companies offering technical support will improve our productivity in the long run.

• License: Whether or not there is a strong company behind the framework, only free and open source software (FOSS) protects us from the whims or misfortunes of any single company.

Fortunately for us, there is a framework that checks off all these criteria with excellent marks: Apache Camel.

Apache Camel

Apache Camel is an integration framework that automates the integration of databases, communication protocols, and other frameworks into your application. Camel offers many ways to achieve integrations.

Camel has its own domain specific languages (DSLs) that are extensions of, or are based on, existing programming languages and interoperable formats. Java, JavaScript, XML, YAML ... all of these languages can translate a simple Camel route into an integration that can be deployed (Figure 1).

Figure 1. Routes written in popular languages are processed by Camel to produceJava integrations.

Camel Quarkus

The Java code produced by Camel for an integration sometimes uses a bigger memory footprint than necessary. This waste is avoided through the Quarkus build for Apache Camel. Camel Quarkus looks exactly the same as creating traditional integrations with Apache Camel from the user or developer perspective, but brings all the developer joy of native builds and deployments to the integration world by providing Quarkus extensions for Apache Camel (Figure 2).

Figure 2. Apache Camel Quarkus works next to Camel to create integrations.

Camel K and Kamelets

Camel K provides Kubernetes-native integration for Camel orchestrations. With Camel Quarkus built in, Camel K deploys Camel integrations to your Kubernetes cluster and monitors the connections during runs.

But Camel K offers much more than just Kubernetes integrations. You can use Kamelets to simplify your integration definitions (Figure 3). Kamelets are snippets of Camel routes that act as metasteps in an integration, hiding complexities in otherwise simple orchestrations.

Figure 3. Kamelets are input to Kamel K to produce integrations for Kubernetes.

No-code integrations with Kaoto

The obvious missing step in the previous diagrams was a visual editor that can transform the graphical representation of the workflow into source code, allowing people to integrate new services and connections without writing a single line of code. The desire to make integration frameworks accessible and easy to use is not new. There have been different approaches to a graphical solution to this problem; these always come back to the question of how to visualize source code without exceeding the Deutsch limit, which states that you shouldn't have more than 50 visual primitives on your screen at the same time.

At Red Hat, we have been searching for a free and open source tool for no-code or low-code integration that uses Apache Camel. Not finding a suitable tool, we decided to create Kaoto. Figure 4 shows how it sets up the whole workflow. The primitives or building blocks of Kaoto are steps in an Apache Camel integration DSL: Kamelets, Camel components, or Enterprise Integration Patterns.

Figure 4. Kaoto produces the Kamelets, bindings, and routes as input to Camel K.

We wanted Kaoto to have a simple user interface that provides building blocks for integrations with drag-and-drop manipulation. At the same time, we wanted our users to be able to manipulate the source code. With this flexibility, Kaoto can be transparent about what the users are building and users can safely deploy integrations without blindly trusting the integration editor.

What does a no-code integration look like?

In a no-code solution, there is no need to interact with or even see the source code at any point. The user can focus on bringing integration capabilities to their architecture without worrying about implementation details. Figure 5 is an animation showing Kaoto adding a logging service to an application.

Figure 5. Kaoto lets users create an integration through searches and clicks.

What does a low-code integration look like?

A low-code solution allows the user to view and interact with the source code to deploy an integration. The user can focus on the features being implemented without knowing how to write the source code. The source code appears as an adjacent add-on or guide to help new users get familiar with concepts. Figure 6 is an animation showing Kaoto adding a Kafka broker to an application with source code displayed.

Figure 6. Kaoto lets users interact with code through searches and clicks.

You can find more use cases and examples on the Kaoto website. Kaoto is the next big step in the ongoing quest to simplify the integration of multiple capabilities into an application.