12.1 CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering

CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering

Deploying and running Mule applications in the cloud requires a thorough understanding of MuleSoft's fully managed integration platform as a service (iPaaS): CloudHub. CloudHub abstracts underlying cloud infrastructure while providing enterprise-grade high availability, dynamic scaling, multi-tenant isolation, and intelligent load balancing. For the Salesforce Certified MuleSoft Developer I exam, mastering worker sizing, scaling patterns, load balancer configurations, and the differences between CloudHub 1.0 and CloudHub 2.0 is essential.

---

1. CloudHub 1.0 Worker Architecture & Resource Allocation

In CloudHub 1.0, each deployed application runs on one or more dedicated virtual machine instances called Workers. A worker is an isolated Amazon EC2 instance running a single Mule runtime engine JVM on Linux, dedicated exclusively to your application.

+-----------------------------------------------------------------------------------------+
|                              CLOUDHUB 1.0 WORKER ARCHITECTURE                           |
|                                                                                         |
|   +---------------------------------------------------------------------------------+   |
|   | AWS EC2 INSTANCE (WORKER)                                                       |   |
|   |                                                                                 |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |   | MULE RUNTIME ENGINE (JVM)                                               |   |   |
|   |   |                                                                         |   |   |
|   |   |   +--------------------------+     +--------------------------------+   |   |   |
|   |   |   | ALLOCATED JVM HEAP MEMORY|     | JVM METASPACE & NATIVE BUFFERS |   |   |   |
|   |   |   | (e.g., 500 MB on 0.1 vC) |     | (Operating System & I/O)       |   |   |   |
|   |   |   +--------------------------+     +--------------------------------+   |   |   |
|   |   |                                                                         |   |   |
|   |   |   +-----------------------------------------------------------------+   |   |   |
|   |   |   | DEPLOYED MULE APPLICATION (Flows, Connectors, DataWeave Engine) |   |   |   |
|   |   |   +-----------------------------------------------------------------+   |   |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |                                                                                 |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |   | EPHEMERAL LOCAL STORAGE (8 GB to 328 GB AWS EBS Volume)                 |   |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

Worker Sizing & Memory Specifications

When deploying a Mule application to CloudHub 1.0, developers specify the processing capacity and memory of each worker in terms of vCores. Fractional vCores (0.1 and 0.2 vCore) provide cost-effective burstable capacity for lightweight APIs, while multi-vCore sizes provide dedicated compute power for high-throughput batch and streaming workloads.

Across every worker size, roughly 3 GB of the allocated disk is reserved for the operating system and Mule runtime components, so the smallest 8 GB workers leave about 5 GB for application use (including verbose logging and disk-backed streaming buffers).

CPU Bursting on Fractional Workers

Fractional workers (0.1 vCore and 0.2 vCore) share underlying physical CPU cores with other cloud tenants. CloudHub grants CPU burst credits during idle periods, allowing the application to burst up to 100% of a physical CPU core for short durations (e.g., initial application startup or brief traffic spikes). However, if a fractional worker experiences sustained high CPU utilization, its burst credits deplete, and the hypervisor throttles CPU execution down to the baseline fractional limit (10% or 20%), resulting in elevated latency and potential request timeouts.

Ephemeral vs. Persistent Storage

The local disk attached to a CloudHub worker is ephemeral storage. If a worker restarts, crashes, or is updated during a deployment, all data written to local worker disk storage (/tmp or local file paths) is permanently lost. To persist state across worker restarts or share data across multiple workers, applications must use Object Store v2 (OSv2), Anypoint MQ, or external persistent databases.

---

2. Scaling Strategies: Horizontal vs. Vertical Scaling

To accommodate growing transaction volumes and guarantee high availability (HA), CloudHub provides two complementary scaling dimensions:

+-----------------------------------------------------------------------------------------+
|                       HORIZONTAL SCALING vs. VERTICAL SCALING                           |
|                                                                                         |
|   HORIZONTAL SCALING (Multiple Workers):            VERTICAL SCALING (vCore Upsizing):  |
|   +-------------+       +-------------+             +-------------------------------+   |
|   | Worker 1    |       | Worker 2    |             | Worker 1                      |   |
|   | 0.2 vCore   | <---> | 0.2 vCore   |             | 1.0 or 2.0 vCore              |   |
|   | (AZ us-e1a) |       | (AZ us-e1b) |             | (Larger Heap & Compute)       |   |
|   +-------------+       +-------------+             +-------------------------------+   |
|          \                     /                                    |                   |
|           v                   v                                     v                   |
|     [HIGH AVAILABILITY & FAILOVER]                    [LARGE DATAWEAVE HEAP BUFFERS]    |
|     [ROUND-ROBIN LOAD BALANCING]                      [COMPUTE-INTENSIVE BATCH JOBS]    |
+-----------------------------------------------------------------------------------------+

Horizontal Scaling (Adding Multiple Workers)

• High Availability (HA): When you deploy an application with two or more workers, CloudHub automatically distributes them across distinct AWS Availability Zones (AZs) within the selected region. If an entire data center facility or availability zone experiences an outage, surviving workers in peer AZs continue serving traffic without downtime.
• Automatic Load Distribution: Inbound HTTP requests arriving at the CloudHub Load Balancer are automatically distributed across all healthy worker instances in round-robin fashion.
• Clustering & Object Store Synchronization: When multi-worker applications use Object Store v2, stored keys and values are synchronized across all workers via a distributed cloud-hosted cache.

Vertical Scaling (Increasing vCore Size)

• Expanded JVM Heap Memory: Upgrading from 0.2 vCore (1 GB heap) to 1 vCore (2 GB heap) or 2 vCores (4 GB heap) prevents java.lang.OutOfMemoryError exceptions when processing massive JSON/XML documents or executing complex DataWeave transformations in memory.
• Dedicated CPU Compute: Eliminates fractional CPU throttling, ensuring predictable sub-millisecond execution times for compute-heavy cryptographic, compression, or parsing operations.

Horizontal vs. Vertical Sizing Decision Matrix

---

3. Load Balancing & Traffic Routing: SLB vs. DLB

Every Mule application deployed to CloudHub requires load balancing to route inbound client requests from the public internet or corporate network to the appropriate worker instances.

+-----------------------------------------------------------------------------------------+
|                        CLOUDHUB TRAFFIC ROUTING TOPOLOGY                                |
|                                                                                         |
|   [PUBLIC CLIENT]                 [ENTERPRISE CLIENT]                                   |
|          |                                 |                                            |
|          v                                 v                                            |
|   +-----------------------------+   +-----------------------------------------------+   |
|   | SHARED LOAD BALANCER (SLB)  |   | DEDICATED LOAD BALANCER (DLB)                 |   |
|   | - app-name.region.cloudhub.io | | - api.enterprise.com (Custom SSL/TLS)         |   |
|   | - Ports: 80 -> 8081         |   | - URL Mapping Rules: /{app}/                  |   |
|   |          443 -> 8082        |   | - VPC Internal & Public Routing               |   |
|   +-----------------------------+   +-----------------------------------------------+   |
|                  \                                 /                                    |
|                   +---------------+---------------+                                     |
|                                   |                                                     |
|                                   v                                                     |
|                +-------------------------------------+                                  |
|                | ANYPOINT VPC (10.0.0.0/16)          |                                  |
|                |                                     |                                  |
|                |   +-------------+   +-------------+ |                                  |
|                |   | Worker 1    |   | Worker 2    | |                                  |
|                |   | Port: 8081  |   | Port: 8081  | |                                  |
|                |   | (AZ-1)      |   | (AZ-2)      | |                                  |
|                |   +-------------+   +-------------+ |                                  |
|                +-------------------------------------+                                  |
+-----------------------------------------------------------------------------------------+

CloudHub Shared Load Balancer (SLB)

• Default Routing Infrastructure: Provided automatically in every CloudHub region without additional cost or provisioning.
• Domain Naming Convention: Exposes public DNS endpoints following the pattern:
  • http://{app-name}.{region}.cloudhub.io (Standard HTTP)
  • https://{app-name}.{region}.cloudhub.io (Encrypted HTTPS)
• Mandatory Port Mappings:
  • Inbound HTTP on port 80 routes to worker port 8081.
  • Inbound HTTPS on port 443 routes to worker port 8082.
  • Applications listening on non-standard ports (e.g., 8080, 9090) are unreachable through the SLB.
• Direct Worker Addressing:
  • http://mule-worker-{app-name}.{region}.cloudhub.io:8081 (Bypasses SLB; routes directly to a specific worker over the public internet).
  • http://mule-worker-internal-{app-name}.{region}.cloudhub.io:8081 (Internal VPC DNS; used for private worker-to-worker communication within an Anypoint VPC).

Anypoint Dedicated Load Balancer (DLB)

• Custom Domain Names & SSL Termination: Enables enterprises to map vanity domains (e.g., https://api.acme.com/customers) to CloudHub applications and manage custom SSL/TLS certificates and cipher suites.
• Path-Based URL Mapping Rules: Translates incoming client request paths dynamically to target application names using pattern matching:
  • Input: https://api.acme.com/{app}/{version}/
  • Target App: {app}-{version}
  • Output Path: /
• VPC Isolation & Firewall Security: Deployed inside a specific Anypoint Virtual Private Cloud (VPC), allowing internal-only routing over IPsec VPN or AWS Direct Connect while blocking public internet access.

Shared Load Balancer vs. Dedicated Load Balancer Comparison

---

4. CloudHub 1.0 vs. CloudHub 2.0 Architecture

CloudHub 2.0 represents the next generation of MuleSoft's managed iPaaS, transitioning from virtual-machine-based infrastructure to a containerized, Kubernetes-based microservices architecture built on Salesforce Hyperforce substrate.

+-----------------------------------------------------------------------------------------+
|                     CLOUDHUB 1.0 (EC2 VMs) vs. CLOUDHUB 2.0 (CONTAINERS)                |
|                                                                                         |
|   CLOUDHUB 1.0 ARCHITECTURE:                    CLOUDHUB 2.0 ARCHITECTURE:              |
|   +-------------------------------------+       +-----------------------------------+   |
|   | ANYPOINT VPC (AWS Subnets)          |       | PRIVATE SPACE (Hyperforce K8s)    |   |
|   |                                     |       |                                   |   |
|   |   +-----------------------------+   |       |   +---------------------------+   |   |
|   |   | WORKER 1 (Dedicated EC2 VM) |   |       |   | INGRESS CONTROLLER (TLS)  |   |   |
|   |   | - Mule Runtime JVM          |   |       |   +---------------------------+   |   |
|   |   | - Linux OS + Virtual Disk   |   |       |                 |                 |   |
|   |   +-----------------------------+   |       |                 v                 |   |
|   |                                     |       |   +---------------------------+   |   |
|   |   +-----------------------------+   |       |   | REPLICA 1 (K8s Pod/CGroup)|   |   |
|   |   | WORKER 2 (Dedicated EC2 VM) |   |       |   | - Lightweight Container   |   |   |
|   |   | - Mule Runtime JVM          |   |       |   | - Rapid Spin-up (~30s)    |   |   |
|   |   +-----------------------------+   |       |   +---------------------------+   |   |
|   +-------------------------------------+       +-----------------------------------+   |
+-----------------------------------------------------------------------------------------+

Shared Spaces vs. Private Spaces in CloudHub 2.0

• Shared Spaces: Multi-tenant container environments managed by MuleSoft across 12+ global regions. Suitable for lightweight public APIs that do not require private corporate network connectivity.
• Private Spaces: Virtual, isolated private network partitions (analogous to an Anypoint VPC + DLB in CloudHub 1.0). Provides built-in ingress load balancing, custom domain management, and out-of-the-box connectivity to corporate data centers via Anypoint VPN or AWS Transit Gateway.

Replicas vs. Workers

In CloudHub 2.0, the unit of execution is a Replica (a containerized Kubernetes pod) rather than a VM worker. Replicas start up in seconds (compared to 3–5 minutes for CloudHub 1.0 EC2 instances), consume fewer cloud resources, and support fine-grained replica allocations:

• Replica Sizes: 0.1, 0.2, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, and 4.0 replicas.

Comprehensive Comparison: CloudHub 1.0 vs. CloudHub 2.0

---

5. Static IP Allocation & Outbound Whitelisting

When Mule applications connect to secured external partner systems or corporate databases protected by network firewalls, the receiving firewall must whitelist the IP addresses of the Mule workers.

Static IPs in CloudHub 1.0

• By default, CloudHub assigns dynamic public IP addresses that change whenever an application restarts, redeploys, or experiences worker recovery.
• In Runtime Manager, administrators can enable Allocate Static IP for an application. CloudHub assigns a fixed, static IP address from the organization's static IP pool to each worker.
• Zero-Downtime Static IP Swapping: During a rolling update, CloudHub provisions a temporary IP for the new worker during verification, and seamlessly swaps the permanent static IP to the new worker upon cutover, ensuring uninterrupted communication with downstream firewalls.

Egress IPs in CloudHub 2.0

• In CloudHub 2.0 Private Spaces, outbound traffic routes through deterministic Egress IP addresses associated with the Private Space's NAT gateway, eliminating the need to manage individual IP addresses per replica.

---

6. Exam Watch: Core CloudHub Architecture Scenarios

[!IMPORTANT] HTTP Listener Port Requirements in CloudHub 1.0 Always configure the HTTP Listener in your Mule application using dynamic property placeholders:

• port="${http.port}" (resolves to 8081 at runtime)
• port="${https.port}" (resolves to 8082 at runtime) If you hardcode port 8080 or 80, the application will start locally in Studio but fail to receive traffic when deployed behind the CloudHub Shared Load Balancer.

[!WARNING] Fractional Worker CPU Throttling 0.1 and 0.2 vCore workers rely on CPU burst credits. For high-volume production integrations or batch processes, deploying fractional workers risks severe CPU throttling. Use at least 1.0 vCore for high-load production workloads.

[!TIP] High Availability Requirement To achieve High Availability (HA) on the MuleSoft Developer I exam, always select at least two workers deployed in different availability zones. A single worker—regardless of how many vCores are assigned—represents a single point of failure.