Managed Container Services

The previous lesson handed off instance count to a group and left six setting items in exchange. The handoff was real but partial: the machine was still there — its family was chosen, its image was baked, its startup was measured. The handoff can go one step further and remove the machine entirely from view.

This lesson compares the same workload across three levels: a self-run cluster (running orchestration on your own instances), a managed cluster service (control plane handed off, nodes still yours), and task-based execution (there is no such item as a node). M22/K02 measured the container and image layer, M22/K03 the orchestration mechanics; that mechanics is not repeated here. The single measure here is the decision handed off: how many items stay with you at each level, how many are handed off, and which of the handed-off items can never be taken back.

CC31. Fifteen decision items belong to the container layer of the regional measurement network — the fictional software that collects readings from water meters; items and annual maintenance hours are fictional. CC32. The three levels are as above and run the same workload. CC33. “none” shows that an item does not exist at all at that level; “shared” shows that part of the decision stays with you. CC34. The move rule is fictional: if the definition is yours it moves (2 h), if it is in the provider’s format it is rewritten (10 h), if it has been fully handed off it is reinstalled (24 h), if it never existed at that level the decision is made from scratch (16 h). CC35. The items that cannot be undone number three per level and are fictional. CC36. Maintenance hours are annual and fictional; an item generates maintenance load only while it is yours or shared.

The Same Workload, Three Execution Levels

Handoff is not an all-or-nothing decision; it is given item by item. The inventory below places fifteen items across three levels one at a time.

// measurement-network/handoff-inventory.mjs — the same workload's decision distribution across three execution levels (model)

export const LEVELS = ["self-run cluster", "managed cluster", "task-based execution"];

// [item, [level1, level2, level3], annual maintenance hours (while the item is yours or shared)]
export const ITEMS = [
  ["node size and family", ["yours", "yours", "none"], 12],
  ["node count", ["yours", "yours", "none"], 8],
  ["cluster version", ["yours", "shared", "none"], 20],
  ["node operating system patch", ["yours", "shared", "provider"], 40],
  ["control plane operation", ["yours", "provider", "provider"], 60],
  ["control plane redundancy", ["yours", "provider", "provider"], 24],
  ["network plugin choice", ["yours", "yours", "provider"], 16],
  ["storage plugin choice", ["yours", "yours", "provider"], 12],
  ["task scheduler setting", ["yours", "yours", "shared"], 18],
  ["task scaling", ["yours", "yours", "yours"], 14],
  ["resource request and limit", ["yours", "yours", "yours"], 10],
  ["image repository and pull identity", ["yours", "yours", "yours"], 8],
  ["log and metric collection", ["yours", "yours", "shared"], 22],
  ["internal network address plan", ["yours", "yours", "provider"], 14],
  ["shared process on the node", ["yours", "yours", "none"], 10],
];

export const count = (d, kind) => ITEMS.filter((k) => k[1][d] === kind).length;
export const maintenance = (d) =>
  ITEMS.filter((k) => k[1][d] !== "provider" && k[1][d] !== "none").reduce((t, k) => t + k[2], 0);

if (import.meta.url === `file://${process.argv[1]}`) {
  console.log("decision item".padEnd(36) + LEVELS.map((d) => d.padEnd(22)).join("") + "annual maintenance");
  for (const [name, where, hours] of ITEMS)
    console.log(name.padEnd(36) + where.map((y) => y.padEnd(22)).join("") + `${hours} h`);
  console.log("");
  console.log("level".padEnd(22) + "kept".padEnd(8) + "shared".padEnd(11) +
    "provider".padEnd(14) + "none".padEnd(12) + "annual maintenance");
  LEVELS.forEach((d, i) =>
    console.log(d.padEnd(22) + String(count(i, "yours")).padEnd(8) + String(count(i, "shared")).padEnd(11) +
      String(count(i, "provider")).padEnd(14) + String(count(i, "none")).padEnd(12) + `${maintenance(i)} h`));
}

decision item                       self-run cluster      managed cluster       task-based execution  annual maintenance
node size and family                yours                 yours                 none                  12 h
node count                          yours                 yours                 none                  8 h
cluster version                     yours                 shared                none                  20 h
node operating system patch         yours                 shared                provider              40 h
control plane operation             yours                 provider              provider              60 h
control plane redundancy            yours                 provider              provider              24 h
network plugin choice               yours                 yours                 provider              16 h
storage plugin choice               yours                 yours                 provider              12 h
task scheduler setting              yours                 yours                 shared                18 h
task scaling                        yours                 yours                 yours                 14 h
resource request and limit          yours                 yours                 yours                 10 h
image repository and pull identity  yours                 yours                 yours                 8 h
log and metric collection           yours                 yours                 shared                22 h
internal network address plan       yours                 yours                 provider              14 h
shared process on the node          yours                 yours                 none                  10 h

level                 kept    shared     provider      none        annual maintenance
self-run cluster      15      0          0             0           288 h
managed cluster       11      2          2             0           204 h
task-based execution  3       2          6             4           72 h

The first handoff is smaller than expected. Moving to a managed cluster, only two of fifteen items are fully handed off: control plane operation and its redundancy. Two more items drop to shared — cluster version and node patching are now given jointly with the provider. The remaining eleven items stay in place; node size, network plugin, address plan, and shared processes running on the node are still chosen. Annual maintenance drops from 288 hours to 204 hours — 29 percent.

The “shared” column is the part of this table most likely to be misread. When the cluster version is shared, the provider does the upgrade, and the provider is also the one who says when it happens: once a version’s support ends, upgrading stops being optional. Node patching works the same way — the patch arrives, but restarting the node cuts the workload, and you are the one who absorbs that cut. A shared item hands off half the maintenance load, and it hands off the entire timing decision.

The second handoff is genuinely large, but its shape is different. Under task-based execution, six items move to the provider and four items disappear entirely: node size, node count, cluster version, and shared processes running on the node stop being questions at all. This is the strongest form of handoff — the decision is not given to someone else, the decision stops existing. The three kept items are task scaling, resource requests, and image identity; annual maintenance drops to 72 hours.

But the last line must be read carefully. Most of the items counted in this course’s first five lessons — instance family, sizing, image freshness, startup time, health threshold — do not disappear at the task-based level; they become invisible. The task still runs on a machine, the image is still pulled, startup still takes time. What gets handed off is decisions, not physics.

What Opens and Closes at Each Handoff

Handoff changes two numbers at the same time: kept items decrease, but part of the decrease turns into items that cannot be changed once set up. The second number does not drop along with the handoff ratio.

// measurement-network/handoff-surface.mjs — the open surface and irreversible items at each handoff level (model)
import { LEVELS, ITEMS, count, maintenance } from "./handoff-inventory.mjs";

// Per level, items that cannot be changed once set up at that level (fictional).
const IRREVERSIBLE = [
  ["the cluster's internal address space", "cluster version upgrade (one-way)", "the node pool's architecture"],
  ["the network plugin given when the cluster is created", "cluster version upgrade (one-way)",
    "the cluster's internal address space"],
  ["the published task definition version", "the network mode given to the task",
    "the resource the execution identity is bound to"],
];

if (import.meta.url === `file://${process.argv[1]}`) {
  console.log("level".padEnd(22) + "open surface".padEnd(14) + "handed off".padEnd(13) +
    "handoff ratio".padEnd(15) + "annual maintenance".padEnd(20) + "irreversible items");
  LEVELS.forEach((d, i) => {
    const open = count(i, "yours") + count(i, "shared");
    const handed = count(i, "provider") + count(i, "none");
    console.log(d.padEnd(22) + `${open}/${ITEMS.length}`.padEnd(14) +
      `${handed}/${ITEMS.length}`.padEnd(13) + `${Math.round((100 * handed) / ITEMS.length)}%`.padEnd(15) +
      `${maintenance(i)} h`.padEnd(20) + IRREVERSIBLE[i].length);
  });
  console.log("");
  LEVELS.forEach((d, i) => console.log(`${d}: ` + IRREVERSIBLE[i].join("; ")));
  const m0 = maintenance(0), m2 = maintenance(2);
  console.log(`\nhandoff gain: annual maintenance drops from ${m0} hours to ${m2} hours ` +
    `(${m0 - m2} hours, ${Math.round((100 * (m0 - m2)) / m0)}%)`);
  console.log(`handoff cost: kept decisions drop from ${count(0, "yours")} items to ${count(2, "yours")} items, ` +
    `but the number of irreversible items stays at ${IRREVERSIBLE[0].length} across all three`);
}

level                 open surface  handed off   handoff ratio  annual maintenance  irreversible items
self-run cluster      15/15         0/15         0%             288 h               3
managed cluster       13/15         2/15         13%            204 h               3
task-based execution  5/15          10/15        67%            72 h                3

self-run cluster: the cluster's internal address space; cluster version upgrade (one-way); the node pool's architecture
managed cluster: the network plugin given when the cluster is created; cluster version upgrade (one-way); the cluster's internal address space
task-based execution: the published task definition version; the network mode given to the task; the resource the execution identity is bound to

handoff gain: annual maintenance drops from 288 hours to 72 hours (216 hours, 75%)
handoff cost: kept decisions drop from 15 items to 3 items, but the number of irreversible items stays at 3 across all three

The last column summarizes what this course has been counting from the start: as the open surface drops from 15 to 5, the number of irreversible items stays at three. The handoff ratio climbs to 67 percent, the maintenance load drops by 75 percent, but the number of items that cannot be changed once set up never changes. Only the names of the items change.

Comparing the irreversible items across the three levels reveals a pattern. In both the self-run cluster and the managed cluster, what stays fixed is the address space; it is given when the cluster is set up and stands for the cluster’s entire life. At the task-based level, the address space question disappears, but three new fixed items take its place: the published task definition’s version does not change, the network mode given to a task is set when the task is created, and the resource the execution identity is bound to cannot be changed afterward. These are the first lesson’s subnet and architecture items returning in the same shape, under a different name.

Where the maintenance hours go is also readable in the same table. The largest part of the 75-percent drop comes from a single item: control plane operation and its redundancy, the inventory’s two most expensive items at 84 hours a year combined, and they leave entirely at the first handoff. Most of the 132 hours that leave at the second handoff are node maintenance — patching, the network and storage plugins, the address plan. The handoff’s gain is proportional not to the number of items but to which items leave.

Cluster version upgrade is an irreversible item at two levels at once, and there is a single reason: the upgrade is one-way. Once a version has been upgraded, returning to the old version is not an undo, it is setting up a new cluster — and moving to that cluster demands the work this lesson’s last section measures.

What Travels at Exit

The handoff decision is a gain for as long as you stay at that level. The other side of the gain shows up only when you leave: how much of the configuration is a portable definition, and how much is a record written into the provider’s format.

// measurement-network/exit-cost.mjs — configuration that does not travel at exit, at each handoff level (model)
import { LEVELS, ITEMS, count, maintenance } from "./handoff-inventory.mjs";

// Move rule (fictional hours): yours moves; the provider's format is rewritten; fully handed off is
// reinstalled at the new place; absent at that level means the decision is made from scratch.
const MOVE = { yours: ["moves", 2], shared: ["rewritten", 10],
  provider: ["reinstalled", 24], none: ["reborn", 16] };

if (import.meta.url === `file://${process.argv[1]}`) {
  const kinds = Object.keys(MOVE);
  console.log("level".padEnd(22) + kinds.map((t) => `${MOVE[t][0]}`.padEnd(18)).join("") +
    "exit hours".padEnd(14) + "not portable");
  const hours = LEVELS.map((d, i) => {
    const n = kinds.map((t) => count(i, t));
    const s = n.reduce((a, v, j) => a + v * MOVE[kinds[j]][1], 0);
    console.log(d.padEnd(22) + n.map((v) => String(v).padEnd(18)).join("") +
      `${s} h`.padEnd(14) + `${n[2] + n[3]}/${ITEMS.length}`);
    return s;
  });
  const gain = maintenance(0) - maintenance(2), diff = hours[2] - hours[0];
  console.log(`\nannual maintenance gain ${gain} h; exit cost difference ${diff} h`);
  console.log(`the handoff's payback is ${(diff / gain).toFixed(2)} years: the time task-based execution ` +
    `gains in a year is almost entirely paid back at exit`);
  console.log(`under task-based execution, decisions dropped from ${count(0, "yours")} items to ${count(2, "yours")} items, ` +
    `but at exit ${count(2, "none")} items will be decided from scratch again`);
}

level                 moves             rewritten         reinstalled       reborn            exit hours    not portable
self-run cluster      15                0                 0                 0                 30 h          0/15
managed cluster       11                2                 2                 0                 90 h          2/15
task-based execution  3                 2                 6                 4                 234 h         10/15

annual maintenance gain 216 h; exit cost difference 204 h
the handoff's payback is 0.94 years: the time task-based execution gains in a year is almost entirely paid back at exit
under task-based execution, decisions dropped from 15 items to 3 items, but at exit 4 items will be decided from scratch again

The last column is the handoff decision’s price tag: under task-based execution, ten of fifteen items do not travel. Six are reinstalled at the new place, and four have to be decided from scratch again — node size, node count, cluster version, and shared processes on the node come back as questions at exit. Handing off did not eliminate the decision; it postponed it.

Placing the two numbers side by side produces the measure of the decision. Task-based execution gains 216 hours of maintenance a year; leaving that level costs 204 hours more than leaving a self-run cluster. The payback is 0.94 years: if you stay less than a year, the handoff gains no time; if you stay longer than a year, every additional year is a net gain. This is the only answer the question “which level is better” can be given by number, and the answer depends not on the level itself but on how long you stay.

The first column is also a result in its own right. All three levels have three items that stay portable: task scaling, resource request and limit, and image repository identity. Because these are never handed off at any level, they never need rewriting at any exit. These three items that cannot be handed off are decisions that belong to the workload itself — how many copies run, how much resource each copy requests, and which image it runs. No matter how far the handoff goes, these three remain; they are the actual decision set that stays above the rented layer.

One warning sits where the table does not show it. Exit hours count only the rewriting of configuration; the interruption during the move, the dual-running period, and data migration are not in this table. The real exit takes longer than these rows say, not shorter.

Summary

• Moving to a managed cluster hands off less than expected: two of fifteen items are fully handed off, two more as shared; eleven items stay in place, and annual maintenance drops from 288 to 204 hours.
• Under task-based execution, the handoff ratio climbs to 67 percent and four items disappear entirely — the decision is not given to someone else, it stops existing; maintenance drops to 72 hours.
• As the open surface drops from 15 to 5, the number of irreversible items is three at all three levels; handoff changes the items’ names, it does not remove irreversibility.
• Cluster version upgrade is an irreversible item at two levels: returning to the old version is not an undo, it is setting up a new cluster and migrating to it.
• At exit from the task-based level, ten of fifteen items do not travel; six are reinstalled, four are decided from scratch — handing off does not eliminate the decision, it postpones it.
• The handoff’s payback is 0.94 years: it gains 216 hours of maintenance a year and makes exit 204 hours more expensive; what decides is not the level itself but how long you stay.

Next Step

This topic rented the machine from end to end. Its family and size were chosen and idle resource was counted; its image was baked and the balance between startup time and freshness was scanned; persistent and interruptible capacity were separated by job type; the definition was collected into a template; the count was handed off to a group; and finally, two-thirds of the decisions were given to a service. In every lesson, two numbers moved together — decisions kept and items that cannot be undone.

All these instances, groups, and tasks rested on one assumption: that they find each other. The collector writes to the registry, the registry is read from the API endpoint, traffic arrives at the scaling group. Not one address, one rule, or one boundary was written in this topic — the machines were made to talk as if they were in the same room. The next topic builds that room, and its first question is this: which address space do these instances stand in, does that space change after it is set up, and which decision does the first door opened to the outside make irreversible?