CloudHub 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 and Deploy to CloudHub.

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

Through this same console you can deploy to CloudHub as well as to other registered servers. You can also manage deployed applications.

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 more general information about CloudHub, see CloudHub.

CloudHub 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 REST API.

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

Workers have the following characteristics:

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

Worker sizes have different compute, memory, and storage capacities. You can scale workers vertically by selecting one of the available worker sizes:

Workers with 0.1 vCores and 0.2 vCores:

Workers with 1 or more vCores:

Each worker has a minimum of 8 GB of storage allocated, which is used for both system and application storage, with about 3.0 GB used for OS and Mule components. If your application requires more storage (for example, verbose logging), use a worker with two or more vCores, enabling the application to access additional storage.

Only running applications count toward worker usage.

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

The metaspace limit for apps deployed to CloudHub is currently unlimited, regardless of the worker 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 workers and enabling persistent queues to distribute workloads across workers. See Worker Scaleout and Persistent Queues.

CloudHub monitors workers to verify that they are operating correctly. If you enable automatic restarts, CloudHub also automatically restarts applications, if necessary.

CloudHub offers worker clouds in different regions of the world: North America, South America, the European Union, and Asia-Pacific. For the complete list of supported regions, see Regional Services.

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 and US-Gov control planes, MuleSoft hosts the management console and platform services in the United States. For the EU control plane, MuleSoft hosts these services in Europe.

The region that you deploy your application to determines the domain provided for your application. For example, if you deploy an application named myapp to Canada (Central), the domain used to access the application is myapp.ca-c1.cloudhub.io. The load balancer used to route requests resides in the same region as your application.

For more information about deploying applications to different regions, refer to Deploy to CloudHub. For more information about CloudHub security and compliance, download the Anypoint Cloud Security & Compliance whitepaper.

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

CloudHub is designed to be highly available and scalable through redundancy, intelligent healing, and zero-downtime updates. It also enables customers to scale and benefit from added reliability through high availability features.

CloudHub architecture provides a secure platform for your integrations.

Securing your payload data is critically important. To this end, CloudHub does not inspect, store, or otherwise interact directly with payload data. CloudHub workers provide a secure facility for transmitting and processing data by giving each application its own virtual machine. This ensures complete isolation between tenants for payload security, and isolation from other tenants’ code.

CloudHub collects monitoring, analytics, and log data from CloudHub workers and may perform actions on behalf of the user on CloudHub workers. All communication between CloudHub platform services and the worker cloud is secured using SSL with client certificate authentication. This ensures that unauthorized parties cannot read data and that they cannot initiate unauthorized actions.

Secure properties can also be loaded as part of your application bundle. If a property is flagged as secure, it won’t be viewable even through the Runtime Manager console, in fact, it is never propagated anywhere outside the CloudHub worker running the application.

For more information about MuleSoft’s approach to security, please see the Anypoint Cloud Security & Compliance whitepaper.