Program artifact
The instructions are available, but no running state exists and no machine resources are being consumed on its behalf.
Threshold · The Shared Machine
One machine.
Several executions.
Start one process, then another. The machine accepts each without drama. Separate running state looks like all the boundary we need.
What boundary lets a shared machine treat one application's execution as a distinct, governable unit?
The machine provides CPU, memory, files, network, and operating-system services. Each process merely inhabits that shared environment. Coexistence is easy. Independence is still unproven.
Shared machine / bay 00Three executions active
Process AWeb service
Process BBackground worker
Process CCommand-line utility
CPUMemoryFilesNetwork
Process count: Selected:
Interactive controls awaiting enhancement.
Static state: Three distinct processes share one machine.
First Principles · Code Is Not Execution
The program waits. The execution has a life.
A program on disk is instructions. When those instructions run, the machine supplies time, memory, files, communication, services, and state that exists only while the process lives.
Execution A
The instructions now have memory, CPU time, open files, connections, operating-system dependencies, and an independent lifetime.
Execution B
Start the same program again to test whether identical code produces identical running state.
Shared CPU
Both executions receive time from the same physical machine.
Interactive controls awaiting enhancement.
Static observation: One running execution depends on the shared machine. Starting identical code again would create another lifetime, not another physical world.
Programinstructions on disk
Execution A + Execution Bindependent running state
Shared machineCPU · memory · files · network · services
Having access to a resource is not the same as having an isolated resource boundary.
Naive Architecture · One Process Per Application
Give every application its own process.
It is the obvious architecture because it genuinely works. A web service, worker, and utility start and stop independently while the operating system schedules them on one efficient machine.
Process-only architectureSeparate running state
Application A → Process Astarts and stops independently
Application B → Process Bstarts and stops independently
Application C → Process Cstarts and stops independently
Shared CPUShared memoryShared filesShared network
Resource treatment
Does CPU or memory treatment belong to the process, the application, or the machine?
Visibility
Should the view of the surrounding machine belong to execution identity or remain a separate concern?
Filesystem context
Should the filesystem context travel with the process or remain machine configuration?
Network context
Should network assumptions follow the process, the application, or the shared machine?
A process gives us separate running state. Whether the surrounding environment needs another abstraction remains unresolved.
Architecture That Almost Worked · Processes Plus Convention
One trusted team can keep the environment coherent.
Assign each application a directory, endpoint, resource expectation, and operator label. Under favorable conditions, this informal boundary is cheap, understandable, and correct.
- DirectoryEach application writes beneath an assigned path.
- EndpointEach application listens at a coordinated endpoint.
- ExpectationEach team knows the application's ordinary resource envelope.
- Operator labelRunbooks record which process belongs to which application.
Coordination Meter
Convention works until coordination becomes the work.
Assign four conventions, then add applications and teams to watch informal agreements spread.
scattered conventions
1 team · 3 applicationsStable
One trusted group keeps four shared conventions coherent.
4 teams · 12 applicationsCoordination rising
Agreements spread across more deployment paths and runbooks.
8 teams · 30 applicationsCoordination dominates
The convention set is now a system that must be maintained.
Interactive controls awaiting enhancement.
Static observation: One team can coordinate directories, endpoints, resource expectations, and operator labels through convention.
Convention is enough
Trusted, compatible applications with predictable demands can share one environment with very little platform machinery.
Coordination becomes architecture
Every new application and team adds rules across directories, endpoint assignments, expectations, deployment systems, and runbooks. No single unit represents them.
Processes plus convention are enough while one trusted group can keep the surrounding environment coherent.
Separate machines provide stronger physical separation but waste capacity for small applications. One shared environment remains efficient. Something between those extremes is attractive, but attraction is not proof.
Breaking Our Design · 01 / Resource Pressure
One process becomes hungry. Its neighbors did not change.
CPU time and memory remain machine resources. As one execution's demand rises, latency and available capacity change for every neighbor sharing that environment.
Pressure Lab · Resource Demand
Raise Process A's demand
Change one execution's demand and observe what moves elsewhere on the shared machine.
Process ADemand: 25%
Only its requested work changed.
Shared machineCPU 39% · memory 40%
Available capacity changes across the common environment.
Processes B + CNeighbor latency: 8 ms
Their own demand is unchanged; their environment is not.
Interactive controls awaiting enhancement.
Static diagnosis: A process identifier does not express resource-control intent. A later decision needs somewhere to refer. Allocation, ownership, limits, borrowing, enforcement, and pressure policy remain deferred to INV-019.
Resource governance must be addressable at the execution boundary without making shared resources private.
Breaking Our Design · 02 / Visibility
The machine and the application do not need the same view.
A process identifies which execution exists. It does not necessarily define what world that execution should observe.
Visibility Lab · Compare Views
Machine-wide or intentionally scoped
The same three processes can be presented through two different views without changing which executions exist.
Machine viewA · B · C
The operating environment has reason to manage all running processes.
Execution A viewA
The selected execution may need only the state relevant to its own work.
Unchanged factThree processes exist
Only the intended environmental view differs.
Interactive controls awaiting enhancement.
Static diagnosis: Execution identity does not automatically define environmental visibility. A visibility-context decision needs somewhere intentional to attach; this scene does not define what must be visible.
Breaking Our Design · 03 / Filesystem Context
Two independent assumptions meet at the same path.
A directory convention repairs cooperative collisions. It does not change an application that was designed as though its expected filesystem were the whole world.
Filesystem Lab · Path Claims
Deliberate sharing or accidental sharing
Compare an intentionally shared dataset with two unrelated claims on the same location.
Application A/config/application.conf
Assumes this location describes its environment.
Application B/config/application.conf
Makes a different assumption about the same location.
Deliberate share/data/shared
Sharing remains valid when the architecture expresses it intentionally.
Interactive controls awaiting enhancement.
Static diagnosis: A filesystem-context decision needs an execution-level reference. Preparation is deferred to INV-016; isolation, layering, portable images, persistence, mounts, and storage semantics remain unresolved or in the Open Backlog.
Breaking Our Design · 04 / Network Context
Two processes request the same endpoint.
Port reassignment works. At small scale, coordinated configuration may remain the best design. As applications multiply, the shared machine becomes a place where every execution negotiates around the others.
Network Lab · Endpoint Decisions
One shared machine, conflicting assumptions
Associate an endpoint decision with each execution without inventing separate network identities.
Execution ANetwork-context decision
Requests endpoint :8080.
Shared machineEndpoint collision
One common environment cannot satisfy both assumptions unchanged.
Execution BNetwork-context decision
Requests endpoint :8080; convention may reassign it.
Interactive controls awaiting enhancement.
Static diagnosis: Network context needs an execution-level reference. Independent network identity remains INV-018's mystery; mechanism and routing details are deliberately postponed.
Breaking Our Design · 05 / Failure Boundary
The process ends. The unanswered relationships remain.
A process can fail independently while consequences cross the environmental boundary it never represented. Exit tells us that running state ended, not what every attached concern should do next.
Failure Lab · Terminate One Process
What survives the disappearance?
The concern labels remain after the process slot empties because their lifetime and ownership are unresolved.
Process AENDED
The independent running state no longer exists.
Attached concernsResource · visibility · filesystem · network
How long should any associated state live?
ContainmentNot established
Which guarantees existed, and where did consequences stop?
The process decides
Can a responsibility inside an execution survive every way that execution disappears?
Its creator decides
Does creation imply continued responsibility?
Another component decides
Would separating work from continued existence create a cleaner responsibility?
Interactive controls awaiting enhancement.
Static diagnosis: Process exit does not define attached-state lifetime, complete containment, or who decides what happens next. Those competing ownership designs remain open for INV-001.
Synthesis · One Reference, Separate Contracts
The same execution keeps being rediscovered.
Resource, visibility, filesystem, and network concerns are independent. Yet every one needs to identify the same running execution before its own decision can apply.
Interactive controls awaiting enhancement.
Common execution reference
Assign each concern
One common execution-level attachment point.Four separate contracts.
concerns attached
repeated relationships found
Static prompt: Assign each independent concern to the execution it governs. The final discovery remains unrevealed until all four relationships are visible.
Contract And Terminology Reveal
One responsibility. No borrowed guarantees.
Every environmental concern governing the same execution must be able to refer to one common execution-level attachment point.
Resource, visibility, filesystem, network, and failure exposed the need for the common reference. They are examples and limits of this responsibility, not five additional contracts.
The machine may remain physically shared. The boundary only prevents each concern from reconstructing the intended execution from unrelated process-level conventions.
The Name Comes Last
One common realization of a boundary around a single process is called a
containerThe name is useful. It is not the discovery, and it does not prove the complete unit an orchestrator should manage.
INV-016
How a container runtime creates the execution environment behind a stable contract.
INV-017
Why one process boundary is not yet proven to be the complete orchestration unit; the Pod problem remains open.
INV-018
What network identity belongs to the managed execution unit.
INV-019
How finite CPU and memory are owned, allocated, borrowed, and protected.
Open Backlog
Filesystem isolation, layering, portable images, persistence, mounts, storage semantics, and visibility mechanisms remain separate mysteries.
Specific operating-system visibility and resource-control mechanisms, including namespaces and cgroups, explain how implementations may realize parts of this architecture. Kubelet and other Kubernetes solution terms belong to later implementation investigations, not to this contract.
The timeless principle: an execution boundary should be defined by the guarantees the execution requires, not merely by the mechanism that starts the process.
Engineering Reflection
A common home does not make the concerns identical.
Name the repeated relationship once
When multiple independent concerns describe the environment of the same execution, give them a common architectural attachment point instead of attaching each directly to unrelated implementation details.
One reference, not one contract
Resource control, network identity, filesystem semantics, visibility, failure containment, runtime design, and orchestration remain separate problems.
Processes plus convention still win
For trusted, cooperative, compatible applications on a shared machine, the simpler design has fewer concepts, moving parts, and platform-created failure modes.
Independent, intentional treatment
A richer attachment point is justified when several environmental concerns must refer to one execution without relying on scattered human agreements.
Costs Accepted
The richer boundary organizes complexity. It does not erase it.
Conceptual layer
Readers and operators must understand another architectural unit.
Lifecycle responsibility
Something must create, maintain, and remove the richer boundary.
More state
The system carries relationships beyond the process's running state.
Component boundaries
More participants must agree on how the common reference is used.
Operational machinery
More mechanisms must be observed, diagnosed, and maintained.
Incorrect assumptions
A named boundary can tempt us to assume guarantees its individual contracts never made.
Investigation Exercise · Four Steps
Remove the names. Find the repeated relationship.
This thought experiment verifies only the common attachment-point discovery. It does not define any individual environmental contract.
Map the concerns
For Applications A, B, and C, predict where resource, visibility, filesystem, and network decisions would attach.
Remove the names
Take Application A's four concern relationships, erase the application label, and ask what common object or boundary remains.
Notice duplication
The contracts and implementations differ, but each relationship independently rediscovers the same execution.
Establish it once
Let every concern refer to the execution through one common attachment point while retaining its own separate contract.
Application A → resource · visibility · filesystem · network
Application B → resource · visibility · filesystem · network
Application C → resource · visibility · filesystem · network
[remove application names]
Concern → EXECUTION ← Concern
Interactive controls awaiting enhancement.
Prediction: Map all four concerns to the execution reference before removing the application names.
The exercise should produce only the common attachment point. It must not decide what any attached concern guarantees.
Ledger · Sources · INV-001 Bridge
Disciplined postponement keeps one discovery honest.
Deliberate Simplifications Ledger
| Deferred question | Why it is deferred | Where it belongs |
|---|---|---|
| How is the execution environment created behind a stable contract? | INV-000 identifies the attachment point, not the component that realizes it. | INV-016 — The Container Runtime Problem |
| Is one process boundary the complete unit an orchestrator should manage? | A single-process realization does not establish the orchestration unit. | INV-017 — The Pod Problem |
| What network identity belongs to the managed execution unit? | Network context is attached without deriving its identity contract. | INV-018 — The Node Networking Problem |
| How are CPU and memory owned, allocated, borrowed, and protected? | Resource context is attached without deriving finite-resource ownership. | INV-019 — The Node Resource Problem |
| How do filesystem isolation, layering, portable images, and visibility mechanisms work? | These mechanisms are not required to establish the common attachment point. | Open Backlog — not yet scheduled |
Sources
Can the thing doing the work also own the promise that it continues to exist?
The execution boundary tells us what one execution contains. INV-001 asks who, if anyone, should decide whether another must exist after it disappears.