With the release of MuleSoft’s CloudHub 2.0 last year, many IT teams have been asking themselves a classic question: do we upgrade or not? In this post we’ll provide an overview of the most important changes and benefits offered by this major release, as well as calling out the smaller improvements that may be decision factors for certain use cases.

First, though, let’s save a few readers some time by summarizing the kinds of customers that CloudHub 2.0 might not or might be for. If you’re using CloudHub 1.0’s persistent virtual machine (VM) queues and need to keep using them, CloudHub 2.0’s shift from VMs to containers will rule out that option for you. Conversely, if your enterprise is already using MuleSoft’s Anypoint Runtime Fabric (RTF) on prem or in a private cloud, CloudHub 2.0’s containerized approach will look extremely familiar to you and might well offer improvements in manageability. Two other categories of customer that should consider the new version are enterprises that are entirely new to CloudHub (or to MuleSoft itself), and enterprises already on CloudHub 1.0 that want to keep their environment as up-to-date as possible and want to take advantage of some or all of the new features we’ll describe below. Note that since CloudHub 2.0 does not support Mule 3 runtimes, an enterprise still using Mule 3 should strongly consider migrating to Mule 4 as its first step before upgrading to CloudHub 2.0 (and for thoughts and advice on ensuring a successful migration, check out our post: https://www.bigcompass.com/blog/best-practices-for-a-successful-mulesoft-4-migration).

RATIONALE

What is MuleSoft hoping to achieve with this release? In part, 2.0 is aimed at giving IT teams an improved experience in the cloud: a MuleSoft infrastructure that’s easier to deploy and manage, with finer-grained controls and greater flexibility in deployment approaches. Of course, as with most “dot zero” releases there are some rough edges to the offering, but MuleSoft is actively smoothing these with frequent fixes and updates.

THE BIG CHANGES

There are three really significant changes—one architectural and two aimed at improved manageability—that MuleSoft has rolled out with this version: containers, teams, and private spaces. Let’s take a quick look at each.

From workers to replicas

As mentioned in the introduction, CloudHub 2.0 marks a major shift in infrastructure design. Where 1.0 ran apps on virtual machines called “workers”, 2.0 places deployed apps in containers (referred to as “replicas”). This shift, of course, mirrors the business community’s broader migration to containerized solutions, for all of the same reasons of scalability and manageability. CloudHub 2.0 replicas—dedicated instances of the Mule runtime engine—can be rapidly scaled to match workloads (especially important where big but episodic jobs used to require the expensive pre-allocation of compute capacity), enable the isolation of apps from other apps (so one failure doesn’t pull down the whole system), and have increased flexibility for being deployed in specific global regions selected by the customer to maximize performance.

From roles to teams

CloudHub 2.0 also brings a real improvement in administrative manageability and security with an evolution from role-based to team-based permissions. This new approach to bundling follows the hierarchical model already common in public clouds, where “child” teams inherit all permissions assigned to their “parent” teams (while still being able to add additional, team-specific permissions as necessary). Team-based permissions reduce or eliminate much previously-duplicated admin work, and in doing so, they’ll reduce the chances that your administrators will create security gaps due to permissions complexity and lack of time.

From VPCs to private spaces

In CloudHub 1.0, customer environments were set up within ‘virtual private clouds” (VPCs), and with 2.0 this approach has been modified to a choice between shared spaces and private spaces. Private spaces are (like VPCs) both virtual and private, but they also enable some powerful new options: firewall rules can be created for both inbound and outbound traffic (with 1.0 only outbound was allowed), both HTTP and HTTPS can be used (in a shared space only HTTPS is permitted), and private spaces can easily connect to your VPCs in AWS through an AWS Transit Gateway. Private spaces also simplify configuration effort, because a Dedicated Load Balancer (DLB) no longer has to be set up separately—and what’s more, the DLB service with 2.0 auto-scales with the load.

THE SMALLER CHANGES

Other changes with CloudHub 2.0—while not as transformational as those discussed above—may be worth taking into account by customers pondering a migration. Let’s run through them at a high level:

• Rolling updates are now complemented by a “recreate deployment” option which completes significantly faster and can help with development and rapid iteration scenarios.
• Additional core sizing options, with 0.5 and 1.5 cores adding to the previous list of 0.1, 0.2, 1.0, and 2.0 cores—a list that often forced tough decisions when volumes fell right in between, say, the 0.2 option and the much more expensive 1.0.
• Visibility into ObjectStores, allowing a user to both view and delete keys to create clean slates for testing and re-testing (something which in the past required the creation of a custom endpoint to clear an ObjectStore).
• Previously only possible with on-prem installations, clustering (i.e. running copies of an application, all coordinated through having access to the same ObjectStore) is now available on CloudHub 2.0.
• The requirement for URL uniqueness is now automated through the addition of a randomly-generated six character ID to each new URL. Though aimed at reducing the decision-making effort up front, this change means that developers can’t know beforehand what their application’s relevant URLs will be until it gets deployed—a limitation that makes CI/CD pipelines harder to set up, and requires that apps dependent on the API can only be updated after deployment once the automatically generated URL is available.
• The CloudHub Connector is not supported.  If you are using the CloudHub Connector for custom notifications, you will need to replace this functionality.
• Finally, and in private spaces only, CloudHub 2.0 offers multiple truststores for TLS authentication flexibility.

We hope this has given you a working idea of what makes CloudHub 2.0 different, and some starting points for further research. Obviously, any decision to upgrade from CloudHub 1.0 to 2.0—or to adopt 2.0 from scratch—is one that will involve many factors in addition to those discussed in this post. We’ll be diving into more detail about 2.0 in future posts, and in the meantime interested readers should feel free to set up a live discussion with Ben Stone.