Integration Modernization in Action

81% of enterprises are participating in a multi-cloud strategy; 51% are deploying a hybrid cloud solution which combines the public & private cloud — Liftr Cloud Insights

With the rise of a multi-cloud strategy, it is becoming crucial to re-think the hybrid cloud integration strategy as well. With the unexpected workloads and variance types of environments, agility, scalability, and adaptability are critical characteristics that must be available on modern integration solutions. To reach such an architecture, we can take a look into the cloud-native design pattern, as one of the benefits of modernizing monolithic applications into micro-components is the agility to independently amend and replace components as needed. Taking the same principles and applying them into the integration platform will empower organizations to adapt to the changes.

The concept is called Agile Integration Architecture (AIA). It is an approach that relies on decentralized integration layer, and it benefits from the containerization and API technology. There are three main pillars in AIA:

Fine-grained Integration Deployment

One of the challenges of traditional integration is the coupling among the components, regardless of their relationships between one another. When a simple modification is done to the environment, such as an upgrade, it might cause several issues for all the integrations. Moving from a huge centralized integration hub into a more fine-grained integration layer, each of the integration services are running independently in small and independently managed components.

Decentralized Integration Ownership

The cloud-native pattern impacts an organization’s culture where a team can be formed by a business-focused and a project (service) requirements. For instance, a single group might be a mix of a developer, integrator, designer and consultant. The team has full autonomy and confidence to make changes without impacting other services. Another aspect is the increase in expertise since teams focus on what their responsibilities are; this brings a new level of productivity and innovation.

Cloud Native Integration Infrastructure

A part of the transition is applying the cloud-native “cattle not pet” approach with the support of technologies such as Docker Containers and Kubernetes. It takes seconds to create or dispose of containers to scale the workloads up and down. A considerable improvement is the startup time because containers are running in a shared host which eliminates the need to reproduce the operating system when a container starts or stops.

If you’re interested to learn more about the concept, check out articles by @KimClark : and others Agile integration architecture: Useful links

Let’s move on to the fun part! In the next section, I will demonstrate a few steps on how to get started with modernizing (containerized) your integration solution; also, we will test the portability of the solution into two different cloud environments: IBM Cloud Private & Google Cloud Platform.

  1. Create a container image.
  2. Push the image to the cloud registry.
  3. Run the application on multi-clouds.


  • IBM App Connect Developer Edition: a platform that supports the full breadth of integration needs across a modern digital enterprise.
  • Docker Containers: a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings from one computing environment to another.
  • Kubernetes: an open-source system for automating deployment, scaling, and management of containerized applications.

I have prepared a simple integration flow, which can be invoked via an HTTP POST operation. Also, I have used the pre-built Cloud connectors to integrate with other 3rd parties systems such as SAP, Salesforce and Slack. On this stage, we will only need to use the BAR file. Navigate to your directory which where you saved the BAR file; then follow the next steps.

IBM App Connect Enterprise v11 — Get started

1. Create Dockerfile

Use the following file to create your Dockerfile for the integration solution. You need to insert your BAR file name on line 3.

2. Build Container Image

$ docker build -t <hostname>/<namespace>/<image-name>:<tag> .

For example:

$ docker build -t cluster.icp:8500/default/myintegration-flow:1.0 .
Note if you are deploying into Google Cloud, then follow this schema

3. Push Container Image

$ docker login <cluster-registry-address>
$ docker push <hostname>/<project-id>/<image-name>:<tag>

For example:

$ docker login cluster.icp:8500
$ docker push cluster.icp:8500/default/myintegration-flow:1.0

4. Create the Deployment File

By now you should have the Docker image ready, you can check by running the following command:

$ docker images | grep myintegration-flow

To start deploying your integration solution into Kubernetes environments, we will begin by creating the deployment file which includes the solution/app definitions; i.e., the image path and environment variables. Also, you can define the multiple instances (replicas) of the same app to make your app resilient (line 8).

Save the file in your directory, and run the following command:

$ kubectl create -f deployment.yaml
deployment/myintegration-deployment created

5. Create the Service File

Your deployment should be ready to expose for external users/app to consume your integration solution. We will use Kubernetes Service to define a logical set of pods and a policy to access the service, such as protocols and ports. Similar to step 2, use the following .yaml file:

Save the file in your directory, and run the following command:

$ kubectl create -f service.yaml
service/myintegration-service created

Double check the status of your app by running the following commands

$ kubectl get po
$ kubectl get svc
IBM Cloud Private Environment & Google Cloud Environment

Both environments are running my integration solution fine, and Kubernetes is taking care of incoming port traffic and mapping them to our target ports; i.e., 32060 → 7600 on IBM Cloud Private and 31318 → 7600 on Google Cloud Platform. Let’s get the node public IP address to check our service

$ kubectl get node --output=wide

Then, form your url like the following:


Here’re my outputs from the two environments

In a few steps, we took one integration solution, containerized it then deploy it on multi clouds environments (IBM & Google). You can apply the same measures on any other integration apps/solutions, and still, you maintain your integration platform agile, scalable and adaptable. The secret behind this is the integration runtime. IBM App Connect Enterprise (ACE) is providing a lightweight integration runtime for cloud-native and container-based deployment. Similar to ACE, all other IBM integration components are ready-made for container-based implementation to support your multi-cloud strategy through a complete platform: IBM Cloud Integration Platform.