Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This article is part of a series. For the previous article, see Moving an App Connect Flow Using MQ onto Containers.
One of the most common integration points is a database, and App Connect is well suited to connecting to a significant variety of datastores. One of the most common protocols used to connect to databases is ODBC, so that is the example that we will work through in this post.
In Scenario 4a, we showed you how to deploy an IBM MQ queue manager in a container using the Kubernetes (OpenShift) command-line interface (CLI). That showed that it’s really just a couple of commands and all the detail is really in the definition files. That’s certainly the approach you’ll want to move to for production so you can automate the deployment through pipelines. However, sometimes it’s useful to just be able to perform actions through a user interface without having to know the detail eg. command lines, and file formats, and that’s what we’re going to look at in this scenario.
IBM MQ Operator that we discussed in Scenario 4a will once again be used under the covers to perform the deployment. The operator also provides us with the user interface which, as you will discover, is neatly integrated with the OpenShift web console.
In Scenarios 2a and 2b, we showed different ways of deploying an App Connect flow onto containers on OpenShift – via the command line, and via the dashboard. We eventually saw a response from our deployed integration, but so what! We haven’t yet really seen what Kubernetes is bringing to the table. We will now explore some of the things that Kubernetes significantly simplifies and extends compared to traditional deployments. In this scenario, we’ll specifically look at load balancing and autoscaling.
If you feel you already understand basic load balancing and autoscaling in Kubernetes, perhaps take a look at the Advanced Scaling Topics section at the end of this post.
In Scenario 1 we took a simple flow from IBM Integration Bus and demonstrated we could get it running in IBM App Connect Enterprise on an isolated Docker container. This was a good start, but of course, in a real production environment, we would need more than just an isolated container. We would want to be able to create multiple copies of the container in order to provide high availability and to scale up when the incoming workload increases. We would also need to be able to automatically spread the workload across all those container replicas.
This and much more is what is provided by a container orchestration platform, and the most commonly used platform today is of course Kubernetes. In this scenario, we’re going to take that same simple flow and deploy it onto Kubernetes and demonstrate some of these orchestration platform features.
Many enterprises have IBM Integration Bus environments running hundreds of integration flows in production. You have likely read about the benefits of moving to containers, perhaps even more generally of agile integration, and you’d like to explore that. You’d also like to move to a more recent version of the product (now named IBM App Connect Enterprise). However, it is likely you have no, or at least a very limited background in container technology. How do you take the first steps to explore these new platforms and product versions?
In this series, we are going to describe how you move to containers running IBM App Connect Enterprise. We’ll build up to more complex examples, but for this first one we’ll take the simplest possible flow, and we’ll use a Docker container environment that can easily be run on a laptop.