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 (RTF). In this series of blog articles, we will cover the following topics related to RTF:

* Overview

* Architecture (this article)

* Installation

* Deploying Applications

* Maintenance and Troubleshooting

Foundations

RTF creates the integration platform as a service (iPaaS) experience for customers by utilizing a combination of cutting edge technologies:

• Docker containers
• Kubernetes
• Gravitational

Each of these could be a series of blogs in themselves, and will not be the focus of this article. While understanding the underlying technologies is recommended and valuable, it’s not required to be able to operate the Runtime Fabric. Please follow their respective links to learn more.

Here is a brief summary of how the Runtime Fabric solution benefits from these technologies:

• Docker: Because Mule applications are deployed inside Docker containers rather than virtual machines, there are major efficiencies gained as 20-25 applications can run on one worker node, all the while maintaining isolation and performance guarantees.
• Kubernetes: Because the containers are managed via the Kubernetes orchestration platform, overlay networking, high-availability, load-balancing, service-discovery, secrets management, and more are available out of the box.
• Gravity: Because all of this is packaged as a Gravity appliance, the entire installation process can be automated when deployed to the supported hardware. Thanks to MuleSoft’s additional automation work, customers can deploy RTF clusters to their favorite clouds with minimal effort. [1]

With the underlying technologies out of the way, let’s focus on the architecture of the Runtime Fabric itself.

Architecture

The architecture of the Runtime Fabric cluster is composed of two types of nodes: controllers and workers.

Controller

The RTF controller is in fact a Kubernetes controller, so the orchestration, distributed database, and internal load-balancing capabilities are still being leveraged here. In addition, most control plane communication with AnyPoint Platform also happens here.

The biggest consideration when deciding on the number and size of controllers is redundancy and load-balancing capacity. Requests to apps running on the worker nodes whether sourced from inside or outside the cluster will always go through the load-balancer on the controller nodes, ensuring the same clustering and zero-downtime upgrades, rollbacks, and scaling that CloudHub customers enjoy. However, keep in mind that if there are multiple controllers, an additional external load-balancer will be required for traffic from outside the cluster.

The current maximum number of supported controller nodes is 5. Due to Kubernetes use of raft algorithm, it’s recommended to have an odd number of controllers.

Worker

The RTF worker node is where regular Mule applications will get deployed as pods. The more workers you have, the more highly-available and performant your cluster will be. However, the individual Mule application deployment configuration will decide on how much CPU, RAM, and number of replicas will be assigned to any one application.

The current maximum number of supported worker nodes is 16.

When external load-balancer, DNS, and AnyPoint Platform are taken into account, the larger looks something like this:

Limitations

Here’s a quick breakdown of some of the limitations of RTF. These are important to note when designing and building your Mule apps:

• RTF only works with MuleSoft-hosted AnyPoint Platform (US or EU).[2] There is currently no support for customer-hosted control-planes.
• There is no native support for ObjectStore or local storage. An external DB or file server should be used for persistent storage of application data.
• Applications deployed to RunTime Fabric must first exist in Exchange, so the configuration of CI/CD jobs will be very different from other Mule deployment targets. Read more about the process here.
• Similar to CloudHub, there is no support for Mule Domain projects. Only app per runtime.
• Running arbitrary Kubernetes workloads on your RTF cluster is not supported. Furthermore, Mule applications should only be deployed to RTF via Runtime Manager.
• For other important notes, see fabric limitations.

Conclusion

Hopefully this brief discussion of Runtime Fabric architecture has been informative. In the next article, we will examine the various installation methods available.

[1] Installation scripts 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.

[2] If you’re looking for a customer-hosted control plane, you’re better off using Pivotal Cloud Foundry or “naked Mules” with Private Cloud Edition.