Use-cases and customers¶
We foresee the following use-cases of the Claudie platform
1. Integration of GPU nodes into Kubernetes for AI workloads¶
A company runs their production workloads on a standard Kubernetes cluster hosted with a cloud provider that offers no GPU instances, or only at a prohibitive cost. They need to execute GPU-intensive tasks such as model training, inference serving, or data preprocessing pipelines without migrating their entire cluster. Claudie allows them to attach GPU-enabled nodes from a specialized or alternative provider (e.g. CloudRift, Vast.ai, or any GPU servers with public IPv4) directly into their existing cluster with native support for GPU autoscaling.
Typical client profile:
- startups building AI/ML products
- cost-conscious organizations looking to avoid GPU pricing from hyper-scale providers
2. On-premises integration and hybrid extension¶
A company already runs (or plans to run) Kubernetes workloads on its own on-premises hardware, co-located servers, or private datacenter, and wants to keep using that investment while gaining the flexibility of public cloud. Claudie lets them register their existing machines as static nodepools and combine them in a single cluster with nodepools from AWS, GCP, Azure, Hetzner, and other supported providers. The on-premises nodes are first-class members of the cluster, eligible for workloads, loadbalancing, and node-level autoscaling on the cloud side.
Typical client profile:
- organizations with existing on-premises or bare-metal investment
- companies in regulated industries that must keep certain workloads in their own datacenter
- teams that want a single Kubernetes control plane spanning on-premises and cloud
3. Cloud-bursting¶
A company uses advanced cloud features in one of the hyper-scale providers (e.g. serverless Lambda and API Gateway functionality in AWS). They run a machine-learning application that they need to train for a pattern on a dataset. The learning phase requires significant compute resources. Claudie allows to extend the cluster in AWS (needed in order to access the AWS functionality) to Hetzner for saving the infrastructure costs of the machine-learning case.
Typical client profiles:
- startups
- in need of significant computing power already in their early stages (e.g. AI/ML workloads)
4. Cost-saving¶
A company would like to utilize their on-premises or leased resources that they already invested into, but would like to:
- extend the capacity
- access managed features of a hyper-scale provider (AWS, GCP, ...)
- get the workload physically closer to a client (e. g. to South America)
Typical client profile:
- medium-size business
- possibly already familiar with containerized workload
5. Smart-layer-as-a-Service on top of simple cloud-providers¶
An existing customer of medium-size provider (e.g. Exoscale) would like to utilize features that are typical for hyper-scale providers. Their current provider does neither offer nor plan to offer such an advanced functionality.
Typical client profile:
- established business
- need to access advanced managed features to innovate faster
6. Service interconnect¶
A company would like to access on-premises-hosted services and cloud-managed services from within the same cluster. For on-premises services the on-premises cluster node would egress the traffic. The cloud-hosted cluster nodes would deal with the egress traffic to the cloud-managed services.
Typical client profile:
- medium-size/established business
- already contains on-premises workloads
- has the need to take the advantage of managed cloud infra (from cost, agility, or capacity reasons)