Comprehensive Overview of MuleSoft Deployment Models

In MuleSoft, a popular integration platform, deployment models refer to different strategies or approaches for deploying Mule applications (known as Mule apps) and managing their runtime environments.

CloudHub Model

CloudHub and CloudHub 2.0 is a fully managed platform where you can deploy APIs and integrations as lightweight containers in the cloud. You can deploy your applications directly from the Anypoint Platform Runtime Manager cloud console to CloudHub 2.0/CloudHub.

Platform: MuleSoft managed cloud backed by AWS.

Pros:

• Hassle-free Deployments and Zero Downtime Upgrades: Applications run continuously until the latest version is fully operational.
• Out-of-the-Box Scalability: Horizontal (number of workers) and vertical (worker capacity) scalability.
• Access to OSV2 Anypoint MQ and Persistent Queues: Available when the runtime is hosted on CloudHub.

Cons:

• Domain Projects Not Supported: Limitations on certain project types.
• Cost Considerations: Workers can be expensive e.g., $19k/year for 1 vCore.
• Additional Charges: VPC and VPN charges are extra on top of CloudHub license and worker costs.

Considerations:

• Isolation Requirements: VPC required for isolation from public cloud.
• Integration with On-Premises Systems: VPN tunnel required for communication with on-premises systems potentially introducing latency.
• Dedicated Load Balancer (DLB) Configuration: Necessary for handling vanity domains and simplifying domain management.

Hybrid Model

In a hybrid deployment setup with MuleSoft, you utilize the Runtime Manager cloud console to deploy applications to your own Mule servers, granting flexibility and centralized management while retaining control over on-premises security measures. It combines the benefits of cloud-based deployment management with the reliability and autonomy of on-premises infrastructure, offering a robust solution for organizations seeking to leverage both environments effectively.

Platform: Managed by the organization.

Pros:

• Shared Resource Utilization: Utilize domain projects to run multiple applications within a single runtime managed internally.
• Reduced Latency: Benefit from lower latency as the runtime is located within the local data center.
• Utilization of Existing Infrastructure: Leverage existing load balancers for managing vanity domains.

Cons:

• Manual Upgrades and Patch Management: Upgrades and patches require manual intervention since the runtime is self-managed.
• Scalability Complexity: Scaling efforts involve creating cluster groups or adding servers to existing clusters.
• Log Management Dependency: Accessing logs through MuleSoft’s control plane requires a Titanium subscription; otherwise, logs must be retrieved manually from the runtime plane.

Considerations:

• Service Limitations: Exclusive services like OSV2 and certain features such as persistent queues from Amazon SQS are unavailable when using this model.

Runtime Fabric Model

In this architecture, the control plane resides in the cloud and oversees a Kubernetes cluster within the data center environment. Docker containers along with the Mule runtime form the core components of the application deployment strategy. This setup is designed to dynamically scale based on defined parameters, allowing Kubernetes to spin up or down Docker instances as required.

Platform: Managed by MuleSoft.

Pros:

• Scalability: You can dynamically scale based on demand.
• Reduced Latency: Benefit from lower latency as the runtime is located within the local data center.
• Utilization of Existing Infrastructure: Basic load balancing is included by default.

Cons:

• Manual Upgrades and Patch Management: Upgrades and patches require manual intervention since the runtime is self-managed.
• Log Management Dependency: Accessing logs through MuleSoft’s control plane requires a Titanium subscription.

Considerations:

• Service Limitations: The model heavily relies on Kubernetes for orchestration and management, which could affect performance and reliability.

Private Cloud Edition Model

In this setup, both the control plane and runtime plane are located within the data center environment, typically chosen for its security benefits—ideal for sectors like banking where stringent data handling regulations apply. The control plane includes the design and management center, deployed as Docker containers managed by Kubernetes.

Platform: Managed by the organization.

Pros:

• Secure On-Premises Management: Both Control and Runtime planes are securely managed within the organization’s premises.
• Data Control: No metadata is sent to Mulesoft’s cloud, ensuring strict control over data exchange.
• On-Premises Asset Security: All assets remain strictly on-premises, bolstering security and compliance.

Cons:

• Expertise Needed for Self-Management: Managing the control plane internally requires specialized skills, and resolving issues can be complex.

Considerations:

• Service Limitations: Resource allocation (CPU, memory, storage) may be constrained compared to public cloud offerings, affecting scalability under heavy loads.

Pivotal Cloud Foundry Model

Pivotal Cloud Foundry (PCF) and Pivotal Cloud Edition (PCE) provide a platform layer that can run on AWS, Azure, a data center, or a private cloud (CCP). They include their own container engine called Garden (Diego) which manages the deployment of applications. Build packs determine the type of application being deployed, and you add your application code on top.

Platform: Managed by VMware.

Pros:

• Secure On-Premises Management: Both Control and Runtime planes are securely managed within the organization’s premises.
• Data Control: No metadata is sent to Mulesoft’s cloud, ensuring strict control over data exchange.
• On-Premises Asset Security: All assets remain strictly on-premises, bolstering security and compliance.

Cons:

• Expertise Needed for Self-Management: Managing the control plane internally requires specialized skills, and resolving issues can be complex.

Considerations:

• Service Limitations: Resource allocation (CPU, memory, storage) may be constrained compared to public cloud offerings, affecting scalability under heavy loads.

Comparisons

Feature	CloudHub	Hybrid	RTF	PCE	PCF
High Availability	Yes (OOTB)	Configure	Yes	Configure	Configure
Load Balancing	SLB/DLB	On-Prem LB	Basic	Configure	Configure
Logging	Yes	No (Titanium)	No (Titanium)	No	No
Monitoring	Yes	Yes	Yes	Only Alerts	Only Alerts
Object Store	Yes	Configure	Configure	Configure	Configure
Scheduling	Yes	No	No	No	No
Security Updates	Yes	Manual	Manual	Manual	Manual
Shared Resources	No	Yes	No	Yes	Yes