Solace Cloud Deployment Ownership Models

The ownership model refers to the location of the region where the Mission Control Agent and software event brokers are installed. These are the variants of ownership:

  • Public Clusters: Dedicated event broker services are deployed in Solace-controlled shared VPC/VNets on public cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure.
  • Dedicated Clusters: Dedicated event broker services are deployed in Solace-controlled VPC/VNets dedicated to the customer on public cloud providers such as AWS, GCP, and Azure.
  • Customer-Controlled Clusters: Dedicated event broker services are deployed in a customer's on-premises or cloud-based Kubernetes cluster, such as OpenShift, Rancher (RKE2), Amazon (EKS), Azure (AKS, ARO), Google (GKE), Alibaba (ACK), Huawei (CCE), Oracle Kubernetes Engine (OKE) and more.

For a list of supported deployment locations, see Deployment Regions.

For the complete list of supported Kubernetes environments, see Deployment Architecture for Kubernetes.

If you require a deployment to a region in China, these deployments are supported only for Customer-Controlled Clusters. Deployments at this time are not supported in Public Clusters or Dedicated Clusters. For more information, see Deployments in China.

Public Clusters

For the simplest deployment, event broker services are deployed within the customer's account in Solace Cloud, using the customer's choice of cloud provider and region. In this scenario, the software event brokers are dedicated to the customer and not shared. Because Solace maintains control over this deployment, there isn't any additional customer overhead when adding services or regions. This is the standard deployment option, and is described in Getting Started with Solace Cloud .

Illustration depicting the concepts described in the surrounding text.

Use Cases

This ownership model is a good choice when:

  • Applications and clients can connect over public internet
  • There are cost-sensitive workloads
  • The fastest time to market is required
  • A development or proof-of-concept environment is needed

Dedicated Clusters

In this deployment configuration, event broker services are deployed to Kubernetes clusters owned by Solace and dedicated to the customer. In this dedicated virtual network, Solace deploys a Mission Control Agent to orchestrate event broker services. The agent creates a secure connection back to the Solace Home Cloud and relays user commands from the console to the software event brokers. Solace maintains control of the address space and network security groups.

Illustration depicting the concepts described in the surrounding text.

With Solace Cloud deployed in a Dedicated Cluster, Solace installs all the components with the sizing required by the customer. In this scenario, Solace maintains the infrastructure, but the customer may provide the VPC/VNet and subnet CIDR blocks. Depending on the connectivity model, the customer may be required to provide sufficient information to establish network peering between the Solace and customer virtual networks.

Use Cases

This model is a good choice if:

  • Single-tenant VPC/VNet ( i.e., network traffic isolation) is important
  • Connectivity to on-premises applications and network is required
  • The customer prefers VPC/VNet management and security concerns to be included in the SaaS offering

Customer-Controlled Clusters

For this scenario, event broker services are installed in a customer's on-premises or cloud-based Kubernetes cluster. Solace Cloud uses Kubernetes StatefulSets to manage the deployment of event broker services.

Illustration depicting the concepts described in the surrounding text.

Use Cases

This type of deployment is a good choice for:

  • Hybrid (cloud and on-premises) event mesh use cases
  • Data movement between legacy and Kubernetes-based applications
  • Highly sensitive data that cannot be on the cloud
  • Situations where an on-premises deployment is a requirement for other reasons (e.g., all applications are on premises)

Supported Platforms

Deployment of the Customer-Controlled Cluster follows a process that begins after you've met with Solace and defined requirements with them.Your deployment will be easier if you supply certain information to the Solace team. The questions listed in the Questionnaire: Deploying in a Customer-Controlled Cluster section guide you through the things you should consider before you deploy Solace Cloud. For an overview of the process, see Process to Deploy Solace Cloud in a Customer-Controlled Cluster.

For details about the architecture of Solace Cloud in a Kubernetes cluster and a summary of the details to deploy Solace Cloud, see Deployment Architecture for Kubernetes.