Multitenancy support

IBM® Software Hub supports different installation and deployment mechanisms for achieving multitenancy.

According to Gartner, multitenancy is defined as:

Multitenancy is a reference to the mode of operation of software where multiple independent instances of one or multiple applications operate in a shared environment. The instances (tenants) are logically isolated, but physically integrated. The degree of logical isolation must be complete, but the degree of physical integration will vary.

https://www.gartner.com/it-glossary/multitenancy

Achieving multitenancy with multiple instances of IBM Software Hub (recommended)

You can install the IBM Software Hub control plane multiple times on the same cluster by installing each instance of the control plane in a separate project (Kubernetes namespace).

Note: The following components are installed once on the cluster and shared by any instances of IBM Software Hub on the cluster:

IBM Cloud Pak foundational services Certificate manager
IBM Cloud Pak foundational services License Service
Scheduling service

Each instance of IBM Software Hub has its own operators project and operands project. This installation architecture offers complete logical isolation of each instance of IBM Software Hub with limited physical integration between the instances.

When you set up your cluster, a Red Hat® OpenShift® Container Platform cluster administrator can create multiple projects to partition your cluster. Within each project, you can assign resource quotas. Each project acts as a virtual cluster with its own security and network policies.

In addition to being logically separated, you can use different authentication mechanisms for each instance of IBM Software Hub.

This tenancy model addresses the following use cases:

Partitioning your non-production environment from your production environment in a continuous integration, continuous delivery (CICD) pipeline. In this model, tenants work in discrete, isolated units with a clear separation of duties.
Creating instances for different departments or business units that have distinct roles and responsibilities within your enterprise. In this model, each tenant has their own authentication mechanism, resource quotas, and assets.

This tenancy model also offers several advantages:

You can minimize your overhead costs by deploying multiple instances on the same cluster.
The cluster administrator can establish tenant-specific quality of service characteristics in each instance.
The cluster administrator can assign instance administrators to manage a given instance of IBM Software Hub
The instance administrator can control which services are deployed in the project and can manage the resources that are associated with the project. However, the instance administrator does not have access to cluster-level settings and cannot change the resource quotas for their project.

Related references

For information about projects, see Supported project (namespace) configurations.

Achieving multitenancy within a single instance of IBM Software Hub

You can install a single instance of IBM Software Hub on your Red Hat OpenShift cluster. The instance uses a single authentication mechanism for all users, and each user is assigned to the appropriate role within the instance.

In this installation architecture, tenancy occurs at the resource level and users can see only resources that they are given access to. The following types of resources support logical isolation:

Projects (collaborative workspaces)

Users must be explicitly added as collaborators to access the contents of a project. In this way, you can enforce logical isolation between projects. For example, you can create analytics projects to support specific teams or departments within your organization.

Deployment spaces

Users must be explicitly added as collaborators to access the contents of an analytics deployment space. In this way, you can enforce logical isolation between deployment spaces.

Service instances

Some services, such as integrated databases, can be deployed multiple times within a single deployment of IBM Software Hub. These deployments are called service instances. Users must be given explicit access to a service instance to interact with it. In this way, you can enforce logical isolation between service instances.

For an additional layer of isolation, service instances can be deployed to separate projects, called tethered projects.

Some services do not support service instances. The resources that are associated with those services are available to any users who have access to the service. And sometimes, all of the users who have access to the instance of IBM Software Hub have access to the service. However, some services can deploy workloads into tethered projects, which allow you to isolate tenant workloads and establish tenant-level resource quotas.

This configuration is physically integrated but does not support complete logical isolation.

Multitenancy for services

The IBM Software Hub platform supports multiple mechanisms for achieving service multitenancy. However, not all services support the same mechanisms. The platform offers the following mechanisms:

Installing a service one time in each project where the control plane is installed. (This is the most common method for achieving multitenancy.)
Installing a service one time in the same project as the control plane and provisioning multiple instances of the service in that project.
Installing a service one time in the same project as the control plane and provisioning multiple instances of the service in tethered projects.

In the following table, an asterisk (*) indicates that the service supports multiple instances that use the same pool of resources.

Service	1. Install the service in separate projects	2. Install the service once and deploy multiple instances in the same project	3. Install the service once and provision multiple instances in tethered projects
AI Factsheets	Yes	No	No
Analytics Engine powered by Apache Spark	Yes	Yes*	No
Cognos Analytics	Yes	No. One instance only.	Yes. One instance in each tethered project.
Cognos Dashboards	Yes	No	No
Data Gate	Yes	Yes	No
Data Privacy	Yes	No	No
Data Product Hub	Yes	No	No
Data Refinery	Yes	No	No
Data Replication	No	No. One instance only.	No
DataStage	Yes	Yes	No
Data Virtualization	Yes	No. One instance only.	Yes. One instance in each tethered project.
Db2	Yes	Yes	Yes
Db2 Big SQL	Yes	Yes	No
Db2 Data Management Console	Yes	No. One instance only.	No
Db2 Warehouse	Yes	Yes	Yes
Service	1. Install the service in separate projects	2. Install the service once and deploy multiple instances in the same project	3. Install the service once and provision multiple instances in tethered projects
Decision Optimization	Yes	No	No
EDB Postgres	Yes	Yes	No
Execution Engine for Apache Hadoop	Yes	No	No
IBM Knowledge Catalog	Yes	No	No
IBM Knowledge Catalog Premium	Yes^¹	No	No
IBM Knowledge Catalog Standard	Yes^¹	No	No
IBM Manta Data Lineage	Yes	No	No
IBM Match 360	Yes	No	No
IBM StreamSets	No	No	No
Informix	Yes	Yes	No
MANTA Automated Data Lineage	Yes	No	No
MongoDB	Yes	Yes	No
OpenPages	Yes	Yes	Yes
Orchestration Pipelines	Yes	No	No
Planning Analytics	Yes	No. One instance only.	Yes. One instance in each tethered project.
Service	1. Install the service in separate projects	2. Install the service once and deploy multiple instances in the same project	3. Install the service once and provision multiple instances in tethered projects
Product Master	Yes	No	No
RStudio® Server Runtimes	Yes	No	No
SPSS Modeler	Yes	No	No
Synthetic Data Generator	Yes	No	No
Unstructured Data Integration	Yes	No	No
Voice Gateway	Yes	Not applicable	No
Watson Discovery	Yes	Yes*	No
Watson Machine Learning	Yes	No	No
Watson OpenScale	Yes	Yes	No
Watson Speech services	Yes	Yes*	No
Watson Studio	Yes	No	No
Watson Studio Runtimes	Yes	No	No
watsonx.ai™	Yes^¹	No	No
watsonx Assistant	Yes^¹	Yes*	No
Service	1. Install the service in separate projects	2. Install the service once and deploy multiple instances in the same project	3. Install the service once and provision multiple instances in tethered projects
watsonx™ BI	Yes	No. One instance only.	No
watsonx Code Assistant™	Yes^¹	No	No
watsonx Code Assistant for Red Hat Ansible® Lightspeed	Yes^¹	No	No
watsonx Code Assistant for Z	Yes^¹	No	No
watsonx Code Assistant for Z Agentic	Yes^¹	No	No
watsonx Code Assistant for Z Code Explanation	Yes^¹	No	No
watsonx Code Assistant for Z Code Generation	Yes	No. One instance only.	No
watsonx.data™	Yes	No	No
watsonx.data Premium	Yes	No	No
watsonx.data intelligence	Yes	No	No
watsonx.governance™	Yes^¹	No	No
watsonx Orchestrate	Yes^¹	Yes	No

¹ Red Hat OpenShift AI is installed once on the cluster. All instances of this service on the cluster must support the same version of Red Hat OpenShift AI.