- PART I — CONTAINERS AND THE DEPLOYMENT UNIT
- Chapter 1 — Deployment Is a Runtime Concern
- Chapter 2 — Image, Container, and Process Are Different Things
- Chapter 3 — Namespaces: Isolation Without a Virtual Machine
- Chapter 4 — cgroups: CPU, Memory, and Resource Control
- Chapter 5 — Layered Filesystems and Immutable Images
- Chapter 6 — Container Networking: Namespaces, veth, Bridges, and Ports
- Chapter 7 — Configuration, Environment, and the Twelve-Factor Boundary
- Chapter 8 — Secrets Are Runtime Dependencies
- Chapter 9 — Liveness, Readiness, and Startup Are Different Questions
- Chapter 10 — Graceful Shutdown, SIGTERM, and Responsibility During Exit
- Chapter 11 — State, Volumes, and the Cost of Pretending Containers Are Stateless
- Chapter 12 — Registries, Image Identity, and the Software Supply Chain
- Visual I — Source → Image → Container → Process
- PART II — ORCHESTRATION AND KUBERNETES
- Chapter 13 — Why Orchestration Exists
- Chapter 14 — The Kubernetes Control Plane: Desired State and Reconciliation
- Chapter 15 — Nodes, kubelet, and the Machine Beneath the Cluster
- Chapter 16 — Pods: The Smallest Schedulable Unit
- Chapter 17 — Deployments, ReplicaSets, and Declarative Rollout
- Chapter 18 — Services, Endpoints, and Stable Network Identity
- Chapter 19 — Ingress, Gateway, and the North-South Boundary
- Chapter 20 — Cluster DNS and Service Discovery
- Chapter 21 — ConfigMaps, Secrets, and Configuration Propagation
- Chapter 22 — Requests, Limits, QoS, and Resource Pressure
- Chapter 23 — Probes, Pod Lifecycle, and Termination Semantics
- Chapter 24 — Jobs, CronJobs, and Work That Must Finish
- Chapter 25 — StatefulSets, Persistent Volumes, and Stable Identity
- Visual II — Desired State → Control Plane → Scheduler → Pod → Node
- PART III — SCALING, CAPACITY, AND FAILURE DOMAINS
- Chapter 26 — Scheduling: Affinity, Taints, Topology, and Placement
- Chapter 27 — Capacity Planning Before Autoscaling
- Chapter 28 — Horizontal Scaling: Replicas Are Not Throughput
- Chapter 29 — Vertical Scaling and the Cost of Changing Resource Shape
- Chapter 30 — Autoscaling Signals: CPU, Memory, Latency, and Custom Metrics
- Chapter 31 — Queue-Driven and Event-Driven Scaling
- Chapter 32 — Load Balancing Across Replicas and Failure Domains
- Chapter 33 — Resource Throttling, OOM, and the Difference Between Slow and Dead
- Chapter 34 — Disruption Budgets, Draining, and Safe Capacity Loss
- Chapter 35 — Multi-Zone Resilience, Failover, and Failure-Domain Design
- Visual III — Demand → Load Balancer → Replicas → Bottleneck → Autoscaler
- PART IV — PRODUCTION OPERATIONS AND PLATFORM RESPONSIBILITY
- Chapter 36 — Observability as a Production Control Loop
- Chapter 37 — Logs, Metrics, Traces, Profiles, and the Signals They Actually Provide
- Chapter 38 — SLIs, SLOs, Error Budgets, and Reliability Policy
- Chapter 39 — Rolling, Blue-Green, and Canary Deployment
- Chapter 40 — Schema and Contract Evolution During Independent Rollout
- Chapter 41 — Incident Response, On-Call, and Recovery as Architecture
- Chapter 42 — Policy, Identity, Secrets, and Runtime Security
- Chapter 43 — Image Provenance, SBOMs, Signing, and Supply-Chain Evidence
- Chapter 44 — Cost, FinOps, and the Economics of Always-On Capacity
- Chapter 45 — The Production Ledger: When Platform Complexity Has Earned Its Cost
- Visual IV — Source → Image → Registry → Cluster → Traffic → Telemetry → Operator
- Appendix A — Tooling for Volume I: The Machine Beneath .NET
- Appendix B — Tooling for Volume II: Crossing the Process Boundary
- Appendix C — Tooling for Volume III: Orchestrating the Distributed System
- Appendix D — Unified NEXUS-1 Systems Toolchain Map
- Glossary
- Sources and References
- Index
FROM RUNTIME TO DISTRIBUTION
VOLUME III
From containers and Kubernetes to autoscaling, observability, Prometheus, Grafana, SLOs, security, and production failure. Volume III shows how distributed architecture becomes an operable, measurable, evidence-driven production system.
Minimum price
$109
$159
You pay
Author earns
PDF
About
About the Book
What happens when distribution is no longer a design diagram, but a production system that must actually run, scale, recover, and remain understandable?
Volume I of From Runtime to Distribution moved downward through the machine beneath .NET: CPU execution, operating-system boundaries, processes, threads, the CLR, IL, JIT compilation, native code, stacks, heaps, and garbage collection.
Volume II crossed the process boundary. It followed execution into concurrency, asynchronous I/O, IPC, serialization, DNS, TCP, TLS, HTTP, gRPC, queues, retries, idempotency, partial failure, and the real cost of distribution.
Volume III begins where distributed architecture becomes operational reality.
The moment software is packaged into images, started inside containers, placed on nodes, replicated across a cluster, exposed through stable network identities, observed through telemetry, and managed by control loops, a new class of engineering questions appears.
An image is not a container.
A container is not a process.
A replica is not throughput.
A limit is not capacity.
A healthy process is not necessarily a Ready workload.
A successful rollout is not proof that users are unharmed.
And a green dashboard is not the same thing as evidence that the system is correct.
From Runtime to Distribution — Volume III: Orchestrating the Distributed System develops the engineering model required to reason about this production layer.
The book begins with containers as runtime boundaries.
Images, containers, and processes are separated carefully. Linux namespaces explain isolation. cgroups explain CPU, memory, and resource control. Layered filesystems explain immutable images and writable runtime state. Container networking, configuration, secrets, probes, shutdown, volumes, and registries are treated as runtime contracts rather than deployment details.
From there, the book moves into Kubernetes.
The Kubernetes control plane is introduced as a desired-state and reconciliation system rather than as a collection of YAML files. Pods, Deployments, ReplicaSets, Services, EndpointSlices, DNS, ConfigMaps, Secrets, resource requests and limits, probes, Jobs, CronJobs, StatefulSets, Persistent Volumes, scheduling, affinity, taints, tolerations, and topology constraints are connected back to the runtime realities underneath them.
The next step is capacity and scaling.
Horizontal scaling is separated from actual throughput. Vertical scaling is treated as a change in resource shape rather than a free performance improvement. CPU, memory, latency, queue depth, and custom metrics are examined as autoscaling signals. Resource throttling, OOM conditions, disruption budgets, node draining, failure domains, and multi-zone resilience are treated as measurable operational behavior.
The final part moves into production responsibility.
Observability becomes a control loop built from logs, metrics, traces, profiles, and explicit evidence. SLIs, SLOs, error budgets, and burn rates become reliability policy. Rolling, blue-green, and canary deployment are examined as periods in which multiple software realities may coexist. Schema and contract evolution are treated as distributed rollout problems. Incident response, runtime security, supply-chain evidence, SBOMs, signing, provenance, and FinOps are incorporated into the same operational model.
Prometheus and Grafana receive particular attention because production systems cannot be operated from static architecture diagrams.
Prometheus is used as the metric and query layer: targets, dimensional time series, PromQL, rates, histograms, recording rules, alert rules, and SLO evidence.
Grafana becomes the human operational surface: dashboards, variables, annotations, heatmaps, SLO views, alerting, rollout correlation, and drill-down from a production symptom toward the exact workload, Pod, version, image digest, and underlying mechanism.
But the book does not stop at theory.
Four extensive practical appendices turn the trilogy into a working engineering laboratory.
Appendix A — Tooling for Volume I moves from process and thread inspection to IL, JIT disassembly, GC diagnostics, memory analysis, dotnet-counters, dotnet-trace, dotnet-gcdump, dotnet-dump, SOS, VMMap, perf, strace, and runtime evidence.
Appendix B — Tooling for Volume II crosses the process boundary with pipes, shared memory, Unix domain sockets, TCP, DNS, TLS, HTTP/2, gRPC, Wireshark, tcpdump, retries, idempotency, queues, OpenTelemetry, and controlled distributed-failure experiments.
Appendix C — Tooling for Volume III brings the system into containers and Kubernetes with Docker inspection, namespaces, cgroups, kubectl, probes, scheduling, autoscaling, rollouts, Prometheus, PromQL, Grafana dashboards, alerting, SLOs, and production failure drills.
Appendix D — Unified NEXUS-1 Systems Toolchain Map connects all three volumes into one evidence path:
Source → IL → JIT → Process → OS → IPC → Network → Image → Container → Kubernetes → Prometheus → Grafana → Operator → Evidence
Four visual checkpoints compress the major production transitions:
- Source → Image → Container → Process
- Desired State → Control Plane → Scheduler → Pod → Node
- Demand → Load Balancer → Replicas → Bottleneck → Autoscaler
- Source → Image → Registry → Cluster → Traffic → Telemetry → Operator
The result is the final bridge in the trilogy: from understanding what the machine executes, to understanding what distribution changes, to understanding how a distributed system survives production.
From Runtime to Distribution — Volume III is written for .NET developers, software architects, technical leads, platform engineers, SREs, DevOps engineers, and software engineers who want to understand containers and Kubernetes not as a collection of commands, but as the next runtime layer of a distributed system.
The central question of the volume is simple:
When a distributed architecture reaches production, can we prove that its platform complexity has actually earned its cost?
Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios
Feedback
Author
About the Author
Grigorios Agathangelidis
My name is Grigorios Agathangelidis, and my professional background is in Electrical Engineering and Software Engineering. Much of my work has focused on .NET, distributed systems, software architecture, domain modeling, and the engineering of systems whose behavior must remain understandable even after they move beyond the boundaries of a single process.
From Runtime to Distribution grew from a sequence of engineering questions.
Volume I asked:
What is actually happening beneath our code before distribution begins?
That led downward through CPU execution, operating-system boundaries, processes, threads, the CLR, IL, JIT compilation, native code, stack frames, managed heaps, and garbage collection.
Volume II asked:
What changes when execution crosses a process boundary?
That led outward into concurrency, asynchronous I/O, IPC, serialization, DNS, TCP, TLS, HTTP, gRPC, queues, retries, idempotency, partial failure, and the uncertainty that appears when another process must participate.
Volume III completes that progression by asking a third question:
What happens when a distributed architecture must survive production?
At that point, architectural diagrams are no longer enough. Software must be packaged into immutable artifacts, started inside containers, constrained by CPU and memory policy, scheduled onto machines, replicated, discovered over networks, observed through telemetry, rolled out without breaking contracts, and recovered when assumptions fail.
That is why this volume moves through containers, Linux namespaces and cgroups, Kubernetes, scheduling, autoscaling, failure domains, observability, SLOs, deployment strategies, runtime security, supply-chain evidence, FinOps, Prometheus, and Grafana.
My broader engineering approach is strongly influenced by one principle:
abstractions remain useful only while their boundaries remain understood.
Containers simplify deployment, but they do not remove processes, namespaces, memory pressure, or kernel scheduling.
Kubernetes simplifies orchestration, but it does not remove partial failure, resource scarcity, network uncertainty, contract evolution, or operational responsibility.
Prometheus can preserve metric evidence, and Grafana can make that evidence visible, but neither automatically explains why a system failed.
The underlying mechanism still matters.
This book is part of the wider NEXUS-1 body of work, which explores complex systems through software architecture, systems engineering, simulation, causal reasoning, domain-driven design, distributed systems, and formal methods. Across that work, I try to preserve the same distinction repeatedly:
what is modeled versus what is measured,
what is declared versus what actually runs,
what is specified versus what is merely observed,
and what an abstraction promises versus what the underlying system can actually guarantee.
I approach these subjects primarily as an engineer rather than as an academic specialist in operating systems, compiler implementation, Kubernetes internals, or reliability theory. Where behavior depends on a particular runtime, kernel, protocol version, container implementation, Kubernetes release, exporter, or monitoring system, I try to make that dependency explicit rather than promote one implementation detail into a universal law.
The practical Appendices in Volume III reflect that philosophy.
The objective is not to memorize commands such as kubectl, perf, strace, dotnet-trace, tcpdump, or PromQL expressions.
It is to learn how to ask a precise engineering question, identify the layer that owns that question, select the smallest tool capable of observing it, collect evidence, and stop before claiming more than that evidence supports.
For me, Volume III represents the final transition in the From Runtime to Distribution trilogy:
from understanding what executes,
to understanding what distribution changes,
to understanding what production demands from the distributed system we created.
Because once software reaches production, the final engineering question is no longer simply whether the architecture is elegant.
It is:
Can we observe it, operate it, recover it, and prove that its complexity has actually earned its cost?
Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.
Contents
Table of Contents
Get the free Community Edition
You can get the free Community Edition in PDF or EPUB just by sharing your name and email address with the author.
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.