docs: propose runtime classes for compute workloads

[scotwells]

What this is

Compute lets a customer say what shape their workload is — a sandbox of containers, or a VM booting their own image. It doesn't let them say how it's executed: what isolation surrounds it, how much of Linux it can use, how fast it starts, what it costs. There's one answer per shape today, and customers find its limits by hitting them.

This proposes the runtime class: a small platform-owned catalog of named execution tiers, each publishing a contract of isolation, compatibility, startup, and cost. Two to start — today's unikernel fast path (millisecond starts, narrow image compatibility) and a general-purpose tier (arbitrary Linux images, stronger isolation, slower and pricier per instance).

The outcome: a customer whose image won't boot on the fast path gets "here's the class that runs it, at this price" instead of "that doesn't work here." Compatibility becomes a priced choice, isolation becomes a stated promise, and placement gets a vocabulary for matching workloads to cells that can serve them.

The consumer API experience

One string, alongside instance type — a sibling of "how big," not a new subsystem:

spec:
  template:
    spec:
      runtime:
        class: general-purpose      # <- the whole customer-facing surface
        resources:
          instanceType: datumcloud/d1-standard-2
        sandbox:
          containers: [...]

(Shape of the experience, not a committed field name — the doc stays out of API specifics on purpose.)

• Omitting it keeps working. No class means the default, pinned to today's runtime. No existing workload changes behavior, cost, or startup profile.
• Class is independent of shape. sandbox/virtualMachine is what you run; class is how it's executed.
• Failure is legible. No cell serves this class here, or this image isn't compatible with this class — each surfaces as a workload condition naming the class, never a pending workload with no explanation.
• Availability is discoverable before deploy, per location. This is where CLI and portal add the most value.
• The class follows the workload — onto instance status, metering, the bill, and quota, so the general-purpose tier can be entitled independently of the fast path.

Where the platform ends and a provider begins

A second class means a second thing realizing instances, so the doc now states the line. The platform owns the contract — the class catalog, the instance-type sizing every class must honor, the customer-facing status and failure vocabulary, and the translation from an instance spec into a runnable description of it. A provider owns realization — its runtime's targeting and plumbing, lifecycle, and capacity — and stays separately deployed, so a bad rollout in one class can't take another down.

Deliberately not narrowed: an instance need not be realized the same way in every class. One class may run containers on a host, another may provision a VM from a cloud provider. The abstraction is the instance, not any particular realization.

Capability gaps get rejected, not silently dropped. An unsupported feature (disk-backed volumes, say) is currently skipped while the instance otherwise starts — fine when there's one runtime with documented limits, a contract violation once a class publishes promises. Unsupported combinations should fail at apply time, naming the class and the feature.

Not decided here

Which technology backs each tier — explicitly a non-goal, since the catalog exists so implementations can change while the contract holds. Also out: runtime tuning knobs, per-container selection, and snapshot / fast resume / scale-to-zero. That last one is the sharpest tension and is called out rather than papered over — those capabilities don't come free in a general-purpose isolation tier.

Open questions

• Is two classes the right ceiling for the first milestone? Every class is a permanent operational commitment. If a cheaper third tier is already on the roadmap, that changes.
• Is runtime class a quota dimension on day one, or does the general-purpose tier ride on existing compute quota at first?
• Should the platform ever recommend a class? Silent inference is rejected — it makes cost and isolation unpredictable — but a deploy-time recommendation is attractive, and it shapes the CLI/portal work.
• Tracking-issue reference in the doc is a placeholder pending a datum-cloud/enhancements issue.

Related

• Placement is a hard dependency; class becomes a scheduling constraint alongside location — docs/enhancements/federated-deployment-scheduling.md (Define integration strategy with federated control plane for workload deployment scheduling #85).
• Guides and CI-tested working examples for building unikernel images #175 (unikernel build guides) is the current answer to fast-path compatibility; this is the other half — a route for images that will never fit it.

Draft: opening for direction on the framing and open questions before filling in the beta/GA readiness sections.