Introduction

MuleSoft is famous for disrupting the enterprise integration space through it’s scalable, extensible runtime engine and API-led connectivity approach to development. With their release of AnyPoint Platform, customers also gained a unified suite of tools for handling the entire API development lifecycle. When the need to alleviate the burden of infrastructure management from customers became clear, MuleSoft released their CloudHub solution to provide an integration platform as a service. More recently, in response to the increasing customer demand for multicloud deployments, MuleSoft released AnyPoint Runtime Fabric. In this series of blog articles, we will cover the following topics related to AnyPoint Runtime Fabric:

• Overview (this article)
• Architecture
• Installation
• Deploying Applications
• Maintenance and Troubleshooting

What is RTF?

AnyPoint Runtime Fabric (hereafter referred to as “RTF”) is the solution to the complexity of managing the underlying infrastructure for Mule deployments in a multicloud environment. Based on a packaged Kubernetes solution, it allows customers to deploy a cluster to any public or private cloud and receive the same great iPaaS experience they enjoy when using CloudHub.

Why RTF?

There are many reasons customers opt for RTF as their deployment strategy:

• Multicloud support
• Application Isolation
• Support for Multiple Runtimes
• Zero downtime upgrades, rollbacks, and scaling
• High availability
• Minimal infrastructure skills required

Let’s examine each of these in some detail:

Multicloud

RTF can be installed to any cloud or customer datacenter, and managed via the AnyPoint Platform Runtime Manager. (NOTE: Installation scripts are currently only available for Microsoft Azure and Amazon Web Services, with Google Cloud announced but not yet generally available. Customers can still perform manual installation on any infrastructure they wish as long as they meet the minimum system and networking requirements.)

Application Isolation

The underlying Docker container technology provides strong isolation through the use of Linux kernel namespaces and control groups. This increases the reliability and security of your application network by isolating any potential failures or compromises in a way that is very difficult to reproduce in traditional customer-hosted deployment scenarios. All of this is transparent to the administrator and there is still full support for the AnyPoint Platform concepts of Environments and Business Groups.

Multiple Runtimes

Because of the above-mentioned isolation, it is also possible to deploy multiple versions of the Mule runtime to the same RTF cluster. Customers can run support Mule 3 and Mule 4 applications on one infrastructure and channel their efforts toward creating value for the business rather than maintaining multiple environments.

Zero Downtime Upgrades, etc.

Orchestrating zero downtime upgrades, rollbacks, and scaling of Mule applications is not trivial. While this has always been available for CloudHub customers, now customers can enjoy the same painless automation in any cloud.

High Availability

RTF cluster installations are highly available by design, and deploying Mule applications in a highly available replica set or cluster is simple as moving a slider and clicking a checkbox.

Minimal Infrastructure Skills

Thanks to the packaging of RTF as a Gravity appliance, installation, upgrades, and other cluster maintenance is trivial and the underlying Docker and Kubernetes technologies are mostly transparent to the end user. However, if required administrators can still dive deep with access to Ops Center, gravity CLI, and kubectl.

What Next?

These are just some of the reasons customers are switching to RTF. In our next article, we will examine the RTF architecture and see how MuleSoft is able to achieve these benefits using the latest cloud-native technologies.