Chapter 1. Overview of migrating Fuse 7 applications to Camel Extensions for Quarkus
Fuse
Red Hat Fuse is an agile integration solution based on open source communities like Apache Camel and Apache Karaf. Red Hat Fuse is a lightweight, flexible integration platform that enables rapid on-premise cloud integration.
You can run Red Hat Fuse using three different runtimes:
- Karaf which supports OSGi applications
- Spring Boot
- JBoss EAP (Enterprise Application Platform)
Camel Extensions for Quarkus
Camel Extensions for Quarkus (CEQ) brings the integration capabilities of Apache Camel and its vast component library to the Quarkus runtime. Red Hat build of Camel Quarkus provides Quarkus extensions for many of the Camel components.
Camel Quarkus takes advantage of the many performance improvements made in Camel 3, which results in a lower memory footprint, less reliance on reflection, and faster startup times.
In a CEQ application, you define Camel routes using Java DSL, so you can migrate the Camel routes that you use in your Fuse application to CEQ.
Camel on EAP
Karaf, which follows the OSGI dependency management concept, and EAP, which follows the JEE specification, are application servers impacted by the adoption of containerized applications.
Containers have emerged as the predominant method for packaging applications. Consequently, the responsibility for managing applications, which encompasses deployment, scaling, clustering, and load balancing, has shifted from the application server to the container orchestration using Kubernetes.
Although EAP continues to be supported on Red Hat Openshift, Camel 3 is no longer supported on an EAP server. So if you have a Fuse 7 application running on an EAP server, you should consider migrating your application to the Red Hat Build of Apache Camel for Spring Boot or the Red Hat build of Apache Camel Extensions for Quarkus and take the benefit of the migration process to consider a redesign, or partial redesign of your application, from a monolith to a microservices architecture.
If you do not use Openshift, RHEL virtual machines remain a valid approach when you deploy your application for Spring Boot and Quarkus, and Quarkus also benefits from its native compilation capabilities. It is important to evaluate the tooling to support the management of a microservices architecture on such a platform.
Red Hat provides this capability through Ansible, using the Red Hat Ansible for Middleware collections.
1.1. Standard migration paths
1.1.1. XML path
Fuse applications written in Spring XML or Blueprint XML should be migrated towards an XML-based flavor, and can target either the Spring Boot or the Quarkus runtime with no difference in the migration steps.
1.1.2. Java path
Fuse applications written in Java DSL should be migrated towards a Java-based flavor, and can target either the Spring Boot or the Quarkus runtime with no difference in the migration steps.
1.2. Architectural changes
Openshift has replaced Fabric8 as the runtime platform for Fuse 6 users and is the recommended target for your Fuse application migration.
You should consider the following architectural changes when you are migrating your application:
- If your Fuse 6 application relied on the Fabric8 service discovery, you should use Kubernetes Service Discovery when running Camel 3 on OpenShift.
- If your Fuse 6 application relies on OSGi bundle configuration, you should use Kubernetes ConfigMaps and Secrets when running Camel 3 on OpenShift.
- If your application uses a file-based route definition, consider using AWS S3 technology when running Camel 3 on OpenShift.
- If your application uses a standard filesystem, the resulting Spring Boot or Quarkus applications should be deployed on standard RHEL virtual machines rather than the Openshift platform.
- Delegation of Inbound HTTPS connections to the Openshift Router which handles SSL requirements.
- Delegation of Hystrix features to Service Mesh.
