Cloudhub 2.0 is out, the goal of the article is to compare Cloudhub 1.0, Cloudhub 2.0, RTF VM and RTF SMK. Some customers currently we are engaged with is looking for recommendation on weather to choose Choose Cloudhub 2.0 or Cloudhub 1.0 or RTF
CloudHub 2.0 is a fully managed, containerized integration platform as a service (iPaaS) where you can deploy APIs and integrations as lightweight containers in the cloud.
Date of GA : August 16, 2022
Cloudhub 2.0 vs Cloudhub 1.0 vs RTF VM vs RTF BYOK
| Sl No | Cloudhub 2.0 | Cloudhub 1.0 | Runtime Fabric VM | Runtime Fabric SMK | |
|---|---|---|---|---|---|
| 1 | Onboarding | Get started fast | Slower than Cloudhub 2.0 | Slower than Cloudhub 1.0 | Slower than RTF VM |
| Set up an environment quickly with simplified configuration for private spaces and network connectivity. | Manually setup VPC, VPN, DLB | Provisioning Cloud, Setting up Infrastructure Setting up Networking RTF Installation Hardening Installation | Provisioning Cloud, Setting up Infrastructure Setting up Networking RTF Installation Hardening Installation. Additional overhead of Kubernetes configuration |
||
| 2 | Streamline your operations | Reduce management overhead with new auto-provisioning and auto-scaling ingress and load balancer in private spaces. | Additional overhead in DLB Sizing scaling , manual, DLB configuration and mapping rules | Automatically provisioned Inbuild Ingress as in Cloudhub 2.0, Additional TCP Load balancer need to configured in production environments | Manual installation of Ingress. Additional Monitoring tooling installation. |
| 3 | Application Isolation | Docker in Pods running on top of EKS shared or private VPC Take advantage of lightweight isolation Improve performance and scale quickly with lightweight container-based application isolation. |
AWS EC2 VM running in VPC shared / private VM Level Application Isolation |
Docker in Pods running on top of EKS shared or private VPC Kubernetes, Pod Level Application Isolation |
Docker in Pods running on top of EKS shared or private VPC Kubernetes, Pod Level Application Isolation |
| 4 | Security | Private Spaces, with firewall control inbound and outbound traffic Implement tighter security controls, Simplify static IP Management and customize outbound firewall rules at the private space level. |
VPC Level with firewall control for inbound traffic. Outbound traffic not firewalled Static IP for DLB, Static IP for individual VM to be manually provisioned |
VPC level firewall control inbound and outbound traffic Static IP for Controller Nodes to be manually provisioned |
VPC level firewall control inbound and outbound traffic Static IP for Ingress Nodes to be manually provisioned |
| 5 | Future Proof | Meet present and future needs, faster, Based on Kubernetes on EKS. Take advantage of new products and features faster to accelerate growth and innovation. | Traditional Cloudhub VM Architecture, Heavyweight | Traditional Kubernetes based Architecture, very less customization option | Based on Kubernetes on EKS, AKS, GKE. |
Feature Comparisons
| Sl No | Cloudhub 2.0 | Cloudhub 1.0 | Runtime Fabric VM | Runtime Fabric SMK | |
|---|---|---|---|---|---|
| VM Management | |||||
| 1 | Managed By | Fully Managed by Mulesoft | Fully Managed by Mulesoft | Customer Managed | Customer Managed |
| 1.1 | Container | Docker | EC2 VM | Docker | Docker |
| 2 | OS patching | Fully Managed by Mulesoft | Fully Managed by Mulesoft | Supported (managed nodes) | Customer Managed |
| 3 | VM self-healing | Fully managed | Fully managed | Supported (managed nodes) K8 Feature | Supported (managed nodes) K8 Feature |
| 4 | Persistent VM Queues | Clustering Supported, Hazlecast VM Queues Available | SQS Backed VM Queue Service | Clustering Supported, Hazlecast VM Queues Available | Clustering Supported, Hazlecast VM Queues Available |
| Load Balancing and Ingress | |||||
| 5 | Default endpoints | Fully managed | Fully managed | Not supported | ?? |
| 6 | URL rewriting | Not supported (app-level) Configuring application ingress path rewrite rules is not supported like DLB rules |
Supported (DLB) | Supported | ?? |
| 7 | Provisioning/updating | Fully-managed | Fully-managed | Supported | |
| 8 | Certificate management | Supported | Supported | Supported | |
| 9 | Multiple truststores (client certificates for mutual TLS) | Supported | Not supported | Supported | |
| 10 | Custom endpoints | Supported | Supported | Supported | |
| 11 | Multiple custom endpoints per app | Supported | Partially supported | Supported | |
| 12 | TLS 1.0 | Not supported | Supported | Supported | |
| 13 | Private endpoints | Supported | Supported | Supported | |
| 14 | Load balancer logs | Supported (download) | Not supported | Supported | |
| 15 | Ingress logs | Supported | Not supported | Not supported | |
| Network | |||||
| 16 | Deployment regions | 12 geographical regions | 12 geographical regions | Supported (manual) | |
| In future plans to roll out to more cloudhub regions | Plan to sunset once cloudhub 2.0 adoption completes | ||||
| 17 | Virtual Private Cloud | Fully managed (private space) private spaces function as improved VPCs from CloudHub 1.0. You can automatically assign a private network for the applications in a private space. You can also configure a private ingress load balancer that auto-scales to accommodate traffic. |
Fully managed (Anypoint VPC) | Supported (manual) | |
| 1 VPC = 1 Private Space, VPC to Private Space peering is not possible. A TGW has to be used for this | |||||
| 18 | Virtual Private Network | Fully managed (private space) The MuleSoft VGW implementation supports a maximum throughput of 1.25 Gbps. Multiple VPN connections to the same private space share the throughput capabilities of a single VGW |
Fully managed (Anypoint VPN) | Supported (manual) | |
| VPN, TGW supported. | |||||
| 19 | AWS Transit Gateway | Supported (private space) | Supported | Supported | |
| 20 | Direct Connect | Not supported deprecated | Supported (not self-serve) | Supported | |
| 21 | VPC Peering | Not supported deprecated | Supported (not self-serve) | Supported | |
| 22 | DNS | Fully managed | Fully managed | Supported | |
| 23 | Inbound firewall rules | Supported | Supported | Supported | |
| 24 | Outbound firewall rules | Supported (private space) | Not supported | Supported | |
| 25 | Static IP addresses | Supported (private space) | Supported (per app) | Supported | |
| App Capabilities | |||||
| 26 | Schedule management | Supported | Supported | Not supported | |
| 27 | TLS certificates for API Gateway deployments | Supported
|
Supported | Not supported | |
| 28 | DataGraph | Not supported | Supported | Not supported | |
| Plans in near future releases | |||||
| 29 | Mule patch updates | Automated | Automated | Requires redeployment | |
| 30 | Cluster management | Fully managed ( EKS Kubernetes Cluster) | Fully managed | Self-managed | |
| 31 | Object store | Fully managed (Object Store v2) | Fully managed (Object Store v2) | Supported ( Persistent GW ) | |
| 32 | High availability across AZs | Fully managed (with two or more replicas) | Fully managed (with two or more workers) | Supported (with two or more replicas) | |
| 33 | Secure properties | Supported
|
Supported | Partially supported | |
| 34 | Log tailing | Fully managed | Fully managed | Supported outside Anypoint Platform | |
| 35 | Continuous integration deployments | Supported (via API and Maven plugin) | Supported (via API, Maven plugin, Anypoint CLI) | Supported (via API and Maven plugin) | |
| Maven version should be at least 3.7 | |||||
| 36 | Built-in notifications | Not supported | Supported | Supported | |
| 37 | Custom notifications (CloudHub Connector) | Not supported | Supported | Not supported | |
| 38 | Log forwarding | Manual | Supported (per app) | Manual | |
| 39 | Message broker | Fully managed (Anypoint MQ) | Fully managed (Anypoint MQ) | Fully managed (Anypoint MQ) | |
| 40 | App monitoring | Fully managed (Anypoint Monitoring) | Fully managed (Anypoint Monitoring) | Fully managed (Anypoint Monitoring) | |
| 41 | Application isolation | Supported | Supported | Supported | |
| 42 | Auto-recovery | Fully managed | Fully managed | Supported | |
| 43 | Mule clustering | Supported | Not supported | Supported | |
| Support | |||||
| 44 | VM management | MuleSoft | MuleSoft | Infrastructure provider/ public cloud | |
| 45 | Network | MuleSoft | MuleSoft | Infrastructure provider/ public cloud | |
| 46 | App capabilities | MuleSoft | MuleSoft | MuleSoft/ infrastructure provider/ public cloud | |
| 47 | Load balancing and ingress | MuleSoft | MuleSoft | Self-managed | |
| 48 | Backup and restore | Fully managed | Fully managed | Self-managed | |
| Additional Features | |||||
| 49 | Autoscaling | May come in future when Action based pricing starts / consumption based pricing starts | ELA only | Not available | Available |
| 50 | CPU Bursting / Application Bursting | Internally Managed, Not visible to Customer. Application bursting depends on the resource usage of other applications that are deployed in the private space and is not guaranteed. |
0.1 vcore, 0.2 vcore, up-predictable | Available | Available |
| 51 | Smallest CPU / Vcore | 0.1 VCPU = 0.1 VCore | 0.1 Vcore | 0.02 VCPU | 0.02 VCPU |
| 52 | VCore consumption | Same as Vcore | Same as Vcore | Same as Vcore | Same as Vcore |
| 53 | Mule 3 Support | No | Yes | Yes | Yes |
| 54 | Mule API Proxy | Not Supported | Supported | Supported | Supported |
| 55 | JVM Properties |
|
Supported partially | Supported partially | Supported partially |
| 56 | Public Cloud | Shared space | public cloudhub 1.0 | Ingress exposed to public internet | Ingress exposed to public internet |
| 57 | Private Cloud | Private Space | VPC | Ingress disabled | Ingress disabled |
| 58 | Custom Log4j Log forwarding Enable / Disable | Enabled by default for streaming logs to external log collectors | Enable by Request | Build In | Custom |
| 59 | App to App comunication | Using ports 80 and 443, applications inside a private space can communicate using internal load balancer via the private endpoint. Note that this depends on application protocol. | Requires a DLB | K8 Feature | K8 Feature |
| 60 | V Core Freeing | Applications that are stopped still consume vCore licenses. To free vCores, delete applications that are not in use. | Stop Application | Stop Application | Stop Application |
| 61 | API Relocation | To move applications between regions, you must redeploy the application to another shared space or private space in a different region. You cannot move the app to a different region once deployed. | Possible from CH 1.0 from Runtime Manager | Not Possible | Not Possible |
| 62 | HTTP / HTTPS ports | HTTP and HTTPS traffic uses port 8081 | 8081 / 8082 | HTTP and HTTPS traffic uses port 8081 | HTTP and HTTPS traffic uses port 8081 |
| 63 | Anypoint Edge Security | No | No | Yes | No |
| 64 | Secrets Manager | No | Yes for API Proxy | Yes for Ingress | ??? |
| 65 | Tokenizer | No | No | Yes | No |
| 66 | Web application firewall (WAF) policies | No | No | Yes | No |
| 67 | Get From Sandbox functionality | No | Yes | ?? | ?? |
| 68 | Insights | No | Yes | ?? | ?? |
| 69 | Supported Mule Versions | 4.3, 4.4 | All | All | All |
| 70 | Non HTTP Inbound Protocols | Inbound protocols that are not HTTP-based are not supported. | |||
| 71 | correlation ID | In application logs, you cannot search by correlation ID | |||
| 72 | In Anypoint Monitoring, you must set alerts for apps individually. Setting alerts for all apps simultaneously is not supported. | ||||
| 73 | Anypoint Monitoring Log Points The Log Points feature in Anypoint Monitoring allows you to generate logs for apps and APIs in real-time and without writing code. For apps, you can specify the level of logs you want to generate, and for APIs, you can specify properties for the logs. This allows you to extract logs on-demand from applications in real-time, without causing re-deployment or application downtime. Permissions control allows you to manage access. All logs seamlessly flow into log management. |
Not Supported | |||
| 74 | Custom Notification | Not Supported | |||
| 75 | Cloudhub Connector | Not Supported | |||
| 76 | Application Name Uniqueness | In CloudHub 2.0, the same application name can be used in different deployments in the same private space as long as they are in different environments or organizations. | In CloudHub 1.0, application names had to be unique, globally, per region. | ||
| 77 | configure multiple public endpoints | Applications now have public and private endpoints by default. You can also configure multiple public endpoints. You can access the endpoint addresses in Runtime Manager. | |||
| 78 | Flex Gateway | Cannot be deployed into Cloudhub 2.0 | Cannot be deployed into cloudhub 1.0 | Cannot be deployed into RTF | Cannot be deployed into RTF |
Default endpoints : An end point is automatically exposed post deployment. In cloudhub this ends up as a us-e2.cloudhub.io end point, in cloudhub 2.0 this appears as ….. [TODO]
URL rewriting : is similar to DLB mapping rules
Plans for Assisted Workflow and workload migration to private space from VPC to Private Space
Private space is similar to heroku space
Cloudhub 1.0 to Cloudhub 2.0 Migration
Step 1 : Catalogue API in CH 1.0, V Core and worker numbers, Heap Consumption
Step 2 : Allocate similar cores to the equivalent VCPU
Step 3 : Automate Migration from CH 1.0 to CH 2.0 with redeployment
Step 4: Cutover
Networking
https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-connection-to-external-network
Cloudhub 2.0 VCore Sizing
| vCore Size | vCPU | Heap Memory | Total Memory | Storage |
|---|---|---|---|---|
| 0.1 | 0.1 | 500 MB | 1 GB | 8 GB |
| 0.2 | 0.2 | 1 GB | 2 GB | 8 GB |
| 0.5 | 0.5 | 1.3 GB | 2.6 GB | 10 GB |
| 1.0 | 1.0 | 2 GB | 4 GB | 12 GB |
| 1.5 | 1.5 | 3 GB | 6 GB | 24 GB |
| 2.0 | 2.0 | 4 GB | 8 GB | 40 GB |
| 2.5 | 2.5 | 4.75 GB | 9.5 GB | 50 GB |
| 3.0 | 3.0 | 5.5 GB | 11 GB | 60 GB |
| 3.5 | 3.5 | 6.5 GB | 13 GB | 70 GB |
| 4.0 | 4.0 | 7.5 GB | 15 GB | 88 GB |
