WEB / WEB-20.03

Containers, Kubernetes, serverless, and edge

Learn runtime replacement, readiness, and persistent ownership separately from platform names.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Replace / ready

Old instance
Old runtime memory and the authoritative committed note belong to separate owners; replacement has not started.
Request dispatcher
Read waiting
Platform projection
runtime-a known
Local runtime
Cache Tea; count2
Persistent note owner
Tea note committed
Replace
Own environment replacement discards the old memory object; the new runtime starts cache-empty while the persistent owner is unchanged.
Request dispatcher
Read waiting
Platform projection
runtime-b created
Local runtime
Cache empty; count0
Persistent note owner
Tea note committed
Running is separate
The supplied status is Running but readiness=false; the controller projection does not yet grant traffic eligibility.
Request dispatcher
Read waiting
Platform projection
Running; ready=false
Local runtime
Cache empty; count0
Persistent note owner
Tea note committed
Traffic not selected
The local dispatcher excludes the unready runtime from eligibility; this own policy is not a real kubelet probe.
Request dispatcher
Eligible set empty
Platform projection
Running; ready=false
Local runtime
Cache empty; count0
Persistent note owner
Tea note committed
Readiness changes
Declared initialization supplies ready=true and the local eligible set is derived again.
Request dispatcher
runtime-b eligible
Platform projection
ready=true supplied
Local runtime
Cache empty; count0
Persistent note owner
Tea note committed
Read persistent owner
The runtime reads its own SQLite file through a new connection; the committed Tea note survived memory-cache replacement.
Request dispatcher
runtime-b eligible
Platform projection
ready=true supplied
Local runtime
Independent DB read
Persistent note owner
Tea note committed
Result checked
The direct local adapter Tea response is independently parsed; no Docker or cluster networking execution is claimed.
Request dispatcher
Tea response checked
Platform projection
ready=true supplied
Local runtime
Public cache Tea
Persistent note owner
Tea note committed

Warm / new

Input prepared
A fixed public input is supplied to the local function; no identity, secret, or cloud request is used.
Request dispatcher
Invocation-a supplied
Platform projection
env-a allocated
Local runtime
count0; public only
Persistent note owner
Tea note committed
First invocation
The own environment counter becomes 1 on the first call; this memory observation is not a global durable request counter.
Request dispatcher
Invocation-a supplied
Platform projection
env-a allocated
Local runtime
env-a count1
Persistent note owner
Tea note committed
Same environment
A second ordinary input uses the same local environment; the previous counter remains transient state.
Request dispatcher
Invocation-b supplied
Platform projection
env-a allocated
Local runtime
env-a count1
Persistent note owner
Tea note committed
Warm projection
Counter 2 is observed; the scene illustrates warm reuse without executing a Lambda invocation.
Request dispatcher
Invocation-b supplied
Platform projection
env-a allocated
Local runtime
env-a count2
Persistent note owner
Tea note committed
New environment
A new own environment does not share the prior memory; the authoritative public note remains separate.
Request dispatcher
Invocation-b supplied
Platform projection
env-b allocated
Local runtime
env-b count0
Persistent note owner
Tea note committed
Counter restarts
The new environment first invocation yields 1; the earlier 2 was not retained as a durable sequence.
Request dispatcher
Invocation-b supplied
Platform projection
env-b allocated
Local runtime
env-b count1
Persistent note owner
Tea note committed

Edge transform

Public source
The public Tea note representation is supplied input; no edge geography or network measurement exists.
Request dispatcher
Public input fixed
Platform projection
Edge placement assumed
Local runtime
Transform not run
Persistent note owner
Tea source retained
Copy boundary
The own function copies the input object before transformation; the original source owner remains unchanged.
Request dispatcher
Public input fixed
Platform projection
Edge placement assumed
Local runtime
Input copied locally
Persistent note owner
Tea source retained
Add metadata
The local transform adds only a fixed servedBy label; the title remains unchanged and no attestation is claimed.
Request dispatcher
Public input fixed
Platform projection
Edge placement assumed
Local runtime
servedBy=edge-demo
Persistent note owner
Tea source retained
Validate output
An independent JSON roundtrip checks title and metadata relationships; this is not an Edge provider execution.
Request dispatcher
Output JSON checked
Platform projection
Edge placement assumed
Local runtime
servedBy=edge-demo
Persistent note owner
Tea source retained
Preserve scope
The edge-demo placement selects a different serving boundary and preserves the original Tea source. The location label alone provides no latency or autoscaling observation.
Request dispatcher
Source still unchanged
Platform projection
Edge placement assumed
Local runtime
servedBy=edge-demo
Persistent note owner
Tea source retained

ACTORS · STATE · DATA FLOW

Image, instance, and durable state have different lifecycles

A container is an execution boundary for an application process with its dependencies and selected isolation mechanisms. The image, running instance, and durable application data are different objects. Linux containers typically share the host kernel; environments such as Docker Desktop can place that host inside a VM. Do not assign a separate kernel to every container. Isolation depends on runtime, privilege, and mount choices, and does not supply application authorization.

A file in a writable container layer and data in a separately managed persistent volume have different lifetimes. Docker does not treat data in a removed container layer as persistent; a volume can have its own lifecycle. Process restart, container replacement, and volume deletion are distinct events. The fixture discards runtime-a memory, starts runtime-b with an empty cache, and reads committed Tea note from an own SQLite file using a new connection. It observes a selected persistence boundary, not Docker storage.

Kubernetes coordinates routing, replicas, and lifecycle for a web runtime; it does not automatically validate business logic or database transactions. A Service can provide a logical endpoint over a changing Pod set, with ingress and external exposure chosen separately. Running phase alone does not establish HTTP readiness. Readiness supports traffic eligibility while liveness supports restart decisions under selected failures; the probes have different purposes.

Serverless and edge retain ownership

Serverless does not mean an absence of servers. It means that provisioning and execution-environment lifecycle responsibilities are shared with a platform. AWS Lambda default-function environments have phases such as Init, Invoke, and Shutdown. They can be reused but should not be assumed to persist indefinitely. Product options such as Managed Instances and Durable Functions have different concurrency or persistence contracts. Transient-state discussion here is limited to the default-environment example.

Warm reuse can retain a module-level object or transient cache from a previous invocation. A new environment need not contain it, and per-request identity or private data must not become a public cache entry. In the fixture the invocation counter becomes 1 and then 2 in one local Python environment, and returns to 1 in a new instance. It describes memory lifetime, not a global durable sequence or distributed request count. Runtime results and authoritative note state retain separate owners.

Edge computing can place selected computation closer to viewers. A CDN cache hit alone does not imply code execution. Lambda@Edge provides a named example of functions attached to CloudFront request/response triggers; other edge products have different runtimes and APIs. We run an own local function that adds a fixed served-by label to a public response. This does not measure geographic placement, latency reduction, automatic scaling, or platform limits.

Read every scenario without motion

Empty memory

Scope of the old memory
Runtime-a held Tea note in publicCache and 2 in invocations. These are runtime-local memory fields, not established persistent note records.
Runtime replacement
runtime-a: publicCache=Tea note
State / routing owner
invocations=2
Trust boundary
Storage not inspected yet
The new runtime starts empty
Runtime-b has publicCache=null and invocations=0. Sharing an imageAlias does not transfer runtime-a memory into the new process.
Runtime replacement
imageAlias=notes-image-v1
State / routing owner
runtime-b: publicCache=null / invocations=0
Trust boundary
Image and memory differ
The note has a separate owner
PersistentNote contains id=tea, title=Tea note and revision=1. An empty cache does not show deletion of this storage record.
Runtime replacement
newMemory.publicCache=null
State / routing owner
persistentNote.revision=1
Trust boundary
Persistent record observed separately
The reopened record
TitleAfterReopen=Tea note shows a successful reread in this example. It does not establish a populated memory cache or crash durability.
Runtime replacement
titleAfterReopen=Tea note
State / routing owner
newMemory.publicCache=null
Trust boundary
Reread and crash testing differ
An empty cache does not decide access
A cache miss means neither a missing stored note nor user access permission. Each outcome requires its storage or authorization owner decision.
Runtime replacement
persistentNote.id=tea
State / routing owner
cache=null
Trust boundary
Object permission absent from this record
Report the lifetimes separately
Runtime memory reset while the public note could be reread. These observations coexist and do not establish reuse of old memory state.
Runtime replacement
runtime-b: invocations=0
State / routing owner
reopened title=Tea note
Trust boundary
Two separate state owners

Running or ready?

Read the running state
Running=true records a running runtime. This field alone does not establish request eligibility.
Runtime replacement
running=true
State / routing owner
Readiness not inspected yet
Trust boundary
Selection decision pending
Initial readiness is false
ReadyBefore=false and eligibleBefore=[] are supplied together. Runtime-b is not a routing candidate in this snapshot.
Runtime replacement
readyBefore=false
State / routing owner
eligibleBefore=[]
Trust boundary
Running alone is insufficient
No instance is selected from an empty set
Inventing an eligible runtime from empty eligibleBefore exceeds the record. Running=true does not supply the missing eligibility condition.
Runtime replacement
running=true
State / routing owner
eligibleBefore=[]
Trust boundary
Readiness condition required first
The later snapshot changes
ReadyAfter=true and eligibleAfter=[runtime-b] describe a later observation. They do not make the earlier runtime ready retroactively.
Runtime replacement
readyAfter=true
State / routing owner
eligibleAfter=[runtime-b]
Trust boundary
Earlier state remains distinct
Eligibility is not operation permission
Routing eligibility does not establish application permission for a user and object. Admission and resource decisions are separate boundaries.
Runtime replacement
eligibleAfter=[runtime-b]
State / routing owner
persistentNote.id=tea
Trust boundary
Authorization is required separately
Do not derive outcomes from a platform label
This ledger teaches readiness semantics. A Kubernetes or Docker label is not evidence of correct policy in a real cluster.
Runtime replacement
running=true / readyAfter=true
State / routing owner
eligibleAfter=[runtime-b]
Trust boundary
Teaching record, not a cluster observation

ASSUMPTION · BOUNDARY · CONTROL

Confusing running, ready, and completed

A replica process may have started while initial data loading is incomplete. Treating Running as ready can produce unusable responses during ordinary startup. Keep platform status distinct from the application readiness predicate and expose the selected traffic decision. In the replacement branch runtime-b exists and is running, but the native adapter does not select it while ready=false. After ready=true an own public read proceeds; this is not a measured kubelet probe.

A restart or new instance alone does not establish the state of a previous business effect. Resetting a memory counter does not erase a committed note, and a running process does not prove a prior database write committed. Review runtime identity, pending work, and persistent-owner results separately. The retry and idempotency boundary from WEB-19.S01 remains relevant when a container or function identity changes.

Trusting transient state too broadly

State that can survive warm reuse conflicts with an assumption that every invocation starts clean. Conversely, treating memory as the durable source creates loss on replacement or disagreement across replicas. This lesson uses only a public Tea note and a counter. Without reading real secrets or user identities, it shows the purpose of the cache and how the application returns to its authoritative owner.

An edge or managed-platform label does not prove a response is trustworthy, current, or authorized. The own served-by label identifies a transformation point and is not cryptographic attestation. Infrastructure responsibility does not take over application validation or access control. Naming the execution-model boundary prevents the scene from implying unsupported sandbox guarantees or unmeasured performance outcomes.

Read every scenario without motion

Local counter

Identify the environment
The warm example identifies environmentAlias=env-a. Do not infer a global sequence without the counters’ environment scope.
Runtime observation
environmentAlias=env-a
State scope
Counters not inspected yet
Evidence boundary
Scope follows the environment
One and two in the same environment
ObservedCounters=[1,2] are two env-a observations. They show local state reuse within an environment, not counting across all environments.
Runtime observation
env-a: [1,2]
State scope
environment-local state
Evidence boundary
Distributed sequence not observed
Another environment starts at one
NewEnvironmentAlias=env-b and newCounter=1 identify a different owner from env-a’s counter value 2.
Runtime observation
env-a last counter=2
State scope
env-b counter=1
Evidence boundary
Owner changed
Do not invent a total
The record does not aggregate invocations at a durable shared owner. Local values 1 and 2 cannot establish a distributed unique sequence.
Runtime observation
observedCounters=[1,2]
State scope
newCounter=1
Evidence boundary
globalDurableCounter=false
Warm reuse is not a guarantee
Env-a was reused in this example. No separate guarantee is supplied that the next request uses that environment or retains its state.
Runtime observation
env-a reuse observed
State scope
env-b separate state
Evidence boundary
Next environment unknown
A global requirement needs its own owner
A unique global sequence requires a shared-state design that owns that invariant. This record establishes only counters from two environments.
Runtime observation
globalDurableCounter=false
State scope
env-a != env-b
Evidence boundary
Local observation retains its scope

Label and location

Establish the public input
The edge input contains id=tea and title=Tea note. The examined transformation concerns this public representation.
Runtime observation
input.id=tea / title=Tea note
State scope
Output not inspected yet
Evidence boundary
Public representation
An output label was added
Output adds servedBy=edge-demo to the same id and title. This is transform metadata, not a location measurement.
Runtime observation
output.title=Tea note
State scope
servedBy=edge-demo
Evidence boundary
Metadata observed
The input was not mutated
InputMutated=false records that adding an output field did not mutate the input object. Equal values do not establish an identical execution path.
Runtime observation
inputMutated=false
State scope
output.servedBy=edge-demo
Evidence boundary
Input and output are separate records
Location was not measured
LocationMeasured=false is explicit. The edge-demo string does not establish geographic proximity, region or latency.
Runtime observation
servedBy=edge-demo
State scope
locationMeasured=false
Evidence boundary
No location outcome
A label is not attestation
An application field does not replace provider-signed execution attestation. No such evidence is present in this artifact.
Runtime observation
public transform metadata
State scope
locationMeasured=false
Evidence boundary
Attestation not observed
Describe the transformation at the observed scope
The known result is a servedBy field on public output without input mutation. Real edge deployment, placement and network duration require other observations.
Runtime observation
inputMutated=false
State scope
servedBy=edge-demo
Evidence boundary
Only the public transform was observed

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Build a lifecycle ownership table

Record image version, runtime instance identity, readiness, and durable-data reference separately. The table shows what changes on replacement. Choosing persistent data outside a container layer also requires retention, backup, access-control, and deletion ownership. Reading the public SQLite file after an orderly reopen is useful bounded evidence; it does not establish host-crash, replication, or volume durability guarantees.

For platform health decisions, describe traffic the application can accept and the required dependency readiness. The fixture derives eligibility from one ready boolean and does not measure Service-endpoint reconciliation delay. Runtime-b starts cache-empty, reads the title through an independent SQLite connection, and parses the resulting representation separately. These observations teach persistence and readiness without claiming a deployment or orchestrator run.

Separate request results from platform names

For function or edge handlers, distinguish invocation input, response status/body, and the owner of durable effects. Give each input a context-specific decision, and validate reused connections or public caches. Do not assign the same timeout, concurrency, or disk quota to every function type: bind claims to the selected product and version contract. There is no numeric production tuning advice here; counter changes are finite local observations.

The edge transform preserves the source title and adds output metadata without changing the original input object. This local-function behavior does not measure AWS execution or geographic placement. A servedBy field is not a location measurement. Report observations from runtime memory, persistent data and public output at their respective owners.

NOW APPLY IT TO THE CASE

Do process memory, a persistent note and routing readiness share a lifetime?

Atlas stores its public tea note at a storage owner. Runtime-b starts with empty memory after runtime-a is replaced; note survival and request admission are examined separately.

Which components contribute to the case response? Show where UI, service, platform and external-provider outcomes complete along their respective hops.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Runtime replacement / persistent note ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "replacement": {
    "imageAlias": "notes-image-v1",
    "oldInstance": "runtime-a",
    "newInstance": "runtime-b",
    "oldMemory": {
      "publicCache": "Tea note",
      "invocations": 2
    },
    "newMemory": {
      "publicCache": null,
      "invocations": 0
    },
    "running": true,
    "readyBefore": false,
    "eligibleBefore": [],
    "readyAfter": true,
    "eligibleAfter": [
      "runtime-b"
    ],
    "persistentNote": {
      "id": "tea",
      "title": "Tea note",
      "revision": 1
    },
    "titleAfterReopen": "Tea note"
  },
  "warm": {
    "environmentAlias": "env-a",
    "observedCounters": [
      1,
      2
    ],
    "newEnvironmentAlias": "env-b",
    "newCounter": 1,
    "globalDurableCounter": false
  },
  "edge": {
    "input": {
      "id": "tea",
      "title": "Tea note"
    },
    "output": {
      "id": "tea",
      "title": "Tea note",
      "servedBy": "edge-demo"
    },
    "inputMutated": false,
    "locationMeasured": false
  },
  "limits": {
    "containerRuntimeExecuted": false,
    "kubernetesExecuted": false,
    "lambdaExecuted": false,
    "edgeProviderExecuted": false,
    "realNetworkExecuted": false,
    "crashDurabilityTested": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><instance ready=\"false\" selected=\"false\"/></audit>",
    "xpath": "count(/audit/instance[@ready='false' and @selected='true'])",
    "expected": 0,
    "positiveFixtureXml": "<audit><instance ready=\"false\" selected=\"true\"/></audit>",
    "positiveExpected": 1,
    "scope": "Authored inert decision ledger only; these are teaching fields, not product log or API field names.",
    "missingFieldBehavior": "A missing observation is insufficient evidence; zero matches alone proves no runtime control."
  }
}

replacement: Memory replacement and a committed SQLite note have different lifetimes.
warm: Own local environment counter is not a distributed durable sequence.
edge: Public transform metadata proves neither location nor attestation.
selector/limits: Ready-decision XML selector and real-platform execution boundary.

Actual own Python environment/readiness adapters and SQLite orderly reopen. No Docker, Kubernetes, Lambda, edge placement, or crash durability execution.

Two reality checks

Pod Running or container started means ready for requests.

Process/phase and application readiness differ; selected traffic eligibility is derived separately.

Serverless gives fresh memory on every request, and edge is always faster.

Environment reuse is product-qualified and transient state can remain. Edge performance needs real measurement and dependency placement.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Runtime-a is replaced; runtime-b is running but readyBefore=false. Is it traffic-eligible?

No; eligibleBefore is empty; readyAfter admits it to the list.
Yes; every running container must receive all requests.

Read the explained answer

No; eligibleBefore is empty; readyAfter admits it to the list. — A running-process observation does not establish readiness/application acceptability.

Which state does replacement reset, and which state remains with a separate owner?

Selected lesson artifact fields; teaching example

replacement.oldMemory: {"publicCache":"Tea note","invocations":2}
replacement.newMemory: {"publicCache":null,"invocations":0}
replacement.persistentNote: {"id":"tea","title":"Tea note","revision":1}

If the image alias matches, the old heap transfers to every new instance.
New memory is empty/counter 0; persistent Tea note revision 1 remains.

Read the explained answer

New memory is empty/counter 0; persistent Tea note revision 1 remains. — Replacing runtime-local memory does not automatically delete the separate persistent-store record.

Warm-environment counters are 1, 2 and a new environment starts at 1. Why is this neither a durable global counter nor a real serverless-provider measurement?

Read the explained answer

Warm reuse may retain the same environment memory for a while; a new environment starts a new local counter. GlobalDurableCounter=false. The fixture executes no Container/Kubernetes/Lambda/edgeProvider; edge-demo servedBy establishes neither actual geographic location nor crash durability.

□ I did not count warm reuse as global durability.

□ I inferred no geographic/runtime proof from provider aliases.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Docker — What is a container?Explanation · Containers versus virtual machines (VMs)
Docker — StorageContainer layer basics · Volume mounts · Bind mounts
Kubernetes — ServiceServices in Kubernetes · Service type · Services without selectors
Kubernetes — Pod LifecyclePod lifetime · Pod phase · Readiness probe · Liveness probe
AWS Lambda — Execution environment lifecycleLambda execution environment lifecycle · Shutdown phase · Cold starts and latency
Amazon CloudFront — Customize at the edge with Lambda@EdgeCustomize at the edge with Lambda@Edge
AWS — Shared Responsibility ModelAWS responsibility “Security of the Cloud” · Customer responsibility “Security in the Cloud” · Shared Controls
SQLite — Transaction2. Transactions · 2.3. Implicit versus explicit transactions
SQLite — IsolationIsolation Between Database Connections

YOUR NOTES / THIS BROWSER

Containers, Kubernetes, serverless, and edge

1. Core · Mechanism

Replace / ready

Warm / new

Edge transform

Image, instance, and durable state have different lifecycles

Serverless and edge retain ownership

2. Red · Trust & Impact

Empty memory

Running or ready?

Confusing running, ready, and completed

Trusting transient state too broadly

3. Blue · Secure development & defense

Local counter

Label and location

Build a lifecycle ownership table

Separate request results from platform names

Do process memory, a persistent note and routing readiness share a lifetime?

Two reality checks

Runtime-a is replaced; runtime-b is running but readyBefore=false. Is it traffic-eligible?

Which state does replacement reset, and which state remains with a separate owner?

Warm-environment counters are 1, 2 and a new environment starts at 1. Why is this neither a durable global counter nor a real serverless-provider measurement?

Sources and scope