Posted on

How to Move IBM App Connect Enterprise to Containers

This article is part of a series and follows the previous article, Deploying a Queue Manager from the OpenShift Web Console.

IBM App Connect Enterprise was initially created at a time when much integration was performed using messaging, and specifically IBM MQ. Indeed, despite the popularity of more recent protocols such as RESTful APIs, there are still many integration challenges that are better suited to messaging. Today, IBM App Connect Enterprise is used to mediate various protocols, but nearly all existing customers will have some MQ-based integration in their landscape.

Posted on

From IBM Integration Bus to IBM App Connect Enterprise in Containers (Part 4b)

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.

Installing the IBM MQ Operator

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.

Posted on

How to Move IBM App Connect Enterprise to Containers (Part 4a)

This blog is part of a series, link back to Part 3 to explore the earlier articles.

In the following scenarios, integrations with IBM MQ are used. When we move IBM App Connect into containers, the recommendation is that wherever possible, we should move to working with MQ remotely. This is highly preferable to having a local MQ server residing alongside App Connect since it allows Kubernetes to fully take over the administration of scaling and high availability of the components. This is part of a broader common practice around containerization, noting that each container should have only one job.

Posted on

IBM MQ in ECS on AWS Fargate

AWS Fargate is a serverless compute resource specifically designed for running containers. With AWS Fargate the deployment and management of the container(s) are controlled by either Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS).

Initially, users often get confused by the relationship between Fargate and the container management solution (EKS or ECS). Therefore, I want to labor the point of the difference, when deploying a container within the context of an enterprise, any solution will include two components:

Posted on

Building AMQP-Based Messaging Framework on MongoDB

Introduction

In any integration scenarios, messaging needs are inevitable. There are several messaging frameworks /tools/technology available today to chose from. Starting from old MQ we have come a long way to the world of open source-based technologies like Kafka, RabbitMQ, ActiveMQ, etc. Every other messaging frameworks came due to certain needs. With the growing trends of microservices, engineers are looking for more lightweight, independently deployable, and less costly options in the market. Every messaging framework comes with the baggage of additional infrastructure and maintenance headache. In one of my projects there has been a proposal to use the capped collection feature of MongoDB along with its tailable cursor as an alternative option to deploy any real messaging infrastructure. Now the question arises,

  • Is this option suitable for all kind of messaging needs?
  • Can it be a replacement of proper messaging framework like Kafka, RabbitMQ, etc.?
  • What are the pitfalls?

Not to mention that this feature of MongoDB is quite old and well-known in the market and you will find a lot of articles around it. However, I believe those articles have just shown the basic way of enabling it without going deep into it. A real messaging framework has lots of challenges than just making an asynchronous way of delivering the messages. In this series of articles, we will try to address them and see if we can really build some messaging infrastructure using MongoDB by considering all the needs of a messaging framework.