Build reactive apps on Kubernetes using Camel K

November 7, 2022
Sumit Mukherjee
Related topics:
KafkaKubernetesOpen Source CommunitiesServerless
Related products:
Red Hat OpenShift Container Platform

A reactive application meets modern requirements for customer-facing services. Reactive applications are message-driven, elastic, responsive, and resilient. Common traits of reactive applications include:

Events play a major role in these types of applications. Events are not new, but event-driven architectures are gaining in popularity and use asynchronous message queue technologies such as RabbitMQ, Apache ActiveMQ, WebLogic, and IBM MQ. In this article, you'll learn how Apache Camel K can make it easier to develop reactive applications on Kubernetes by integrating data sources, Apache Kafka brokers, and Knative for event management.

Why choose Camel K?

Apache Camel K is a Kubernetes-native cloud integration platform based on Apache Camel. Apache Camel is popularly known as the Swiss army knife of integration. Camel 2.x can integrate a wide range of endpoints, transform data into and out of different formats, and process data using prebuilt enterprise integration patterns.

The release of Camel 3 in 2019 introduced Camel K. This framework creates integrated, modular, lean, and fast applications and functions that are inherently reactive. Such applications and functions can run serverless on Kubernetes or Red Hat OpenShift clusters. The cluster can be hosted on a public, private, or hybrid cloud or using on-premises infrastructure.

Camel K combines the well-known Camel components and connectors with the low boot times and memory consumption of the Quarkus Java platform. Quarkus gives programmers built-in tools for making applications that are based on message forwarding and are responsive, elastic, and resilient. To interact with many types of systems, Quarkus offers these capabilities through extensions. Each new release of Quarkus adds more extensions, enabling more reactive features.

How Camel K enables reactive applications

To build a reactive application, an integration specifies the sources and destinations (sinks) of interactions. This configuration is referred to as binding in the Camel K universe. Camel K introduces the concept of Kamelets, which configure both sources and sinks. So to build a reactive application, you just need to connect a source Kamelet to a sink Kamelet.

As an example, imagine an e-commerce website that dynamically updates its masthead banner in real time with information on the ten fastest selling items. The application accomplishes this task through a microservices-based architecture with Kafka topics as the communication medium. The application couples the Kafka topic listing customer orders to an Infinispan cache that stores the names of the sold items. The web application then fetches information on sales from the Infinispan cache and updates the masthead in the client browser over WebSockets. Figure 1 shows the elements of this solution.

A basic architecture for real-time, reactive updates to a web page uses Kafka, connected through Camel K.
Figure 1: A basic architecture for real-time, reactive updates to a web page uses Kafka.

Apache Kafka is one of the most widely used platforms for event streaming. Traditionally, however, applications would have to be Kafka-integration aware and would have to orchestrate data to flow it into Kafka clusters. Alternatively, the applications would use Debezium connectors. Camel K hides the details of Kafka messaging.

Another valuable feature of Camel K is the action Kamelet, which can be illustrated through two new business demands in our example application. Suppose that an item can be listed as one of the top selling items only when the price exceeds $1,000. Additionally, to prevent unintentional disclosure of credit card numbers recorded in messages listing customer orders, the application must mask the credit card field.

An action Kamelet carries out specific activities on messages passed in by a source Kamelet. To satisfy our two new business demands, the developers create an action Kamelet that filters entries based on the price field and hides the credit card field. Figure 2 illustrates the new architecture.

The application adds a Camel K action to filter information before it goes to the web page.
Figure 2: The application adds a Camel K action to filter information before it goes to the web page.

Going serverless with KNative

Businesses are highly conscious of the costs associated with running applications in the cloud and want to get the most out of their cloud investments. A serverless computing option is one way that cloud providers today offer even more cost savings.

Camel K, in conjunction with Knative, provides reactive applications that can be automatically instantiated on source triggers and that scale to zero when no traffic is present. Furthermore, such serverless functionality is available on any cloud that can host a vanilla Kubernetes or OpenShift cluster.

Suppose you want to add the following added business requirements to our sample application:

  • If the price of an item is higher than $4,000, an email message must be sent to the purchaser for confirmation purposes.
  • Since the entire solution is reactive, the business wants to minimize compute costs caused by idle polling during periods of no activity or traffic.

Figure 3 shows a possible architecture that meets these requirements. A notable change is the use of Knative channels that decouple the source Kamelet (the Kafka topic) from the action and sink Kamelets (the Infinispan cache and email server).

The application adds Knative to manage messages.
Figure 3: The application adds Knative to manage messages.

Benefits of Camel K and Knative

The solutions illustrated by this article have the following advantages over older server technologies:

  • Portability: Camel K is a Kubernetes-native runtime, so applications can be managed as Kubernetes objects. Applications behave consistently across any platform, both in the cloud and on-premises, wherever Kubernetes or OpenShift is running.

  • Open source with no lock-in: With active contributions from the community and enterprise open source companies such as Red Hat, new and innovative features are always being added and upgraded to Camel, with no vendor lock-in.

  • Proven technology: Camel is one of the most famous integration frameworks, with industry-tested and established connectors. Camel K makes it possible for you to further modernize your application while still enjoying Camel's reliability.

  • High return on investment: Camel K helps you create integrated applications and event-driven, reactive applications and also go serverless with your enterprise processes. This all takes place within a single framework and leaves room for more.

Learn more about Camel K and Knative

The following documentation and web sites offer more background on the technologies discussed in this article.

Last updated: October 20, 2023