Deep dive into a scalable enterprise integration platform with MuleSoft and OpenShift

Summary

Service integration in an enterprise environment is a complex task. The integration platform must be flexible enough to support integrations with legacy systems and at the same time provide a future-proof foundation for modern use cases throughout the business. Like any other workload, an integration platform should support deployment to a container platform for optimal scalability and strict resource control.

On the other hand, this topic is absolutely crucial for software development in complex organisations. How else would you align interface changes, develop with different teams in different circles and manage application connectivity in hybrid- / multi-cloud environments?

This question we want to tackle in this article by discussing how MuleSoft’s Runtime Fabric (RTF) deployed to Red Hat OpenShift delivers this modern containerized solution, be it on-premise, in a cloud or hybrid environment. But what exactly does this mean in practical terms?

What to expect in this article

What are the products MuleSoft and OpenShift
Why an API solution is crucial for efficient software development and system integration
Why Red Hat has a strategic partnership with MuleSoft

and we will show two practical examples:

A Point of View how to run MuleSoft and OpenShift in a hybrid cloud environment, detailing:

How to choose the number of OpenShift clusters
Which environment to place on-prem and which in the cloud
How the API platform with MuleSoft RTF in this setup works
What the capability map and a blueprint architecture look like

As the second practical example we will show how to get MuleSoft RTF running on OpenShift.

At the end you will find a summary around the key takeaways.

So, first let us have a look at the business proposition.

WHERE is the benefit in driving an API strategy

69% of organizations are taking a top-down approach to integration and API strategy.¹

68% of organizations are using containers and Kubernetes technology.²

29% of the average organization’s 800 apps are integrated.¹

Application programming interface (API) management has become a key consideration for businesses. In fact, 69% of organisations are taking a top-down approach to developing an integration and API strategy.¹

And 68% of organisations are using containers and Kubernetes technology.²

However, it’s an uphill battle. The average organisation runs more than 800 applications, and only 29% of them are integrated.¹

To grow and innovate at speed, you need standardised, integrated solutions that provide flexibility without compromising on security.

In other words, to operate off-the-shelf software or develop custom software effectively and stay competitive in the future, a sophisticated API approach is out of question.

Let us now spare some words on the two key players in this blog.

WHAT is MuleSoft’s Anypoint Platform

MuleSoft is the middleware suite from Salesforce and one of the biggest (if not the biggest) players in the market of application integration and API platforms. MuleSoft’s Anypoint Platform provides tools for service integration, API management and automation. The platform comes with numerous prebuilt assets such as connectors and templates to deliver fully integrated services fast and scalable.

The key qualities of Anypoint Platform are:

Low- or no-code development with AI-assistance and the option to add custom code if needed
Powerful control panel to govern and manage APIs and integrations in SMB and enterprise environments
Capability to connect to any source or destination system and transform messages in transit, be it event-based, scheduled or in a synchronous manner
Deploy the runtime components to a self-hosted, a public cloud or to MuleSoft’s PaaS.

WHAT is OpenShift

OpenShift is a family of containerization software products developed by Red Hat. Its flagship product is the OpenShift Container Platform — a hybrid cloud platform as a service built around Linux containers orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux.

It is an out of the box container platform with all you need to start developing, building, deploying and running containers at scale.

WHY the strategic partnership between Red Hat and MuleSoft

With its portability OpenShift can be seen as a real multi-cloud enabler. But there is no efficient development without an API platform as we saw in the previous chapter.

MuleSoft fills this gap by ensuring all services running on OpenShift or elsewhere have the data they need to deliver their full value.

Besides that, RTF profits from the capabilities OpenShift provides by running on it despite the underlying infrastructure. This is a clear win-win situation.

So, it makes absolutely sense to have a strategic partnership and to leverage benefits from each other.

But enough of theory. Let’s dig into the technical background of our blog by elaborating on the two use cases.

Point-of-View of HOW to run MuleSoft and OpenShift in a hybrid cloud environment

As promised we want to start with a potential use case:

Use-Case

Our setup should have Development (DEV) and System Integration Testing (SIT) running on a hyperscaler. Just imagine the customer wants to use some fancy services there.

But for User Acceptance Testing (UAT) and Production (PR) he wants to get back on prem.

Capability Map

The capabilities of the OpenShift and the Anypoint platform complement each other with very little overlap. OpenShift primarily provides the infrastructure for the container workload to run and scale, and the capabilities to isolate workloads in a secure fashion through dedicated namespaces and projects. It also provides network connectivity and enterprise-grade workload monitoring and security capabilities, such as secrets management.

OpenShift’s operator catalogue provides templated deployments including MuleSoft’s RTF operator

MuleSoft’s Anypoint Platform consists of one control panel delivered as SaaS and one or several runtime environments which, in the context of this article, are deployed to OpenShift through the RTF operator.

All administrative, governance and operations capabilities of Anypoint Platform are delivered through the control panel while the actual service-to-service communication only traverses through the runtime components.

So, from the capability overview, you can see once again why this technology partnership between MuleSoft and OpenShift makes so much sense.

Let’s dig a bit deeper into the use case and start with a possible high-level blueprint.

High-level Blueprint

So, we decided to run four OpenShift clusters.

The first hosts DEV and as such triggers the CI/CD pipeline
Then we run a second cluster for SIT based on synthetic data
For UAT we go back on-prem and use anonymized or production-near data
Finally, the fourth cluster is for the PR workloads

Every cluster runs MuleSoft via the RTF operator (please see next chapter on how to install MuleSoft on OpenShift).

DEV would hold all development and build + deployment elements. Of course we would have run RTF on the DEV cluster as well as on all the other three clusters representing the different test stages + PR.

But now the big question is, how does this setup work from a CI/CD perspective? And how is an interface change done on DEV reflected on the two test stages as well as on PR?

All clusters are linked to the same MuleSoft layer called Control Panel. Here the magic happens between interfaces changes.

The other magic could bring Red Hat’s Ansible Automation Platform (AAP) into the game.

AAP can automate almost everything and can help you with triggering complex builds happening outside of your Data Center but which need to be reflected deep in your on-prem world.

In the end what happens here in detail is not so important and also not relevant for this blog. The important point is only that you have these two helping layers which are enough for your end-to-end automation journey.

Service Integration

The goal of MuleSoft’s integration platform is to deliver connected services in a scalable way. Point-to-point connections between services within an IT architecture generally hinders scalability as it does not provide the ability to reuse already existing components easily.

Introducing layers of abstraction into the integration architecture therefore provides stability and predictability for every change to the overall application landscape. It also accelerates development of new services that rely on existing reusable components without the need for every developer to understand the complexity of the underlying system.

Every Mule app implements a reusable service and is deployed into a container by the RTF operator. Using MuleSoft’s large catalogue of connectors a Mule app can connect to nearly every type of downstream system and expose their data and functionality in a standardised way.

Mule apps commonly expose these interfaces as synchronous APIs (REST, SOAP, GraphQL) or through asynchronous channels (by using a message queue or an event streaming solution). Overlying Mule apps then orchestrate these exposed systems and execute business logic such as data transformations and system synchronisation.

Mule apps are stateless and process all data in transit. Access governance is enforced by the embedded API gateway.

The full lifecycle of every Mule app is supported by Anypoint’s platform tools.

Anypoint’s platform tools

API Designer: A web-based, graphical tool to create API specifications and corresponding documentation.
Exchange: The central catalogue for API specifications, connectors, data schemas and more.
Code Builder: A VS Code-based IDE to implement APIs and integrations in low-code. Code Builder connects directly to Exchange to pull connectors and downstream dependencies (such as Mule app) into the project.
MUnit: A native unit testing framework.
Runtime Manager: A central place to manage deployments to all environments
API Manager: An admin console to apply API policies (authentication, authorization, traffic control, …)
Monitoring and Visualizer: The central view for all runtime operations such as log analysis and troubleshooting.

To automate the full build, test and deployment process of all MuleSoft workloads, Anypoint Platform provides a dedicated Maven plugin, comprehensive platform APIs and CLI tools.

Deployment automation solutions (e.g. Ansible) then leverage these tools to implement the CI/CD pipeline for your enterprise integration solution based on Mule.

But let’s take a step back and see how we can install MuleSoft’s RTF on OpenShift.

HOW to install MuleSoft on OpenShift

Installation of MuleSoft Anypoint Runtime Fabric (RTF) instance

Below is a high level diagram which summarises the creation of RTF instances on OpenShift.

Prerequisites

You will need an enterprise MuleSoft account to have access to Runtime Fabric from Runtime Manager. With that enterprise account, from Anypoint platform, navigate to the Runtime Manager and then you will be able to create a Runtime Fabric instance.

Your MuleSoft account representative will help you acquire an Enterprise licence in the form of a licence.lic file which will be needed for creating an RTF instance.

Have a running OpenShift cluster ready – whether it is on prem or on a public cloud.

Once you have the above prerequisites in place, follow the instructions listed on Runtime Manager (Anypoint login required) and create a Runtime Fabric by selecting “OpenShift” as the installation platform.

Then navigate to the Operator hub in the OpenShift cluster and install the RTF Operator. After the RTF Operator is installed, navigate to the Runtime Fabric namespace. Use the form view to create an RTF instance.

Fill the RTF instance form view with activation data from the Anypoint Runtime Fabric page, base64 encoded format of the licence from the enterprise mule licence file.

The guide Creating Runtime Fabric RTF on OpenShift on Github has additional details with screenshots. We also recommend consulting the official documentation from MuleSoft.

Create a Service account which can be used for running the RTF instance.

Before creating the RTF instance, toggle to the yaml view and add the service account. Then create the RTF instance.

Once all the pods in the “rtf” namespace are active and registered with Anypoint platform you’ll be able to start deploying Mule apps to your OpenShift cluster within minutes.

From the above github repo, copy the ingress template yaml into your OpenShift cluster, modify the hostname by providing appropriate value and create an ingress. This will create an ingress in the “rtf” namespace. All Mule applications for this RTF instance will use this ingress.

That’s about it. Your applications can now be integrated with MuseSoft RTF.

So, time for a wrap up.

Key take-aways

We have learned how MuleSoft’s Anypoint Platform deployed to Red Hat OpenShift addresses demand for scalable integration of a heterogeneous application landscape.

We have also seen an approach to distribute the hosting platform to a hybrid cloud environment and how the capabilities of both the Anypoint and the OpenShift platforms complement each other.

We see the following three points you should take with you

To grow and innovate at speed, you need standardised, integrated solutions that provide flexibility without compromising on security In other words you need an API solution
OpenShift abstracts the infrastructure for you and is the real multi-cloud enabler, whereas the MuleSoft Control Panel guarantees you that interface changes are reflected over all stages and environments.
OpenShift is the only certified container platform to run MuleSoft on-prem and therefore fulfils a major multi- / hybrid-cloud requirement.