MuleSoft Mastery: From Zero to Hero | Ch.08

In Chapter 7 you took a working Customer API and turned it into a governed asset — policies, SLA tiers, Flex Gateway, and a CI/CD pipeline. But governance is only half of production. The other half is resilience: what happens when an availability zone drops, when traffic triples on Black Friday, or when you have to ship a breaking change to a live API serving millions of requests. This chapter is your complete tour of the runtime side of MuleSoft — where your apps actually run, and how to keep them running.

By the end of this chapter you will:

• Compare CloudHub 1.0, CloudHub 2.0, and Runtime Fabric — and pick the right one with confidence
• Understand CloudHub 2.0 architecture: private spaces, replicas, vCore sizing, and intelligent healing
• Run Mule on your own Kubernetes with Runtime Fabric — controllers, workers, and the agent
• Design for high availability across availability zones — and know HA from clustering
• Scale horizontally with replica scale-out and Horizontal Pod Autoscaling
• Handle state and messaging correctly — why persistent VM queues are gone on CloudHub 2.0
• Ship zero-downtime updates with rolling, blue-green, and canary strategies
• Plan disaster recovery and a multi-region topology — and understand what MuleSoft does not give you out of the box
• Monitor and alert on the metrics that actually predict incidents

01 · The Landscape — Where Can a Mule App Actually Run?

MuleSoft’s deployment options sit on a spectrum that trades convenience against control. At one end, you hand everything to MuleSoft and never think about infrastructure. At the other, you run Mule on your own Kubernetes cluster and own every layer. The art is knowing which trade-off your project actually needs — most teams over-estimate how much control they require.

02 · CloudHub 2.0 — The Managed Runtime, Up Close

CloudHub 2.0 gives you a fully managed, containerized runtime. Each environment runs inside a private space — a virtual, private, isolated logical space in which your Mule apps run, with its own IP ranges, VPC connectivity, and firewall rules. Inside a private space you deploy applications, and each application runs as one or more replicas — dedicated instances of the Mule runtime engine, each in its own container.

2.1 · Replicas and vCore sizing

You scale a replica vertically by choosing a vCore size, and horizontally by adding more replicas. Bigger vCore sizes give more CPU, heap, and ephemeral storage. Replicas below 1.0 vCore are burstable (they can briefly borrow CPU when available); replicas at 1.0 vCore and above give consistent performance.

2.2 · Deploying to CloudHub 2.0 with Maven

You can deploy from Anypoint Studio, from Runtime Manager, or — the only sane choice for production — from a pipeline using the Mule Maven Plugin. Always pin an LTS runtime (Mule 4.6 LTS or later) and set a rolling update strategy for zero downtime.

<plugin>
  <groupId>org.mule.tools.maven</groupId>
  <artifactId>mule-maven-plugin</artifactId>
  <version>4.2.0</version>
  <extensions>true</extensions>
  <configuration>
    <cloudHub2Deployment>
      <uri>https://anypoint.mulesoft.com</uri>
      <environment>Production</environment>
      <target>private-space-eu-west-1</target>
      <muleVersion>4.6.14</muleVersion>          <!-- LTS -->
      <applicationName>order-api-prod</applicationName>
      <replicas>2</replicas>                         <!-- HA across AZs -->
      <vCores>0.5</vCores>
      <deploymentSettings>
        <updateStrategy>rolling</updateStrategy>   <!-- zero downtime -->
        <clustered>false</clustered>            <!-- HA, not clustering -->
      </deploymentSettings>
      <properties>
        <mule.env>production</mule.env>
      </properties>
      <secureProperties>
        <db.password>${DB_PASSWORD}</db.password>  <!-- encrypted at rest -->
      </secureProperties>
    </cloudHub2Deployment>
  </configuration>
</plugin>

03 · Runtime Fabric — Your Kubernetes, MuleSoft’s Management

Runtime Fabric (RTF) lets you run Mule applications and API gateways on your own Kubernetes, while Anypoint Platform stays the control plane. Your data never leaves your infrastructure — the perfect fit for data-residency requirements, hybrid cloud, or teams who already live in Kubernetes. RTF comes in two flavours:

• RTF on Self-Managed Kubernetes — you install the RTF agent into an existing cluster: Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift, or Rancher (RKE). You own the cluster lifecycle.
• RTF on VMs / Bare Metal — MuleSoft ships the full appliance (Docker + Kubernetes packaged together) and you install it on VMs you operate. MuleSoft maintains the appliance components.

04 · High Availability — Surviving a Zone Outage

High availability means your application keeps serving even when something fails. On CloudHub 2.0 and Runtime Fabric, HA comes from redundancy. The single most important fact: when you deploy with two or more replicas, the platform automatically distributes them across two or more availability zones. If one zone has an outage, the replicas in the other keep handling traffic — and you didn’t configure anything special to get it.

But there’s a subtle, frequently-misunderstood distinction between plain HA and clustering, and choosing wrong causes real bugs (double-fired schedulers, lost object-store data).

4.1 · Replica scale-out limits

You can deploy an application with up to 8 replicas — or up to 16 replicas if your organization has the Anypoint Integration Advanced package or a Platinum/Titanium subscription. Mule automatically distributes those replicas across two or more data centers for maximum reliability. When you enable clustering, MuleSoft recommends scaling a cluster to no more than 8 nodes.

05 · Scaling — Manual, Automatic, and the Catches

Scaling on CloudHub 2.0 happens two ways. Manual scaling: in Runtime Manager you adjust replica count and vCore size at any time — new replicas are provisioned on scale-up, and traffic is drained before termination on scale-down. Autoscaling: under the hood, Kubernetes uses a Horizontal Pod Autoscaler (HPA) that adds or removes replicas to match demand, so an application can move to a new replica without any user action.

Before you crank the replica count, internalize the four things that bite teams in production:

06 · State & Messaging — Why Persistent VM Queues Are Gone

This is the section that trips up engineers migrating from CloudHub 1.0, so read it twice. CloudHub 2.0 does not support persistent VM queues. The in-memory VM connector still works for transient, intra-app communication, but if you relied on persistent VM queues for reliable, restart-surviving messaging, you must refactor to a real message broker.

For shared application state (not messages), CloudHub 2.0 uses Anypoint Object Store v2 (OSv2) — a managed store for things like idempotency keys, OAuth tokens, and watermark values. Two facts you must design around:

• OSv2 is regional. It runs in the same region as your app and provides no cross-region failover. An app in another region cannot read it.
• Object stores are not shared between non-clustered replicas. Write to one replica and the others won’t see it — unless you use the cloud object store (OSv2) or enable clustering.

On Runtime Fabric, the equivalent is the Persistence Gateway, which persists Object Store data to a PostgreSQL database so state survives restarts and is shared across replicas.

<!-- Publish reliably to a durable broker queue -->
<flow name="order-intake">
  <http:listener config-ref="https-listener" path="/orders"/>
  <anypoint-mq:publish config-ref="amq-config" destination="orders-queue"/>
  <ee:transform> <!-- 202 Accepted --> </ee:transform>
</flow>

<!-- A subscriber processes independently; survives restarts & redeploys -->
<flow name="order-processor">
  <anypoint-mq:subscriber config-ref="amq-config" destination="orders-queue"/>
  <flow-ref name="persist-order"/>
</flow>

07 · Zero-Downtime — Shipping Without Interruptions

CloudHub 2.0 supports updating applications at runtime so users of your HTTP APIs experience zero downtime. You choose a deployment model: Rolling update keeps the old version serving while the new one deploys, then cuts over — the production default. Recreate stops the old version first (faster, but a brief outage) — only for non-critical apps.

For changes that need careful validation, two classic patterns layer on top — implemented at the gateway/router level, not inside your app.

08 · Disaster Recovery — The Multi-Region Truth

Here’s the honest version that most tutorials skip: CloudHub 2.0 does not provide multi-region HA or disaster recovery out of the box. Availability is provided within a single region — replicas spread across availability zones, with a platform SLA of 99.95% for replicas in an active-active configuration in that region. If an entire AWS region fails, every replica, private space, ingress, and Anypoint MQ destination in that region becomes unavailable, and they are not automatically replicated elsewhere.

Cross-region resilience is something you architect. The pattern: deploy the app in two regions, put a global load balancer in front, and replicate the database across regions.

09 · Monitoring — Know Before Your Users Do

Anypoint Monitoring is enabled by default for CloudHub 2.0 and Runtime Fabric applications. It gives you dashboards for throughput, error rates, response-time percentiles, and CPU/memory per replica — plus log search by correlationId and custom business metrics. The trick isn’t collecting data; it’s alerting on the signals that actually predict an incident.

10 · Case Study — OmniShop — Resilient Orders at Global Scale

Let’s make it concrete. OmniShop, a global online retailer, runs an Order Management API that processes millions of orders a day. It must survive an availability-zone failure, absorb Black-Friday spikes, and ship updates without dropping a single order. Here’s how they assembled it from the building blocks in this chapter — and what they consciously chose not to rely on MuleSoft for.

10.1 · The architecture, decision by decision

11 · Recap — What You Now Know