CloudHub 2.0 Architecture

An integration application is any integration that you’ve built using Anypoint Studio. These applications can do everything from synchronizing data from Salesforce to a database, to publishing a SOAP or REST API, to creating complex orchestrations of business processes.

For more about creating and deploying integration applications, see CloudHub 2.0 Overview and Deploying Apps to CloudHub 2.0.

Runtime Manager is integrated into Anypoint Platform. Sign in with your Anypoint Platform credentials to deploy and manage your integration applications at runtime. The console provides monitoring information from the platform services and also functions as a comprehensive dashboard for both application-level and account-level management.

Administrator account holders can use the Anypoint Platform to add and manage other users in the organization, define user roles, and create and manage sandbox environments. For information, see Access Management Overview.

Platform services are responsible for coordinating all aspects of the platform. They coordinate deployment of applications, monitor integrations, provide analytics data, store application data, run scheduled jobs, and more. Many of these services are also exposed through the CloudHub 2.0 REST API.

Replicas are dedicated instances of Mule runtime engine that run your integration applications on CloudHub 2.0.

Replicas have the following characteristics:

The memory capacity and processing power of a replica depends on how you configure it at the application level.

Replica sizes have different compute, memory, and storage capacities.

You can scale replicas vertically by selecting one of the available vCore sizes:

Replicas with fewer than 1 vCore:

Replicas with 1 or more vCores provide performance consistency.

Each replica has a minimum of 8 GB of storage, which is used for both system and application storage. If your application requires more storage (for example, verbose logging), use a replica with two or more vCores, enabling the application to access additional storage in /tmp.

All running applications count toward replica usage. Stopped applications do not.

If your applications require more vCores than are available, CloudHub 2.0 allows you to create the application, but you cannot start it until the additional vCores become available. To increase vCore allocation, stop or delete an application or contact your account manager to increase your subscription’s vCore allocation.

The metaspace limit for apps deployed to CloudHub 2.0 is currently 256 MB, regardless of the replica size. The initial metaspace size is 128 MB; metaspace garbage collection begins after the metaspace reaches that threshold.

You can scale your applications horizontally by adding multiple replicas for persistent queues. See Replica Scale-out.

CloudHub 2.0 monitors replicas to verify that they are operating correctly, and automatically restarts applications if necessary.

If your organization uses the Anypoint Integration Starter package or Anypoint Integration Advanced package, CloudHub 2.0 uses replica sizing for application deployment. You can choose from the following replica sizes based on the application profile or size and display the equivalent in terms of vCores:

Replica sizes with the suffix .mem are memory-intensive options with the same compute.

During the monthly patching cycle, your applications automatically migrate to an equivalent replica size. Application deployment through the Mule Maven Plugin is not yet supported. However, you can deploy using the Runtime Manager UI and the Application Manager Experience APIs by leveraging a new field under target.deploymentSettings called instanceType.

CloudHub 2.0 provides the ability to deploy apps in different regions of the world: North America, South America, the European Union, and Asia-Pacific.

This global distribution enables you to host your integration in the location closest to your services, thus reducing latency. It can also provide for adherence to local laws, such as the EU Data Protection Directive. For the US Cloud and MuleSoft Government Cloud control planes, MuleSoft hosts the management console and platform services in the United States. For the EU Cloud control plane, MuleSoft hosts these services in Europe.

The region that you deploy your application to determines the domain provided for your application.

The load balancer that CloudHub 2.0 uses to route requests resides in the same region as your application.

Because different levels of security and isolation are needed depending on the service, the platform provides three different levels of multitenancy.

CloudHub 2.0 is designed to be highly available and scalable through redundancy, intelligent healing, and zero-downtime updates. It also enables you to scale and benefit from added reliability using clustering.

CloudHub 2.0 monitors all applications and restarts them automatically if necessary so that your applications recover without your intervention.

CloudHub 2.0 displays a notification that the app is restarting and another to report the success or failure of the restart.

The logs report the details of the restart procedure. You can also receive alerts and diagnostic information if your application becomes unresponsive. For more information, see Configuring Application Alerts.

CloudHub 2.0 architecture provides a secure platform for your integrations.

CloudHub 2.0 does not inspect, store, or otherwise interact directly with payload data. CloudHub replicas provide a secure facility for transmitting and processing data by giving each application its own container. This ensures complete isolation between tenants for payload security, and isolation from other tenants’ code.

CloudHub 2.0 collects monitoring, analytics, and log data from CloudHub replicas and might perform actions on behalf of the user. All communication between platform services and CloudHub is secured using SSL with client certificate authentication, ensuring that unauthorized parties cannot read data or initiate unauthorized actions.

You can also protect application property values. Protected property values are not viewable or retrievable by any user. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization.

For more information about MuleSoft security, see the Anypoint Cloud Security & Compliance whitepaper.