Build reactive apps using Camel-K

Overview

EDA is one of the newest and most popular emerging technologies. Events as a concept are not new. The use of messaging queue technologies like RabbitMQ, Apache ActiveMQ, Weblogic, IBM MQ by asynchronous applications to exchange messages and events is fairly prevalent.?

Businesses of today want applications that need modern technology paradigms like event streaming, change data capture (CDC), data integration, distributed integration, and function as a service (FaaS). This is due to the rise in cloud native applications and at the same time, containers and hybrid cloud architecture becoming commonplace.

One of the most widely used platforms for event streaming is Apache Kafka. However, in most cases, the applications have to be kafka-integration aware and data must be orchestrated to be flown into Kafka clusters (with the exception of Debezium connectors).?

The most recent supersonic Java runtime, called Quarkus, gives programmers built-in tools for making applications that are responsive, elastic, resilient, and based on message forwarding. In order to interface with many systems, Quarkus offers these capabilities through extensions, and with each new release, more extensions are added, enabling more reactive features.

Alternatively, there is Apache Camel, one of the most popular open source libraries for integrating applications, also popularly known as the Swiss army knife of integration. With Camel 2.x, developers could integrate a wide range of endpoints, transform data into and out of different formats, and process data using pre-built patterns (known as Enterprise Integration Patterns, or EIPs, for short).

With the release of Camel 3 in 2019, the Camel-K project was introduced to the world. Camel-K combines the well known Camel components and connectors with the low boot times and memory consumption of Quarkus. This allows developers to create integrated, modular, lean and fast applications and/or functions that are inherently reactive and configurable as serverless on Kubernetes/Openshift clusters running on public/private/hybrid cloud or their on-premise infrastructure.

In this article, we'll examine just how Camel-K enables reactive applications on Kubernetes and why you should care about it at all.

EDA : Being reactive featuring Camel-K

In order to build a reactive application, one needs to be able to specify the source of the interaction and the destination to which it should be connected when such a source is activated. Such a configuration is referred to as "binding" in the Camel-K universe. Camel-K introduces the concept of Kamelets. A kamelet is just a YAML version of a camel route snippet. A kamelet has the ability to function as both a sink and a source component. So to build a reactive application, we just need to connect a source kamelet to a sink kamelet.

?Let's take an e-commerce website as an example, which wants to dynamically update their masthead banner in real time with information on the top 10 fast-selling items. This might be easily accomplished by coupling the order topic to an infinispan cache to store the name of the sold item (assuming a microservices based architecture with topics as the communication medium). The web application can then fetch from Infinispan cache and update over WebSockets, updating the masthead in the client browser. A possible solution architecture can be represented diagrammatically as follows.

?So far, so good. But what about processing source data while it is being transmitted? Camel-K additionally has an action kamelet to address such a need. A kamelet that can carry out specific activities in response to a source kamelet trigger is known as an action kamelet.

?Assume a business demand has arisen, using the previous section's case as an example. Only when the price exceeds $1,000 must the piece be listed as one of the top selling items on the website. To prevent unintentional disclosure of credit card numbers recorded in order microservice messages, it is also necessary to mask them. Such a demand can be easily met by an action kamelet that filters entries based on pricing and hides the CC number entry. For the sake of simplicity, imagine the order messages as shown in the diagram below. As shown below, action kamelets can be used to implement a possible solution to the new business requirement.

?EDA: Being serverless with KNative

Businesses are well aware of the cloud costs associated with cloud native applications, and they want to get the most out of their cloud investments. The serverless computing option is one way cloud providers today offer even more cost savings. AWS Lambda functions and Microsoft Azure Azure functions are popular choices for developers when developing serverless applications. These solutions, however, are only available on the respective provider clouds, as of this writing.

Camel-K, in conjunction with Knative, another popular open source project, provides reactive applications that can be automatically instantiated on source triggers and scale to zero when no traffic is present. Furthermore, this serverless feature is available on any cloud that can host a vanilla Kubernetes or Openshift cluster. This enables businesses to build truly elastic and cost-effective enterprise applications that are cloud agnostic, allowing them to future-proof their cloud investments.

Let’s suppose that a new business requirement has cropped up on our e-commerce example application. Key aspects of this requirement are :

1. In case the price of an item is higher than $4000, an email must be sent to the purchaser for confirmation purposes.?
2. Since the entire solution is reactive, business wants a solution to minimize compute costs due to idle polling during periods of no activity or traffic.

Both requirements can be easily met using Camel-K and Knative, with minimal changes to the existing solution. First, we must decouple kamelets from event producers and consumers by introducing a knative channel. As many additional kamelets can thus be chained to perform additional tasks, for instance, in this case sending an email in the event of a high-priced item purchase. Second, the kamelets can now scale up/down and execute only with traffic, significantly lowering cloud costs. A possible reference architecture for this solution may be as shown below.

Benefits of Camel-K + Knative

• Portability and no cloud lock-in.

Camel-K is a Kubernetes native runtime and as such all applications developed can be managed as Kubernetes objects. Applications behave consistently across any platform regardless of cloud / hybrid / on-prem infrastructure where Kubernetes / Openshift is running.

• Proven technology

Camel is one of the most famous integration frameworks with industry proven and established connectors. With Camel-K, the same trusted reliability of camel can be re-used while modernizing the applications.

• High Return on Investment

Investing in solutions based on Camel-K gives you the choice of creating integrated applications or event driven reactive business applications and also go serverless with your enterprise processes. All within the same framework and leaves room for more. With active contributions from the community and enterprise open source companies like Red Hat, new and innovative features are always being added/upgraded with no vendor lock-in.

Learn more about Camel-K and Knative

1. Apache Camel-K project website : https://camel.apache.org/camel-k/next/
2. Knative project website : https://knative.dev/docs/
3. Getting started with Red Hat Camel-K : https://access.redhat.com/documentation/en-us/red_hat_integration/2022.q3/html/getting_started_with_camel_k/index
4. Community kamelet catalog : https://camel.apache.org/camel-kamelets/0.9.x/index.html
5. Red Hat kamelet catalog : https://access.redhat.com/documentation/en-us/red_hat_integration/2022.q3/html/kamelets_reference/index
6. Knative and Camel-K tutorial : https://redhat-developer-demos.github.io/knative-tutorial/knative-tutorial/index.html
7. Red Hat learning path - Develop with Camel K : https://developers.redhat.com/learn/camel-k