CloudHub V1 Vs V2

Core Infrastructure and Orchestration

• CloudHub v1 (CH1): Built on an architecture utilizing AWS EC2 instances with VM-based health monitoring. Self-healing and zero-downtime deployments rely on proprietary MuleSoft automation and load balancers.
• CloudHub v2 (CH2): Features a modern, containerized architecture built on Kubernetes (EKS). This provides better scalability, faster deployments, and utilizes native Kubernetes orchestration for self-healing (such as automatically rescheduling failing apps to healthy nodes) and zero-downtime deployments via standard service probing.

Resource Allocation and Sizing

• CH1: Uses 1 to 8 workers per application, with vertical sizing ranging from 0.1 vCores (0.5 GB RAM) up to 16 vCores (32 GB RAM).
• CH2: Supports 1 to 16 workers (replicas) and offers finer granular vertical sizing, introducing intermediate half-vCore steps. Sizing ranges from 0.1 vCores to 4 vCores, but fundamentally delivers much higher RAM/Heap allocations per vCore (e.g., 0.1 vCores gets 1.2 GB RAM), addressing a common bottleneck.

Load Balancing and Traffic Management

• CH1: Relies on Dedicated Load Balancers (DLB, based on NGinx), which use 2 instances/Public IPs hosted in the VPC. The DLBs directly perform TLS offloading and firewalling.
• CH2: Uses a segmented approach with an External Load Balancer (exposing 3 public IPs for internet traffic) and an Internal Load Balancer (exposing 3 private IPs for private traffic). TLS offloading is handled by a common Ingress Controller located within the Private Space. Note that while this is a modern approach, the absence of the older DLB system can make segregating internal and internet traffic more complex.

Networking, Outbound Traffic, and Firewalling

• CH1: Mule app source IPs are volatile AWS regional IPs, but CH1 allows static IPs to be assigned to single applications for fine-grained outbound source filtering. Firewalling rules are applied at the VPC and DLB levels. Intra-app communication happens within the VPC using the application name.
• CH2: Introduces an Egress Gateway that handles outbound traffic outside the Private Space. It utilizes 3 static IPs per Private Space for all outbound connections, which simplifies IP source filtering for backend systems but is less granular per-application than CH1. Firewalling is handled via Ingress/Egress rules at the Private Space and Application levels. Intra-app communication occurs within the Private Space via application/overlay names.

CPU Performance and Bursting

• CH1: Provides native, predictable CPU bursting for 0.1 and 0.2 vCore sizes based on AWS CPU credits.
• CH2: Offers constant, guaranteed CPU performance regardless of the plan for workers 1 vCore or larger. For replicas under 1 vCore, burst capability improves startup times but relies entirely on remaining shared resources on the worker node, meaning bursts are not guaranteed, predictable, or monitorable.

In a Nutshell