IBM Cloud Docs
Service rollout policy

Service rollout policy

IBM Cloud® has a resilient global network of locations to host your highly available cloud workload. To ensure that the cloud infrastructure and services are consistent and stable across our deployment locations, we created best practices for our service catalog management. These best practices help us to accomplish rollouts in the most efficient manner and minimize business impact, costs, and risks. The following information describes our guidelines on when to expect or how to request that a service is available in your region.

This policy covers all IBM Cloud public MZRs, public single-campus MZRs and public data centers.

IBM® classifies our services deployed to our public locations as core or market-driven.

Core services

All IBM® multi-zone regions contain the following core services, which are the most basic and vital services that are needed for the majority of customer workloads.

  • IBM Cloud platform (console, CLI, Identity and Access Management, and global catalog)
  • IBM Cloud® Virtual Private Cloud
    • IBM® Cloud Block Storage for Virtual Private Cloud
    • IBM Cloud® Virtual Servers for Virtual Private Cloud
    • Virtual Private Network (VPN) for VPC
    • IBM Cloud® Transit Gateway
    • Network Load Balancer for VPC
    • Application Load Balancer for VPC
    • Virtual Private Endpoint (VPE) for VPC
    • IBM Cloud® DNS Services
  • IBM Cloud Object Storage
  • IBM Cloud Databases for PostgreSQL
  • IBM Key Protect for IBM Cloud
  • IBM Cloud® Continuous Delivery
  • IBM Cloud Container Registry
  • IBM Cloud Kubernetes Service
  • Red Hat OpenShift on IBM Cloud

The IBM Cloud platform, including the console, CLI, Identity and Access Management, and global catalog, is a globally accessible instance that is independent of any region or zone. Global resources like the platform are accessible from a global endpoint.

Deployment Tiers

IBM identifies the following deployment tiers that can contain core services, market driven services or both.

Table 1. Deployment tiers and service types
Deployment tier Core service Market-driven services
MZR Checkmark icon Checkmark icon
Single campus MZR Checkmark icon Checkmark icon
Data center Checkmark icon

Core service deployments

Adding new core service to existing MZRs
After a new core service is deployed in the first MZR and added to this IBM Cloud service rollout policy, the new core service will be deployed to all other MZRs within a period of 90 days.
Updating existing core services in existing MZRs
After a generally available update to an existing core service is deployed in the first MZR and documented in a release note, the same update will be deployed to all other MZRs within a period of 30 days.

Not all hardware dependent profiles and features are available in all MZRs. If the service you want depends on such a profile or feature, contact IBM Cloud Sales for details on availability.

Some services could deploy sooner.

Market-driven deployments

Market-driven services are deployed based on sufficient customer demand. To request that one of these services is available in your region, contact IBM Cloud Sales.

Deployments into any location other than an MZR are always market-driven.

Market-driven classification covers any case other than those specified under the MZRs' description.

Dependency and service availability standards

For each service, you can review our dependency and availability standards.

  • IBM Cloud services are available in several regions worldwide.
  • IBM services can be deployed by using various models, and the SLA standards that apply to each model are outlined in the Service Level Agreements
  • Follow our best practices to ensure your environment that integrates the use of the IBM Cloud services is as resilient as possible. Check out the resiliency documentation that is published in the architecture center.
  • To build a solution that meets your needs, it is important for you to see the Shared responsibility matrix for more information on the scope of the services.
  • For quick reference, we include links to the high availability documents for the services within our SLO description.

Dependency levels

Low-level implementation and details of services change based on your setup and configuration requirements. As such, we've provided a high-level explanation for the dependencies.

These levels might be considered layers or tiers in an architectural block diagram. Each layer might depend only on the layers below it, although there are some dependencies that might be fulfilled in the same layer in the case of some complex services.

Core services form the foundation for our cloud infrastructure. These services are required for a new MZR location to go live and are required to be updated across the entire footprint when there is a fundamental change.

Market-driven services are based on market demand and depend on the core services and some other services within this market-driven category. The other services are services that are needed to support regulation that applies in different regions or industries.

Market-driven classification covers all services other than those specified under the core service description.

Service-to-service dependencies

The IBM Cloud backend services support all of the other services within our deployment units.

IBM Cloud services have a set of dependencies that are self-contained within the MZR deployment units. The rest of the service dependencies use global services that are served from cross regional locations. Any solution that is not hosted on an MZR might require an associated MZR that hosts the control plane services.

For the key dimensions of compute, storage, networking, and authentication or authorization, we indicate the following dependencies.

Control planes

Common dependencies for control planes are:

  • The identity or platform data plane for authentication and authorization
  • The audit tracking service
  • Internal services that provide, for example, workflow, metadata storage, monitoring and logging
  • Load balancers, VPN, and other network infrastructure services

Some control planes obviously have service-specific dependencies. For example, the compute control plane, when starting a bare metal or VM instance, depends on:

  • Object Storage to retrieve the required system images
  • Block Volumes control plane for provisioning and attaching the volumes
  • Networking control plane to provision and attach NICs, subnets, and so on
Data planes

Core service data planes follow the general principle that each data plane is designed to have minimal dependencies in order to achieve high availability, fast time to diagnosis, and fast time to recovery. Therefore, the systems continue to function (with some limitations, for example cannot provision, reboot, or decom) even when there is a control plane outage.

Network

The networking data and control planes exist in every deployment unit.

Some services depend on others in the core, for example Compute services like bare metal and VM instances depend the Block Volumes data plane and the Networking data plane, and therefore will be impacted by the data planes for these services going down. But as stated before the control planes might suffer an outage and the Compute instances continue to function, if they do not require the associated service control plane (that is, increasing volume storage size, and so on)

Internal services

All client facing internal or external services depend on the identity and platform data plane for authentication and authorization. Control planes for monitoring, logging, and IBM Cloud CLI and data plane services for security services depend on the identity platform data plane. (Specific configurations might vary.)

Storage

The Object Storage data plane does not depend on Block Volumes or File Storage. Services that support backup and restore depend on Object Storage to operate. Therefore, those services require that the Block Volumes data and control planes exist in every deployment unit.