Apache Camel is the most popular 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 three-part series, introduces the most important 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 flavor of Camel to implement your integration service.
Integration frameworks
Integration frameworks address the increasing needs of applications to work with a variety of outside 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 toward microservices, created a programming burden.
Integration frameworks such as Camel take this burden off the programmer. The framework makes popular 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 come 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 benefit from its rich functionality.
To deliver enterprise-grade integration, organizations hoped for a complete packaged solution 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."
For years, the dominant integration standard was OSGi, which originally stood for Open Services Gateway initiative. Apache Karaf implemented OSGi and became a very popular runtime for Camel (Figure 1). Karaf's highly modular architecture allowed programmers to easily and elegantly include all the functional layers mentioned previously (logging, monitoring, etc.). It also encouraged developers to create small Camel projects deployed as independent modules that could easily transition to the emerging microservices approach.
Java application servers were also very popular in the enterprise (and still 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 running 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 built, deployed, and managed. Kubernetes soon became the platform of choice, particularly for the more prominent organizations. When the number of integrations is limited, you might still 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 running on containers, the popularity of all-in-one solutions—Karaf, Wildfly, and other integration solutions from various vendors (many known as enterprise service buses, or ESBs)—faded away.
Standalone mode was still viable for running a limited number of integrations. However, Camel and Spring Boot quickly became a very popular combo for developers planning for a large number of services deployed in Kubernetes (Figure 3). Whether running on containers or not, the big microservices movement influenced integration teams to increasingly adopt smaller and more developer-friendly runtimes, and this soon became their preferred approach.
Fast-forward to the current scene, and you'll find Quarkus playing a pivotal role in ensuring Java's continued relevance (Figure 4). Quarkus saves organizations from investing effort to seek alternatives to Java. Quarkus also allows organizations to retain their codebase and preserves continuity.
Camel K: A new breed for Kubernetes
To open Apache Camel to a broader audience and lower the entry barrier to run integrations in Kubernetes, Camel K was conceived (Figure 5). It's a pill to eliminate the headaches of developers running 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 solving 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 benefit that Kamelets bring to the table 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 destinations. 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 automatic build and deployment of the integration process that executes your flow definition.
Current landscape
The quick timeline in this article helps us understand the many ways to run Camel. In summary, the most popular options are:
- In JVM containers: OSGi, Wildfly
- In Java runtimes: Spring Boot, Camel Quarkus
- As a native binary: Camel Quarkus
- Operator-based: Camel K (powered by Quarkus)
Coming up
This article provided a quick overview of the past, present, and planned future of Apache Camel. I explained 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 resources to learn more about Camel Quarkus and Camel K:
- Explore in more detail Camel Quarkus by reading Boost Apache Camel performance with Quarkus.
- Read the article Improve cross-team collaboration with Camel K to learn about Kamelet bindings and the DSL.
- Learn how to implement a complete API integration using Camel K and AtlasMap.
- A good place to start learning about Camel K is the Camel K topic page on Red Hat Developer.
- Visit the Red Hat Integration page on developers.redhat.com to see complementary capabilities around Camel.