CloudHub 2.0 — An up-close look
CloudHub 2.0 Features and Architectures
Introduction:
MuleSoft has released their containerized fully managed iPaaS offering that makes it possible to deploy MuleSoft API/applications as lightweight containers on cloud. This offering is named as CloudHub 2.0 — the next generation of our very own MuleSoft CloudHub 1.0. The key benefits that makes CloudHub 2.0 a lucrative iPaaS deployment choice is as follow -
- Application clustering on more than one replica seamlessly.
- Container-based (as opposed to VM based deployment in CloudHub 1.0) deployment with better availability and scalability.
- Zero infrastructure maintenance and advance setup required for application deployment on shared space.
- vCore allocation is possible with more granularity than CloudHub.
- Outbound Firewall rule configuration to control egress traffic.
- Ingress self service log.
- AWS service roles for resource access control. More on AWS service role is in below link — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/service-role.html
Where CloudHub 2.0 precedes CloudHub 1.0:
Let us now focus on some of the improvements introduced by MuleSoft in CloudHub 2.0 than its predecessor.
- Packing multiple listeners in one API to optimize the resource usage can be eliminated from deployment strategy with newly added fractional vCore offerings in CloudHub 2.0
- Re-imagined CloudHub 1.0 VPC as private space in CloudHub 2.0 — where automatically Private Network can be assigned to applications.
- Auto scaling of private Ingress load balancer (which is the equivalent of Dedicated Load Balancer in CloudHub 1.0) makes CloudHub 2.0 more elastic.
- VPN high availability is by default.
- Applications deployed on CloudHub 2.0 have both public and private endpoints by default. Configuring multiple Public endpoints for one application is also possible and endpoint addresses can be accessed from Anypoint Runtime Manager.
- In-place edit and update of the TLS context and truststore of the Ingress layer.
- Enable log streaming to external log aggregator by custom log4j.xml without raising request for enable/disable the feature with support.
- Self-service logs for Ingress are available through private space. Titanium users can download the logs through Anypoint monitoring
- Applications deployed into a private space can communicate internally on a private endpoint via an internal load balancer. This allows inter application communication within private space without letting the traffic traverse outside the private space.
- Both HTTP and HTTPs traffic use port 8081 (unlike in CloudHub 1.0 where HTTP traffic uses port 8081 and HTTPs traffic uses 8082).
- Unlike CloudHub 1.0, application names need not to be unique across CloudHub 2.0. This eliminates the need for creating a globally unique nomenclature strategy. The application names need to be unique across the environment or across the organization only. On deployment to CloudHub 2.0 the application names are appended with a unique id and shard to make the API name unique universally in CloudHub. If an application name “testapp ‘’ deployed on US East (N. Virginia) then the application DNS name will be testapp-uniq-id.shard.usa-e1.cloudhub.io. Where uniq-id is a 6 digit value appended to the app name to maintain the uniqueness and shard is a 6 digit value associated with a private or shared space where the application is deployed.
Infrastructure and Application considerations:
- Unlike CloudHub 1.0, CloudHub 2.0 does not support Direct Connect and VPC Peering for extending with external networks. Only VPN and Transit Gateway attachments are the available option for the same. On deletion of a private space with a transit gateway attached, the gateway will be preserved for repurposing with another private space.
- Applications if not running but deployed on CloudHub 2.0 still consume vCore licenses. To free up vCore applications need to be deleted.
- Redeployment is the only option to move applications between regions. Once an application is deployed to one region it is not possible to move to another region without redeployment.
- Unlike CloudHub 1.0 VPC, a private space can be associated with multiple environments based on the type of the environment (sandbox or production). Instead of environment, now it needs to choose the environment type (among sandbox and production) and individual business groups to which private spaces to be shared. So for example if there are two business groups defined say HR and Finance, then it is possible to share a private space with all environments (say DEV, UAT etc.) of type sandbox under Finance business group or with all environments (PROD) of environment type production under HR business group.
- CloudHub 2.0 only supports Mule 4.3.0 to 4.4.x
- Application bursting depends on the resource usage of other applications that are deployed in the same private space and it is not guaranteed. So an application deployed on private space is running under high load and needs additional resources (CPU or memory) then the allocation of resources depends on the consumption of the same resources by other applications processing traffic at that time.
- Need to use Anypoint MQ or other queue management instead of Persistence queue as it is not supported in CloudHub 2.0
- Secure properties are stored in encrypted, private vaults and no-one including MuleSoft staff can view once it gets created.
- Inbound protocols other than HTTP and HTTPs (like TCP, UDP, SMTP etc.) are not supported.
- Unlike public endpoints, private endpoints does not support mTLS capabilities
- Setting up alerts for Applications are done individually and not simultaneously on all apps in one go.
What is not in CloudHub 2.0:
CloudHub 2.0 does not support the following Infrastructure & Application features —
- Anypoint Security
- Secret Manager
- Tokenizer
- Web Application Firewall Policies
- Get From Sandbox feature — which enables moving application from sandbox VPC to Production VPC in CloudHub 1.0
- Insights — Need to use Anypoint Monitoring instead
- Mule Runtime versions prior to 4.3.0
- Overwriting JVM parameters
- Overriding default JVM truststores with custom truststores
- Log points in Anypoint Monitoring
- Custom Notification creation and CloudHub connector
- TLS 1.0 is not supported
- DataGraph is not supported
Architecture Overview :
Runtime Manager — User Interface through which deployment and monitoring of application are managed.
Platform Services — Shared services those are responsible to coordinate the deployment and monitoring of applications, providing analytics data store application data, run schedule job and many more. Many of these services are also exposed through CloudHub 2.0 REST API.
CloudHub 2.0 — Instance of elastic cloud of replicas that runs Mule applications. CloudHub 2.0 Replicas have following characteristics —
- Each Replica has a specific amount of capacity (CPU and Memory) based on the selected vCore size.
- Each Replica runs in a separate container that ensure isolation from other applications
- Each Replica is deployed and managed independently
- Each Replica runs in a specific global region like US, EU or APAC
- Each Replica has a minimum of 8 GB of storage that is used for both system and application storage. To increase the storage capacity further add two or more workers to replica that enabling the application to access additional storage in /tmp.
- If applications need more vCore than what is available , CloudHub 2.0 still allows the deployment but applications can not be started to use until additional vCore is added by deleting the unused application and making vCore free or by purchasing additional vCore.
- The metaspace limit of applications deployed to CloudHub 2.0 is currently 256 MB. By definition metaspace is a native memory region in a JVM that stores metadata for classes and with more classes loaded into the JVM the metaspace grows. In CloudHub 2.0 the metaspace garbage collection begins after it reaches the threshold limit of 128 MB.
Shared Global Regions — CloudHub 2.0 provides the ability to deploy applications on different regions across the globes and major continents. This global distribution enables host applications closest to services and reduces latency. The load balancer used to route the traffic resides within the same region where the application gets deployed.
Multitenancy — Three different levels of multitenancy are offered based on different security and isolation need.
- Shared Global Space — Co-tenancy without having access to applications and data of other tenant
- Single Tenant Private Space — Virtual and isolated space in CloudHub 2.0 for deployment
- Management Console and Platform services — control plane is shared by all tenants.
CloudHub 2.0 Availability and Scalability :
CloudHub 2.0 offered out of the box scalability and availability with below features —
Redundant Platform — All CloudHub 2.0 platform services (from load balancing to the API layer) are supported with at-least one built-in layer of redundancy. Services are available in at least two data centers geographically at least 60 miles apart. This redundancy ensures platform availability even if there is a Data Center outage.
Intelligent Healing — CloudHub 2.0 monitor replicas and apply a self healing mechanism to recover from any problem. The underlying hardware failure platform migrates the application to a new replica. In case of application crash, the platform detects the crash and deploy the replica automatically.
CloudHub 2.0 Zero Downtime Upgrade — It supports upgrading applications on the fly without making end consumers impacted with any outage. If the application uses the rolling update option then during deployment of the upgraded version of application, users can still connect with the existing application version. Old versions of applications remain on-line still the new version of application become up and running and users experienced zero downtime during cutover.
Clustering — This feature provides scalability, workload distribution and added reliability to applications. This is powered with scalable load balancing and replica scale out features. With clustering multiple replicas can be added to an application to make the horizontal scaling possible. When deployed on two or more replicas, the HTTP load balancing service distributes requests across these replicas. CloudHub distributes requests on a round-robin basis.
Security:
CloudHub 2.0 does not touch, store or interact directly with application payload data. Replicas provide each application its own container and thus enforce isolation between tenants to secure payloads and code. CloudHub 2.0 collects monitoring, analytics and log data from replicas and may perform action on behalf of users. All communication between platform services and CloudHub applications are on secured transport channels using SSL with client certificate authentication, ensuring that unauthorized parties can not read data or initiate unauthorized actions. Application property values can be made secure in such that those values can not be viewable or retrievable by any user.
Conclusion:
CloudHub 2.0 is the next version of CloudHub iPaaS offering released by MuleSoft this year (2022). This blog is an attempt to provide the features of CloudHub 2.0 and the major differences with CloudHub 1.0. For certain needs CloudHub 2.0 is a better choice. However for certain other needs it is still good to go for CloudHub 1.0. This blog is an attempt to discuss the criteria to be considered to move from CloudHub 1.0 to CloudHub 2.0. Thank you for your patient reading. Please give a clap if you like the article.
