About Anypoint Runtime Fabric
Anypoint Runtime Fabric is a container service that automates the deployment and orchestration of your Mule applications and gateways. Runtime Fabric runs on customer-managed infrastructure on AWS, Azure, virtual machines (VMs) or bare-metal servers.
Some of the capabilities Anypoint Runtime Fabric provides are the following:
Isolation between applications by running a separate Mule runtime per application.
The ability to run multiple versions of the Mule runtime on the same set of resources.
Scaling applications across multiple replicas.
Automated application fail-over capabilities.
Application management with Anypoint Runtime Manager.
|Please reach out to your Customer Success Manager for more information on how to get Anypoint Runtime Fabric enabled for your account.|
Anypoint Runtime Fabric is composed of a set of VMs, each serving as one of the following roles:
Controller - VMs dedicated for operating Runtime Fabric, including orchestration services, distributed database, load balancing, and services enabling Anypoint Platform management.
Worker - VMs dedicated for running Mule applications and API gateways.
This separation of responsibilities enables scaling of the worker VMs based on the number of Mule applications. It also enables scaling the controller VMs based on the the frequency of deployments, changes in application state, and amount of inbound traffic. To ensure resources are available to re-schedule and re-deploy applications in the event of a hardware failure, we recommended over-provisioning the number of worker VMs.
By default, the services operating Runtime Fabric are deployed across the controller VMs to avoid a single point of failure in the system.
Anypoint Runtime Fabric uses a set of technologies, including Docker and Kubernetes, which are tuned to operate well with Mule runtimes. Knowledge of these technologies is not required to deploy or manage Mules on Runtime Fabric. Managing Runtime Fabric requires the operational and infrastructure-level experience needed to support any system at scale. We recommend following best practices and running fire drill scenarios in controlled environments to help prepare for unexpected failures.
|Deployments of applications and gateways not powered by Mule on Anypoint Runtime Fabric is not supported.|
Anypoint Runtime Fabric contains specific versions of all components required to function as designed. Each component, including Docker and Kubernetes, are tuned to operate efficiently with the Mule runtime and other MuleSoft services. Installing Runtime Fabric within an existing Kubernetes-based PaaS is not supported.
For customers already running on a PaaS, it’s recommended to deploy Runtime Fabric alongside the PaaS to take advantage of the complete benefits of Anypoint Platform.
Anypoint Runtime Fabric supports the following:
Deploying applications from Anypoint Runtime Manager.
Deploying policy updates of API gateways using API Manager.
Integration with Anypoint Exchange to store and retrieve related assets.
To enable this, Runtime Fabric establishes an outbound connection to Anypoint Cloud control plane via the AMQP protocol and secured using mutual TLS. A set of services running on the controller VMs initiate outbound connections to retrieve the metadata and assets required for application deployment. These services then translate and communicate with other internal services to cache the assets locally and deploy the application.
|Anypoint Runtime Fabric uses the AMQP protocol to connect to Anypoint Cloud control plane. Check with your network administrator on enabling outbound connections from your organization’s network using this protocol.|
On-premise deployments of Mule applications require you to install a version of the Mule runtime on a server and deploy one or more applications on the server. Each application shares the resources available to the Mule runtime. Other resources such as certificates or database connections can also be shared using domains.
On Anypoint Runtime Fabric, each Mule application and API gateway runs with their own Mule runtime, and in their own container. Each application deployment specifies the amount of resources the container can access. This enables Mule applications to horizontally scale across VMs without relying on dependencies. It also safeguards each application from competing with another application’s resources on the same VM.