Introduction
CloudHub 2.0 (CH 2.0) is the latest deployment option for MuleSoft Runtime, made available in the second half of 2022. This blog will cover Migrating to CloudHub 2.0 – what you need to know. CloudHub (CH) 2.0 is a dynamically scaled, containerised service based on Kubernetes, similar to the Runtime Fabric (RTF) deployment option, which also uses containers to deploy Mule Applications.
Some readers will know that RTF can either be a Cloud IaaS or an On-prem Hybrid solution with only the Control Plane managed by MuleSoft. CH 2.0, however, is a fully managed PaaS, which means that both planes, Runtime and Control, are managed by MuleSoft with all the benefits that they bring to Operations.
CH 2.0 is already the default option for new applications being deployed to CloudHub, and MuleSoft will increase efforts to migrate existing applications to this new hosting option. This is because CH 2.0 is less resource intensive, as well as having numerous advantages over CloudHub 1.0, as we will see in detail in this blog.
With that said, it’s also worth clarifying that CH 1.0 will still be fully supported for the foreseeable future, as there is no end-of-life plan as of yet, and, of course, it can be used in parallel with CH 2.0, sharing resources (vCores) from the same pool.
A detailed comparison of CH 2.0, CH 1.0, and RTF can be found on this MuleSoft documentation page, so I won’t go into much detail about the differences, but I will highlight some of the main advantages of CH 2.0 and recommend some tips and good practices for migrating from CloudHub 1.0 to CloudHub 2.0.
Main Advantages and Limitations
The advantages of CloudHub 2.0 over CloudHub 1.0 are numerous, and a full list can be found here. In a nutshell, the most important are:
- An improved Virtual Private Cloud (VPC) called Private Space supports outbound firewall rules and multiple TLS Contexts in each private space allowing multiple vanity domains, and has a small set of pre-allocated inbound and outbound static IPs to simplify whitelisting.
- A new isolated, lightweight, containerised environment called Replica, replaces the Mule Worker, and will be where Mule APIs will be deployed in CH 2.0. Spinning up a Kubernetes pod is a lot faster and requires less CPU and Memory compared to a virtual computing environment like EC2 (Amazon Elastic Compute Cloud), which is used by CH 1.0 and the Mule Workers.
- On top of the existing vertical sizing options for a Mule Worker, Replicas have some additional vCore sizing options for increased granularity (e.g. 0.5, 1.5, 2.5, 3.0, 3.5 vCores).
- The introduction of an Ingress Controller, which replaces the Dedicated Load Balancer (DLB), will give access for the first time to load balancer logs, support public and private endpoints and will also support URL rewriting.
- Clustering is available on CH 2.0 when deploying the application to two or more Replicas.
- Access to log4j configuration for Log Forwarding without contacting Mule support.
- The high availability of VPNs is supported out of the box.
On the other hand, some of the main deviations of a CH 2.0 application that should be taken into consideration before migrating are:
- CH 2.0 applications can only listen to the 8081 port for HTTP and HTTPS traffic. This will probably require configuration changes in the application to make it compliant with the new port requirement.
- In an effort to promote Anypoint Monitoring, Insights and Custom Alerts are not supported anymore at the application level. This means that support and ticketing flows based on custom alerts must be migrated to Anypoint Monitoring at the same time or even before migrating to CH 2.0.
- Because of significant performance limitations, persistent queues are not supported with CH 2.0. So, to implement a message reliability pattern, only external to the application message brokers can be used (Anypoint MQ, JMS, IBM RabbitMQ etc).
- At the time of writing, non-HTTP-based inbound protocols, DataGraph and Flex Gateways are not supported, but they are on the roadmap to be made available later on.
Careful consideration of the deviations and limitations is required in order to create a migration plan, as some MuleSoft APIs might not be suitable for migration just yet. Continue to the next section for tips and recommendations for those APIs that fulfil the requirements to be migrated from CloudHub 1.0 to CloudHub 2.0
Migration from CH 1.0 to CH 2.0
For applications that were developed and deployed to CH 1.0 you must follow a few steps to redeploy them to CH 2.0:
- Create and configure a Private Space(s), if necessary.
As a rule of thumb, a private space is necessary if the application must run in isolation from the public internet, must connect to backend systems in a private network or must have a vanity domain name. - Ensure the API Specification published to Exchange has a different name from the API Implementation.
It’s a common practice for many teams to use the exact same name for the API Specification and the API Implementation, and that was totally fine with CH 1.0, but in CH 2.0, this will not work. - Add the following file to your project if it is not already there:
project-root/exchange-docs/home.md
The file can be empty, but it must exist; otherwise, you won’t be able to publish the asset to Exchange. - If you are using the Mule Maven Plugin to deploy, follow the instructions described in these 2 pages to update the POM file
- It’s important to highlight that CH 2.0 requires the artefact to be published to Exchange before it can be deployed to Runtime Manager. Exchange can be used as an Artefact Repository in accordance to the CI/CD Strategy that we recommend in this blog.
- After deploying the application to CH 2.0, add or remove public and private endpoints based on the intended use of the application.
Note that the endpoint pattern for CH 2.0 is the following:
myapp–uniq-id.shard.region.cloudhub.io
Where:- unig-id is a 6-digit value appended to the app name to ensure uniqueness.
- shard is a 6-digit value associated with the space (private or shared) that the app is deployed to. Each private space gets a unique value for shard.
- similar to CH 1.0, the region is the last subdomain before cloudhub.io, but the values for CH 2.0 are different. Check here for the full list.
And the private endpoint is:
myapp–uniq-id.internal-shard.region.cloudhub.io
- And the last step is to test the newly deployed MuleSoft API and, if the test is successful, un-deploy the CH 1.0 version of the same application to return the unused vCores back to the pool.
With the above steps, individual APIs can be migrated from CloudHub 1.0 to CloudHub 2.0 independently of the rest of the flow, allowing a gradual transition to the new architecture instead of a big bang which is riskier. Especially for large application networks with hundreds of MuleSoft APIs, it would be smart to follow a phased approach for migration to disrupt the business as little as possible.
Conclusion
This blog Migrating to CloudHub 2.0 – What you need to know, discusses the advantages of CloudHub 2.0 and provides tips and good practices for migrating existing applications from CH 1.0 to CH 2.0. By following the steps outlined in this blog, you can migrate your applications seamlessly and begin to take advantage of the many benefits that CH 2.0 has to offer, like increased performance and improved security.
Keep in mind that CH 2.0 might not be suitable for your entire application network just yet. There are still some limitations which are expected to be lifted soon, but applications that are not impacted by these can be migrated now and work in parallel with those that will remain in CH 1.0 for some time. After all, migrating in phases might be the right move depending on the circumstances.
If you want to learn more about migrating to Ch 2.0 from CH 1.0 with your organisation or want to learn how Devoteam can help you migrate, please do not hesitate to contact us.
