HomeKubernetesChoose the best Camel for your integration ride, Part 1

Choose the best Camel for your integration ride, Part 1

Apache Camel is the most wellliked open source integration framework today. Over the years, Camel has evolved to support new environments such as containers on Kubernetes while continuously improving the developer experience—so much so that it’s now easy to consume by Kubernetes users with no previous Camel experience.

This article, the first in a 3-part series, introduces the most necessary ways you can use Camel and why each came into being. We’ll weigh factors such as performance, developer control, environment, and usability to help you understand and select the best taste of Camel to implement your integration service.

Integration frameworks

Integration frameworks address the increasing needs of applications to work with a variety of outdoors services: databases, message brokers, etc. In the past, each programmer would laboriously write custom code to connect and interact with a service. The availability of more and more services, and particularly the movement towards microservices, created a programming burden.

Integration frameworks such as Camel take this burden off the programmer. The framework makes wellliked services available to an application through a few lines of code.

In the following sections, we’ll examine the technical needs of different eras and the available Camel alternatives that user communities have approach up with to meet the demand. 

From traditional integration…

When Camel was conceived and developed as a Java library, it brought the tools to address and solve enterprise integration patterns (EIPs). Anyone could add Camel in their Java project as a dependency to advantage from its rich functionality.

To deliver enterprise-grade integration, organizations hoped for a complete packaged resolution rather than just an added library. Critical functions such as logging, monitoring, a management console, clustering, and support enable a product to become “enterprise-ready.”

Figure 1: Camel on Karaf.
Figure 1: Camel on Karaf.

For years, the dominant integration standard was OSGi, which initially stood for Open Services Gateway initiative. Apache Karaf implemented OSGi and became a very wellliked runtime for Camel (Figure 1). Karaf’s highly modular architecture allowed programmers to easily and elegantly include all the practical layers mentioned previously (logging, monitoring, etc.). It also inspired developers to create small Camel initiatives deployed as unbiased modules that could easily transition to the rising microservices approach.

 

Figure 2: Camel on Wildlfy
Figure 2: Camel on Wildly.

Java application servers were also very wellliked in the enterprise (and nonetheless are). Demand soon arose for support to run Camel on top of these servers. Wildfly (better known as JBoss), under the Jave EE specification, also became a Camel runtime choice (Figure 2). Although Wildfly was less suited to operating Camel than OSGi, it offered advantages for better integration with Java EE applications.

…to microservice architectures

The emergence of container environments revolutionized how applications were constructed, deployed, and managed. Kubernetes soon became the platform of choice, particularly for the more prominent organizations. When the number of integrations is restricted, you might nonetheless opt to run them in standalone mode, but Kubernetes is seen as the better choice when planning for many services.

In the face of new microservice and distributed architectures operating on containers, the popularity of all-in-1 solutions—Karaf, Wildfly, and other integration solutions from various distributors (many known as enterprise service buses, or ESBs)—faded away.

Figure 3: Camel on Spring Boot.
Figure 3: Camel on Spring Boot.

Standalone mode was nonetheless viable for operating a restricted number of integrations. However, Camel and Spring Boot quickly became a very wellliked combo for developers planning for a large number of services deployed in Kubernetes (Figure 3). Whether operating on containers or not, the huge microservices movement influenced integration teams to increasingly adopt smaller and more developer-friendly runtimes, and this soon became their preferred approach.

 

Figure 4: Camel on Quarkus.
Figure 4: Camel on Quarkus.

Fast-forward to the current scene, and you’ll find Quarkus playing a pivotal position in ensuring Java’s continued relevance (Figure 4). Quarkus saves organizations from investing effort to search alternatives to Java. Quarkus also allows organizations to retain their codebase and preserves continuity.

Camel K: A new breed for Kubernetes

Figure 5: Camel K.
Figure 5: Camel K.

To open Apache Camel to a broader viewers and lower the entry barrier to run integrations in Kubernetes, Camel K was conceived (Figure 5). It’s a pill to eliminate the complications of developers operating applications in Kubernetes and let them focus on what matters most: the business logic.

All you need to do to run an integration is to define its Camel route, full stop. Camel K is based on Kubernetes Operators. As soon as Camel K finds your definition, it builds the integration, creates an image, and deploys it for you. No more time spent fixing dependency conflicts—the Operator takes care of that and everything else.

Kamelets

Camel K also introduces Kamelets. These are predefined Camel routes (or snippets) you can pick and choose from an out-of-the-box catalog. The key advantage that Kamelets bring to the desk is to allow anyone with no previous Camel experience to use them; you just need to configure them. We will dive into Kamelets in more detail in the next installment of this series.

Camel K allows you to bind Kamelets together to connect sources and locations. You can, for instance, easily configure (declaratively) a data flow from a Java Message Service (JMS) broker to a Kafka platform. Camel K will do the rest: The moment you define your Kamelet binding, the Operator triggers an automated construct and deployment of the integration process that executes your flow definition.

Current panorama

The quick timeline in this article helps us understand the many ways to run Camel. In summary, the most wellliked options are:

  • In JVM containers: OSGi, Wildfly
  • In Java runtimes: Spring Boot
  • As a native binary: Camel Quarkus
  • Operator-based: Camel K (powered by Quarkus)
Figure 6. Choosing between various Camel runtimes.

Figure 6. Choosing between various Camel runtimes.

Coming up

This article provided a quick overview of the past, present, and planned prospective of Apache Camel. I defined how Camel has evolved in response to accelerating changes in markets seeking faster service delivery, increased scale of traffic, and management automation.

The next installment in the series will cover both standalone and container environments, show which Camel runtimes fit each, and elaborate on the new paradigms Camel K introduces and the possibilities it unfolds.

Learn more about Camel Quarkus and Camel K

See the following sources to learn more about Camel Quarkus and Camel K:

Source

Most Popular