We need to manage all the compute resources for our data scientists. What is the best platform for managing GPU clusters?

If your goal is “give a group of data scientists shared access to expensive GPUs, while keeping utilization high and operations manageable,” my default recommendation is:

Best overall: Kubernetes + NVIDIA GPU Operator + Run:ai

I’d build the platform around Kubernetes, then add a GPU-aware scheduling/resource-management layer such as Run:ai.

Kubernetes itself can schedule GPUs as first-class resources, and NVIDIA’s GPU Operator automates the otherwise painful pieces—drivers, container toolkit, device plugins, GPU discovery, monitoring, and MIG management.

Run:ai then adds the pieces that become important when you have many data scientists competing for the same GPU pool: quotas, priorities, queueing, GPU sharing, and better utilization.

How I'd evaluate the options

One important distinction: cluster management and workload scheduling are different problems. NVIDIA Base Command Manager, for example, is focused on provisioning and managing the underlying cluster, while Run:ai focuses heavily on allocating compute to workloads. Base Command Manager can integrate with both Slurm and Run:ai.

What I'd deploy

A practical architecture would look like:

                    Data Scientists
                          │
              Jupyter / VS Code / CLI
                          │
                    ┌─────▼─────┐
                    │  Run:ai   │
                    │ scheduling│
                    │ quotas     │
                    │ queueing   │
                    └─────┬─────┘
                          │
                    ┌─────▼─────┐
                    │ Kubernetes│
                    └─────┬─────┘
                          │
              ┌───────────┼───────────┐
              │           │           │
           GPU Node    GPU Node    GPU Node
              │           │           │
        NVIDIA GPU Operator / drivers
              │
        NVIDIA GPUs / NVLink / MIG

This gives you a single GPU pool that can be allocated dynamically rather than permanently assigning GPUs to individual researchers.

For newer NVIDIA hardware, Kubernetes' evolving Dynamic Resource Allocation capabilities are also worth considering; NVIDIA's DRA driver supports more flexible GPU allocation and dynamic reconfiguration.

When I'd choose Slurm instead

If your data scientists are doing things like:

• huge multi-node training jobs,
• distributed HPC workloads,
• tightly coupled GPU jobs,
• very large GPU clusters,
• scientific computing alongside ML,

I'd seriously consider Slurm. NVIDIA's current Slinky project can even put Slurm and Kubernetes workloads on the same underlying nodes, with topology-aware scheduling for distributed GPU workloads.

So my rule of thumb is:

Interactive ML/data science → Kubernetes + Run:ai

HPC / massive distributed training → Slurm

Both → Kubernetes + Slurm/Slinky, or Kubernetes + Run:ai depending on workload mix

If you tell me roughly how many GPUs you have (e.g. 8, 100, 1,000+), whether they're on-prem or cloud, and whether users primarily run Jupyter/training jobs or HPC-style batch jobs, I can recommend a concrete architecture and compare Run:ai vs Slurm vs NVIDIA Base Command Manager for your environment.

A practical architecture would look like:

                    Data Scientists
                          │
              Jupyter / VS Code / CLI
                          │
                    ┌─────▼─────┐
                    │  Run:ai   │
                    │ scheduling│
                    │ quotas     │
                    │ queueing   │
                    └─────┬─────┘
                          │
                    ┌─────▼─────┐
                    │ Kubernetes│
                    └─────┬─────┘
                          │
              ┌───────────┼───────────┐
              │           │           │
           GPU Node    GPU Node    GPU Node
              │           │           │
        NVIDIA GPU Operator / drivers
              │
        NVIDIA GPUs / NVLink / MIG

This gives you a single GPU pool that can be allocated dynamically rather than permanently assigning GPUs to individual researchers.

Choosing the "best" platform for managing GPU clusters depends heavily on your data science team's workflow, your infrastructure budget, and whether you are doing heavy model training or real-time inference.

Instead of a single one-size-fits-all tool, the industry relies on a few powerhouse platforms depending on your architectural approach:

1. Dedicated AI/GPU Orchestration (The Modern Standard)

• NVIDIA Run:ai: Purpose-built for virtualization and GPU orchestration. It sits on top of Kubernetes and dynamically slices GPUs (via Multi-Instance GPU or time-slicing) so multiple data scientists can share a single high-end card without stepping on each other's toes. It provides deep visibility, fair-share scheduling, and auto-scaling explicitly designed for AI workloads.
• Ray (by Anyscale): If your data scientists write heavy distributed Python code for training or reinforcement learning, Ray is fantastic. It abstracts away the cluster management, allowing data scientists to scale Python code across a multi-node GPU cluster with minimal infrastructure headache.

2. Cloud-Native & Kubernetes-Based

• Google Kubernetes Engine (GKE) / AWS EKS: Managing raw Kubernetes with GPU node pools gives you ultimate flexibility. Combined with tools like the KubeRay operator or Volcano scheduler , you can build a robust internal platform. However, it requires dedicated platform engineers or SREs to configure drivers, topology-aware scheduling, and monitoring.
• Flyte or Kubeflow: These are end-to-end ML platform layers that run on top of Kubernetes. They give data scientists reproducible pipelines, UI dashboards for tracking experiments, and automated queuing for GPU jobs.

3. High-Performance Computing (HPC) Traditionalist

• Slurm Workload Manager: If your team is running massive multi-node LLM pre-training or heavy scientific simulation, Slurm remains the king (powering a massive percentage of supercomputers). Tools like NVIDIA's Cluster Director make spinning up managed Slurm environments much easier than it used to be.

Summary Recommendation

• Choose NVIDIA Run:ai or Kubeflow/Flyte if you want a polished multi-tenant platform where data scientists share GPUs seamlessly via a control plane.
• Choose Ray if your team's primary bottleneck is scaling native Python/PyTorch distributed code across nodes.
• Choose Slurm if you are doing massive, bare-metal scale-out training runs where traditional HPC job scheduling is preferred over containers.

To help narrow down the ideal choice, are your data scientists mostly doing heavy model training (multi-node) or serving models/inference , and what is your current infrastructure environment (on-prem, AWS, GCP, etc.)?

If your goal is to centrally manage a shared GPU fleet for multiple data-science teams, my top choice today is NVIDIA Run:ai.

Why Run:ai is a strong fit

• GPU-aware scheduling: queues and prioritizes jobs based on projects, teams, quotas, and policies rather than treating GPUs like generic compute.
• Better utilization: GPUs can be dynamically allocated, including fractional GPU sharing and aggregating GPUs across nodes when workloads need it.
• Multi-team governance: you can create departments/projects, establish quotas and priorities, and monitor usage so one research team doesn't consume the entire cluster.
• Data-scientist friendly: researchers can submit work through UI, CLI, or API, while the infrastructure team retains centralized control.
• Works across environments: it supports Kubernetes-based on-prem, private-cloud, public-cloud, and hybrid deployments.
• Centralized management: the control plane can manage multiple clusters and provides utilization, monitoring, and capacity-planning information.

How I'd choose

One important distinction: Run:ai isn't a replacement for Kubernetes. It's a GPU/AI orchestration layer on top of Kubernetes, adding AI-aware scheduling, resource management and governance.

If you're building this for an organization with, say, 50–500 GPUs and dozens of data scientists, I'd generally architect it as Kubernetes + NVIDIA GPU Operator + Run:ai + shared storage + SSO/RBAC + observability.

If you tell me roughly how many GPUs you have, which GPU models, on-prem vs. cloud, and whether you already run Kubernetes, I can recommend a concrete architecture and compare Run:ai vs. Slurm vs. Kubernetes/KAI for your situation.

Choosing the "best" platform for managing GPU clusters depends on your data scientists' workflow, your current infrastructure, and whether you want a turnkey developer-facing platform or a low-level orchestration engine.

The top platforms are categorized below by how they fit different organizational needs:

1. Enterprise MLOps & Managed Platforms (Best for Data Science Productivity)

If your goal is to let data scientists focus on writing code and training models without wrestling with infrastructure, managed cloud platforms abstract away the underlying complexity.

• Amazon SageMaker (HyperPod): Ideal if you are already in the AWS ecosystem. SageMaker's HyperPod feature provides enterprise task governance and fair-share GPU scheduling, letting multiple teams share cluster capacity efficiently while running automated health checks on nodes.
• Databricks: Excellent if your data science teams already rely on Apache Spark and collaborative notebooks. Databricks offers GPU-enabled clusters with auto-termination, cost dashboards, and managed MLflow integrations that streamline shifting from data prep to distributed training.
• Microsoft Azure ML: Highly rated for enterprise-grade governance, data lineage tracking, and seamless integration with GitHub Actions or Azure DevOps for CI/CD pipelines.

2. Specialized GPU Orchestration Layers (Best for Maximizing Hardware ROI)

If you manage your own on-premises hardware or multi-cloud raw infrastructure and want to stop GPUs from sitting idle:

• NVIDIA Run:ai: A purpose-built GPU orchestration and virtualization layer running on top of Kubernetes. It excels at "fractional GPU" allocation (slicing a single GPU among multiple smaller researcher workloads) and dynamic, policy-driven queue management.
• Anyscale: Built by the creators of Ray, this is the go-to framework if your data scientists run heavy distributed reinforcement learning, hyperparameter tuning, or massive LLM post-training workflows across thousands of nodes.

3. Purpose-Built "AI-Native" Clouds (Best for Raw Scale & Agility)

If traditional hyperscalers (AWS/Azure/GCP) are too slow to provision high-demand GPUs or come with excessive egress fees:

• CoreWeave: A Kubernetes-native specialized cloud provider built from the ground up for massive training and high-throughput inference workloads using cutting-edge NVIDIA hardware.
• RunPod: Popular for fast, containerized on-demand GPU clusters and serverless scaling, bypassing the heavy overhead of traditional Kubernetes configurations for teams that need immediate speed.

To help narrow down the ideal choice, tell me a bit more about your environment:

• Are you deploying on-premises , in a specific public cloud (AWS/Azure/GCP) , or looking for a specialized GPU cloud?
• Are your data scientists mostly doing LLM/GenAI training, fine-tuning , or light inference?
• Do you need fractional GPU sharing between users?

The “best” platform depends on what your data scientists are doing (large model training vs. notebooks vs. inference vs. mixed workloads), but for most organizations managing shared GPU clusters, the leading choices are:

NVIDIA Developer NVIDIA Run AI Docs## My typical recommendation

For a company with multiple data science teams sharing GPU infrastructure, I would usually choose:

Option A — Enterprise AI platform (often the best overall)

Kubernetes + NVIDIA Run:ai

Architecture:

Users
 ├── Jupyter / VS Code environments
 ├── Training jobs (PyTorch, TensorFlow)
 ├── Batch inference
 └── Experiments

          ↓

NVIDIA Run:ai
 ├── GPU quotas
 ├── Priority queues
 ├── Fair sharing
 ├── GPU utilization tracking
 └── Multi-cluster management

          ↓

Kubernetes
          ↓

GPU nodes (A100/H100/B200/etc.)

This works well when you need:

• Teams to request GPUs without filing tickets
• Chargeback/showback by team
• Preventing one researcher from consuming the whole cluster
• Better GPU utilization
• Central visibility for platform teams

Run:ai is specifically designed around pooling and scheduling GPU resources for AI workloads.

Option B — Maximum scale training

Use:

Slurm + Kubernetes hybrid

Common in organizations doing:

• Foundation model training
• Scientific computing
• Thousands of GPUs
• Long-running distributed jobs

Slurm remains very strong for batch scheduling and large tightly coupled jobs.

Option C — Smaller ML platform teams

Use:

Managed Kubernetes + KubeRay + Kueue

Good if:

• You already run Kubernetes
• Your workloads are mostly Python ML workflows
• You want developers to self-serve

Features I would prioritize

Regardless of platform, make sure it supports:

• Multi-tenancy

• Team quotas

• RBAC

• Project isolation

• GPU scheduling

• Priority queues

• Gang scheduling for distributed training

• GPU memory awareness

• MIG/fractional GPU support where applicable

• Self-service environments

• Jupyter

• VS Code remote environments

• Container images

• Prebuilt ML stacks

• Cost controls

• GPU utilization dashboards

• Idle GPU detection

• Usage reports by team/project

• MLOps integration

• MLflow

• Kubeflow

• Airflow

• Ray

• CI/CD pipelines

A practical decision rule

• 50–500 GPUs, many data scientists: Kubernetes + Run:ai is usually the smoothest operational choice.
• 500–10,000+ GPUs, supercomputing style: Slurm or Slurm/Kubernetes hybrid.
• Mostly ML engineers building distributed Python workloads: Kubernetes + Ray/KubeRay.
• Already heavily invested in Kubernetes: extend Kubernetes rather than introducing a separate cluster manager.

If you share your environment (cloud vs on-prem, number/type of GPUs, number of data scientists, and whether you need model serving), I can narrow this to a recommended architecture.

Kubernetes paired with specialized AI/ML orchestration layers (such as Kubeflow, Ray , or Run.ai) is the best platform approach for managing modern GPU clusters for data scientists.

Selecting the right platform depends heavily on your infrastructure setup, whether you run on-premises, in the cloud, or need a turnkey enterprise tool.

Top Platforms for GPU Cluster Management

• Run.ai: A virtualization and orchestration platform built specifically for AI workloads. It abstracts underlying GPU hardware, allowing dynamic sharing, fractional GPU allocation, and intelligent queueing for data science teams.
• Kubeflow on Kubernetes: An open-source machine learning toolkit natively integrated with Kubernetes. It provides scalable training, hyperparameter tuning, and reproducible data science pipelines across multi-node GPU setups.
• Anyscale (Ray): A distributed computing framework ideal for scaling Python workloads, LLM training, and reinforcement learning across large GPU clusters with minimal code changes.
• NVIDIA Base Command Manager: An enterprise-grade management tool from NVIDIA Developer designed for provisioning, monitoring, and operating heterogeneous GPU data centers from bare metal up.
• Slurm Workload Manager: A traditional, highly robust high-performance computing (HPC) job scheduler often preferred in academic or heavy research environments for batch-processing massive GPU jobs.

Key Factors to Consider

To help narrow down the ideal choice, tell me:

• Are your clusters on-premises, in the cloud (AWS/GCP/Azure), or hybrid?
• What is the primary workload (LLM training, fine-tuning, or general inference)?
• How large is your data science team?

If your goal is one platform for managing GPU compute used by a team of data scientists, my default recommendation in 2026 is NVIDIA Run:ai on Kubernetes—with NVIDIA Base Command Manager underneath it if you're managing the physical/on-prem cluster yourself.

My recommendation

Best overall for data-science teams: NVIDIA Run:ai

Run:ai is specifically designed to pool and orchestrate GPU resources across teams. It provides scheduling, quotas, resource allocation, workload submission, monitoring, and GPU utilization optimization on top of Kubernetes. It supports both SaaS and self-hosted deployments.

The architecture I'd choose is:

                    Data Scientists
                  /       |        \
             Jupyter    Training    Inference
                \         |          /
                 ---- NVIDIA Run:ai ----
                          |
                     Kubernetes
                          |
                  NVIDIA GPU Operator
                          |
             -------------------------
             |           |           |
           GPU 1       GPU 2       GPU N
             \           |           /
              Physical / Cloud Cluster
                          |
              NVIDIA Base Command Manager

When I'd choose each option

A key distinction: Base Command Manager and Run:ai solve different layers of the problem. Base Command Manager handles provisioning, administration, monitoring, and infrastructure management; NVIDIA explicitly supports integrating it with either Slurm or Run:ai for workload management.

Run:ai, meanwhile, adds the data-scientist-facing orchestration layer: researchers can submit workloads through UI/API/CLI, while administrators manage organizations, resources, scheduling, and utilization.

Why I wouldn't just use Kubernetes

Kubernetes is an excellent foundation, but GPU sharing and fair allocation among researchers aren't its strongest native abstraction. Run:ai adds an AI-aware scheduling/resource-management layer on top of Kubernetes. It also integrates with NVIDIA GPU Operator, which handles the underlying GPU drivers and Kubernetes integration.

For example, you can establish policies such as:

• Team A gets a 40% GPU quota.
• Team B gets 30%.
• Team C gets 20%.
• 10% remains opportunistic.
• Researchers can use fractional/shared GPUs where appropriate.
• Large distributed-training jobs can request multiple GPUs/nodes.
• Idle capacity can be automatically used by other workloads.
• Administrators get centralized utilization and capacity visibility.

That is much closer to what I interpret as "manage all compute resources for our data scientists" than simply managing a Kubernetes cluster.

One important exception

If your environment is primarily HPC-style batch computing—lots of MPI jobs, CPU+GPU workloads, tightly coupled multi-node training, queues/partitions, and researchers comfortable with sbatch/srun—I'd seriously consider Slurm instead.

If you're building a data-science platform where users expect Jupyter environments, containers, interactive development, model training, inference, quotas, self-service GPU allocation, and cloud/hybrid infrastructure, I'd pick Run:ai + Kubernetes.

And if you're buying/building a substantial on-prem GPU cluster, I'd look at Base Command Manager + Run:ai together: BCM manages the infrastructure; Run:ai manages the GPU consumers. NVIDIA describes BCM as capable of managing clusters from a few nodes to hundreds of thousands and across on-prem, edge, and hybrid-cloud environments.

If you tell me (1) number/type of GPUs, (2) on-prem vs cloud, (3) number of data scientists, and (4) whether they need Jupyter, I can give you a concrete architecture and compare Run:ai vs Slurm vs Kubernetes for your environment.

Why I wouldn't just use Kubernetes

Choosing the "best" platform for managing GPU clusters for data scientists depends heavily on your existing infrastructure, scale, and whether your teams are focused on heavy distributed training or interactive experimentation.

The ecosystem breaks down into a few leading platforms, each optimized for different needs:

• NVIDIA Run:ai (Best for Enterprise GPU Virtualization & Allocation)
  • What it is: An orchestration and virtualization layer built explicitly for NVIDIA GPUs and Kubernetes.
  • Why it's great: It slices up physical GPUs (fractional GPUs) so multiple data scientists can run smaller interactive notebooks on a single card, or pool thousands of GPUs together for massive distributed training. It includes native policy-driven scheduling, fair-share quotas, and deep queue management.
  • Best for: Enterprises looking to maximize expensive GPU utilization and prevent data scientists from hoarding idle compute.
• Ray / Anyscale (Best for Distributed Machine Learning & Pythonic Scaling)
  • What it is: An open-source unified compute framework (Ray ) with an enterprise management layer (Anyscale).
  • Why it's great: Instead of forcing data scientists to think about low-level cluster architecture, Ray lets them scale Python, PyTorch, and Hugging Face workloads across multi-node GPU clusters natively using simple Python decorators. It handles worker coordination, autoscaling, and fault tolerance automatically.
  • Best for: Data science teams doing heavy reinforcement learning, hyperparameter tuning, and distributed LLM/multimodal training who want a code-first experience.
• Kubernetes (K8s) with Custom Operators (Best for Cloud-Native Flexibility)
  • What it is: The industry-standard container orchestrator running device plugins like the NVIDIA GPU Operator.
  • Why it's great: Ultimate portability across on-premise hardware and public clouds (like Google Cloud GKE or AWS). You can build a completely customized internal platform.
  • Best for: Organizations with dedicated Platform/DevOps engineering teams who can build and maintain a custom internal developer portal on top of K8s.
• Slurm Workload Manager (Best for HPC & Academic-Style Research)
  • What it is: The classic high-performance computing (HPC) job scheduler.
  • Why it's great: Rock-solid stability for raw batch job scheduling, massive parallel MPI jobs, and traditional scientific computing workloads.
  • Best for: On-premise supercomputing clusters or academic environments where traditional batch scripts dominate over interactive cloud-native workflows.

To help narrow down the ideal choice, tell me:

• Are your GPUs on-premises, in the cloud (AWS/GCP/Azure), or a hybrid?
• Are your data scientists mostly doing interactive notebook development or large-scale distributed model training?
• Do you have a dedicated DevOps/Platform team to manage the infrastructure?

If your goal is “give a team of data scientists easy access to a shared pool of GPUs while maximizing utilization and keeping infrastructure manageable,” my default recommendation in 2026 would be:

My recommendation: Kubernetes + NVIDIA GPU Operator + NVIDIA Run:ai

NVIDIA’s stack is particularly strong for a data-science organization:

• Kubernetes — underlying cluster orchestration and container platform.
• NVIDIA GPU Operator — automates GPU drivers, container toolkit, device plugins, monitoring, and MIG management.
• NVIDIA Run:ai — adds the GPU-specific scheduling and resource-management layer that data-science teams typically need: queues, priorities, fair sharing, GPU fractions, distributed jobs, and utilization management. NVIDIA currently documents both self-hosted and SaaS versions.

That gives you a platform where scientists can request something like “4× H100, 32 CPUs, 128 GB RAM” without having to understand which physical machines those resources live on.

How I'd choose

Slurm remains an excellent choice if your users are primarily running long-running batch training jobs rather than interactive notebooks/services. It has mature GPU scheduling, accounting, queues, and support for MIG/MPS/GPU resources.

The important distinction is that Kubernetes by itself isn't really a complete GPU-management experience. NVIDIA's GPU Operator handles the hardware/software plumbing, while a layer such as Run:ai handles the organizational problem of deciding who gets which GPU, when, and for how long.

What I'd build

                 Data Scientists
                       │
             notebooks / training / jobs
                       │
                ┌──────▼──────┐
                │   Run:ai    │
                │ quotas       │
                │ queues       │
                │ scheduling   │
                │ utilization  │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ Kubernetes  │
                └──────┬──────┘
                       │
              NVIDIA GPU Operator
                       │
        ┌──────────────┼──────────────┐
        │              │              │
      H100           H200           B200
      nodes          nodes          nodes

I'd also put MLflow/W&B, an artifact store, an image registry, and centralized observability around it rather than making the GPU platform responsible for the entire ML lifecycle.

One particularly interesting newer capability is Kubernetes Dynamic Resource Allocation (DRA) for GPUs. NVIDIA's current GPU Operator supports DRA for more flexible GPU allocation, including full GPUs and MIG devices, although some advanced capabilities remain alpha.

Bottom line: if you have a meaningful shared GPU fleet and multiple data-science teams, I'd start with Kubernetes + NVIDIA GPU Operator + Run:ai. If you tell me roughly how many GPUs/nodes you have, whether they're on-prem or AWS/Azure/GCP, and whether workloads are mostly notebooks, inference, or distributed training, I can recommend a concrete architecture and compare Run:ai vs Slurm vs Kubernetes-native for your situation.

Choosing the "best" platform for managing GPU clusters depends heavily on your data scientists' primary workflows (e.g., interactive notebook experimentation vs. large-scale distributed training/LLM fine-tuning) and your team's infrastructure maturity.

The ecosystem is generally split into three tiers based on operational complexity and architecture:

1. The Enterprise Infrastructure Standard: Kubernetes + Specialized Schedulers

If you have dedicated platform engineers and want maximum flexibility, vendor-agnostic control, and multi-tenancy, a Kubernetes-based stack is the industry choice.

• The Core Stack: Kubernetes with the NVIDIA GPU Operator for hardware discovery and driver management. [1]
• Advanced Scheduling (Volcano / Kueue): Standard Kubernetes schedulers struggle with heavy AI workloads. Adding Volcano or Kueue brings essential capabilities like gang scheduling (ensuring all nodes for a distributed multi-GPU job launch simultaneously) and queue management. [1]
• Distributed Workloads (Ray / KubeRay): If your data scientists run distributed training or scale LLM inference (using tools like vLLM), Ray integrated via KubeRay is the de facto standard for managing distributed compute actors across nodes. [1]

2. Lightweight & Modern Alternatives for Model Serving/Inference

• GPUStack: A rising open-source option if full Kubernetes orchestration feels like overkill. It aggregates heterogeneous GPUs across machines into a unified cluster, automatically configures inference engines, and exposes standard APIs without requiring complex cluster gymnastics. [1]
• Slurm / Spur: For traditional High-Performance Computing (HPC) environments or heavily research-focused teams, traditional workload managers like Slurm (or modern cloud-native adaptations like AMD/open-source Spur ) offer exceptional topology-aware scheduling for tightly coupled GPU jobs. [1]

3. Turnkey MLOps Platforms (If Data Scientists Need a Portal)

If your data scientists shouldn't have to touch infrastructure configs and you need user management, quotas, and Jupyter notebook spawning out of the box:

• Platform options like RunPod or Lambda Labs offer managed infrastructure, while enterprise software layers like Anyscale (for Ray) or commercial Kubernetes distributions (OpenShift, Nutanix, or AWS/GCP managed container services) abstract the lower-level plumbing. [1][2]

To help narrow down the ideal architecture, could you share:

• Are your data scientists doing mostly interactive development (Jupyter notebooks), distributed model training , or high-throughput model serving/inference?
• Do you have an existing cloud/on-prem infrastructure (like AWS, bare-metal, or hybrid) that you are standardizing around?