# Cloud-Native Computing on Quake AI

Source: https://docs.quake.ai/docs/kubernetes/concepts/cloud-native-computing
Markdown: https://docs.quake.ai/docs/kubernetes/concepts/cloud-native-computing.md

---

# Cloud-Native Computing on Quake AI

Traditional application deployment is straightforward: install software on a server, configure it, run it. That model works until you need to scale to multiple instances, deploy updates without downtime, recover from failures automatically, or reproduce an environment exactly. Cloud-native computing is the set of practices that solve those problems by treating infrastructure as programmable, applications as portable, and deployment as automated.

Cloud-native computing describes applications built as containers, managed by orchestrators, scaled horizontally, and updated through automated pipelines. Many applications run on cloud VMs without that architecture; cloud-native is the design choice, not the hosting location.

## Core concepts

### Containers

A container packages an application with its dependencies (libraries, runtime, configuration) into a single portable unit. Unlike a full VM, containers share the host kernel, so they start in seconds and use a fraction of the resources. The image you build on your laptop runs identically on a test server, a CI pipeline, and a production cluster.

On Quake AI, you run containers in two ways:

- **Docker on instances**: install Docker or containerd on a Compute instance and run containers directly. You manage the host, networking, and orchestration yourself. Good for simple workloads, development environments, and single-host services.
- **Kubernetes clusters**: use the [Kubernetes service](/docs/kubernetes/concepts/kubernetes) to provision a full cluster with automated networking, load balancing, and persistent storage. Good for production workloads that need scaling, health management, and rolling updates.

### Orchestration

Running a few containers on one host is simple. Running dozens across multiple hosts (with health checks, rolling updates, network routing, and storage) requires an orchestrator. Kubernetes is the industry standard: it schedules containers across worker nodes, restarts failed ones, scales replicas based on load, and manages service discovery.

The Quake AI Kubernetes service automates cluster provisioning: you define a template, and the platform creates master nodes, worker nodes, networking, and stable control-plane endpoints. You manage the workloads; the platform manages the infrastructure setup.

### Infrastructure as code

Cloud-native teams do not click through consoles to set up infrastructure. They write declarative configuration files that describe the desired state (instances, networks, volumes, security groups) and use tools to apply them. When the configuration changes, the tool calculates the difference and applies only what is needed.

On Quake AI, you use [OpenTofu](/docs/automation/concepts/terraform) (or Terraform) with the OpenStack provider, or [Heat stacks](/docs/automation/concepts/cloud-automation) for native OpenStack orchestration. Both support version control, peer review, and automated deployment; the same workflow you use for application code.

### CI/CD pipelines

Continuous integration builds and tests code on each commit. Continuous deployment pushes validated builds to production automatically. Together, they replace manual deployment processes with automated pipelines that are faster, more reliable, and auditable.

A typical cloud-native pipeline on Quake AI:

1. Developer pushes code → CI system builds a container image
2. CI runs tests against the image
3. Validated image is pushed to a container registry
4. CD system updates the Kubernetes deployment, which triggers a rolling update across the cluster

<Figure size="md" caption="Cloud-native CI/CD pipeline: a git push triggers build, test, registry push, and a rolling update on the Kubernetes cluster.">

```d2
direction: right

dev: Developer {shape: person}

ci: CI System {
  build: Build image
  test: Run tests
}

reg: Container Registry {shape: cylinder}

cd: CD System

cluster: Kubernetes Cluster {
  rolling: "Rolling update\n(pod by pod)"
}

dev -> ci.build: git push
ci.build -> ci.test
ci.test -> reg: push validated image
reg -> cd: trigger
cd -> cluster.rolling: apply manifest
```

</Figure>

The rolling update replaces pods one at a time, so the service stays available throughout the deployment. If the new version fails health checks, the update halts automatically.

## Containers vs. VMs: when to use each

| | Containers on Kubernetes | Direct VM deployment |
|---|---|---|
| **Startup time** | Seconds | Minutes |
| **Resource overhead** | Minimal (shared kernel) | Full OS per instance |
| **Scaling** | Horizontal autoscaling, pod-level | Vertical (resize) or manual horizontal |
| **Update strategy** | Rolling updates, canary, blue/green | Redeployment or in-place update |
| **State management** | Stateless preferred; persistent volumes for state | Filesystem, local disk |
| **Best for** | Web services, APIs, microservices, batch jobs | Legacy applications, databases, GPU workloads, Windows |
| **Operational complexity** | Kubernetes learning curve | Familiar Linux administration |

Neither approach is universally better. Many production architectures use both: Kubernetes for stateless application tiers and dedicated VMs for stateful services like databases or specialized workloads that do not containerize well.

## Cloud-native on Quake AI

The platform provides the primitives for each layer of a cloud-native architecture:

| Cloud-native layer | Quake AI primitive |
|---|---|
| **Container orchestration** | [Kubernetes service](/docs/kubernetes/concepts/kubernetes) (Magnum) |
| **Container runtime** | Docker / containerd on Compute instances |
| **Persistent storage** | [Volumes](/docs/block/concepts/volumes) via Cinder CSI driver |
| **Object storage** | [Object storage](/docs/object/concepts/object-storage) for artifacts, backups, static assets |
| **Networking** | [Networks](/docs/network/concepts/networks), Kubernetes `LoadBalancer` Services, and in-cluster ingress controllers |
| **Infrastructure as code** | [OpenTofu / Terraform](/docs/automation/concepts/terraform) + [Heat](/docs/automation/concepts/cloud-automation) |
| **Stable endpoints** | [Floating IPs](/docs/network/concepts/floating-ips) for public-facing services |

The platform does not provide a managed container registry, managed CI/CD, or managed databases. You self-host these on instances or use external services. This is typical for infrastructure-focused cloud platforms and gives you flexibility in tooling choices.

## Getting started

If you are new to cloud-native patterns on Quake AI:

1. **Start with containers on a single instance.** Deploy a Docker host, run your application in a container, and understand the container lifecycle before adding orchestration complexity.
2. **Graduate to Kubernetes when you need multi-host orchestration.** When your workload requires scaling, rolling updates, or service discovery, create a Kubernetes cluster through the platform.
3. **Codify your infrastructure.** Write your cluster configuration, network setup, and security groups as OpenTofu or Heat templates. Commit them to version control alongside your application code.
4. **Automate deployment.** Set up a CI/CD pipeline that builds container images, runs tests, and deploys to your cluster on each commit.

## Further reading

**On this platform:**

- [Kubernetes on Quake AI](/docs/kubernetes/concepts/kubernetes): how the Kubernetes service provisions and operates clusters
- [Cloud automation](/docs/automation/concepts/cloud-automation): infrastructure as code with Heat and OpenTofu
- [Instances](/docs/compute/concepts/instances): when direct VM deployment is the right choice

**External resources:**

- [CNCF Cloud Native Trail Map](https://landscape.cncf.io/guide): a guided path through cloud-native adoption stages
- [The Twelve-Factor App](https://12factor.net/): design principles for building cloud-native applications
- [Kubernetes documentation](https://kubernetes.io/docs/): official concepts, tutorials, and API reference
- [CNCF Cloud Native Glossary](https://glossary.cncf.io/): vendor-neutral definitions for cloud-native terminology