The Engineering Foundations Library
Ok, let's talk about something that keeps annoying me.
We have a lot of engineers that know tools. They know Kubernetes, Terraform, Argo, AWS, GitHub Actions, Prometheus, Grafana, Postgres, Redis, Kafka, and whatever else happens to be in the stack this year. That is fine. Tools matter. The problem is that a lot of them do not understand the substrate those tools are built on.
That is where things start to break down. You can teach someone to apply YAML. You can teach someone to run a Terraform plan. You can teach someone to click around in a cloud console, restart a pod, scale a deployment, or follow a runbook. That does not mean they understand the system.
This is the difference that I think a lot of the industry keeps pretending does not matter. We keep teaching the abstraction first, then we act surprised when people cannot reason about what is underneath it. Linux still matters. Networking still matters. Operating systems still matter. Performance, security, distributed systems, and reliability still matter.
The tools did not erase any of that. They just moved the failure modes around, hid some of the knobs, added APIs, and gave everyone more YAML to argue about.
So this is my attempt at building a small foundation library. Not 80 books. Not a giant academic reading list. Not seven books for every subject. Nobody is going to read that. I am talking about a serious, practical list of about 10 books. The kind of list you could hand to an engineer and say, "If you actually work through these, you will understand a lot more of what the hell is happening under the tools you use every day."
The Goal
The goal is not to turn someone into a kernel engineer, network engineer, database engineer, security researcher, and SRE all at the same time. That would be nonsense. The goal is to build enough foundation that an engineer can reason across layers.
When something breaks, I do not want the first response to be guessing. I do not want blind restarts, random scaling, cargo-culted probes, dashboard staring, or "the network is probably broken" because nobody knows what else to say. I want the engineer to be able to ask better questions.
What layer is failing? What assumption broke? What evidence do I have? Is this actually networking, or is it DNS? Is this memory pressure, or is the application lying to me? Is this a database problem, or is the connection pool trash? Is this a queue problem, or are the consumers falling behind because we created our own backpressure issue? Is this a platform problem, or did we deploy garbage and then blame the platform?
That is the point of the list. Not trivia. Judgment.
The List
This is the current foundation library I would hand to someone. It is ordered on purpose. Linux user fluency comes before Linux internals. Networking comes before distributed systems. Operating systems come before performance diagnosis. Reliability comes before pretending a deployment tool is an operational strategy.
The Linux Command Line
William Shotts
This is the actual starting point. Not kernel internals, syscalls, containers, or eBPF. Just the plain reality that if you are going to work around modern infrastructure, you need to be comfortable in a shell.
Files, directories, permissions, pipes, redirects, quoting, expansion, process basics, text processing, scripting, and the general ability to move around a Linux system without treating every command like a spell from some ancient book. A lot of people skip this stage. You can tell.
They can paste commands, but they do not understand what the command is doing. They can follow a quickstart, but they cannot inspect the system when the quickstart fails. They can run a script, but they cannot read it. That is not a great place to be.
This book belongs first because command line fluency is still one of the most basic pieces of technical literacy an infrastructure engineer can have.
How Linux Works
Brian Ward
Once someone can use Linux, they need to understand what Linux is doing. This is the bridge book.
Boot, devices, disks, filesystems, networking, systemd, userspace, containers, virtualization, and the general shape of a Linux system. Not every engineer needs to be a deep Linux specialist, but every infrastructure engineer should understand the operating environment they are working in.
Containers did not make Linux irrelevant. They made Linux more important. Most of what we call cloud native infrastructure is still Linux processes, filesystems, namespaces, cgroups, signals, sockets, mounts, and networking. The fact that it is wrapped in a cleaner interface does not mean the older pieces stopped existing.
This book helps turn Linux from a pile of commands into an actual system.
Computer Networking: A Top-Down Approach
James Kurose and Keith Ross
Networking is one of those areas where people often know just enough to be dangerous. IP addresses, ports, DNS records, security groups, maybe some load balancer vocabulary. Enough to get through the day until something weird happens. Then the guessing starts.
This book is a good foundation because it starts where most engineers actually experience networking: at the application layer. HTTP, DNS, TLS, timeouts, connection resets, retries, congestion, routing, packet loss, NAT, wireless, load balancing, and all the other things that eventually become "the site is slow" or "the service cannot connect."
I do not care if someone can recite every field in a packet header. That is not the point. The point is whether they can reason. Is this DNS? Is this TLS? Is this routing? Is this MTU? Is this packet loss? Is this congestion? Is this connection reuse? Is this load balancer behavior? Is this a retry storm? Is the application just broken?
Without a real networking foundation, network debugging becomes superstition.
Operating Systems: Three Easy Pieces
Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau
Operating systems are not some academic side quest. Scheduling, memory, concurrency, persistence, filesystems, locks, and failure show up in real systems all the time.
A service slows down under load. A process gets killed. Latency spikes during disk activity. Memory usage does not match what someone expected. A program that should scale with concurrency collapses instead. Two nodes behave differently even though everyone swears they are the same.
That is not always "the app." It is not always "the platform." A lot of the time, the answer lives in operating system behavior.
This book gives the reader the mental model. Linux is the main system most of us touch, but the underlying ideas are bigger than Linux. If you do not understand scheduling, memory, filesystems, and concurrency, you are going to have a bad time diagnosing production systems.
The Linux Programming Interface
Michael Kerrisk
This is not an entry-level Linux book. This is the book for the person that already knows their way around Linux and now needs to understand the boundary between userspace and the kernel.
Processes. File descriptors. Signals. Sockets. Terminals. Permissions. Threads. IPC. Syscalls.
That may sound like systems programming material, and sure, it is. But it is also infrastructure material. Process behavior matters. Signal handling matters. PID 1 behavior matters. File descriptors matter. Sockets matter. Permissions matter. Mounts matter. Blocking I/O matters. Namespaces and cgroups matter.
If you work with containers, schedulers, supervisors, service managers, or production Linux systems, this stuff is not optional forever. You can avoid it for a while, but eventually the system will make you pay attention.
This book is large. It is not casual reading. It still earns the spot because so many strange production problems live right at this boundary.
Systems Performance
Brendan Gregg
This is probably the most important book on the list for senior infrastructure and platform engineers. It teaches people how to investigate instead of guessing.
That sounds simple, but it is not how a lot of teams operate. People see a slow service and start scaling things. They blame the database. They blame the network. They blame Kubernetes. They blame the cloud provider. They open a dashboard, stare at 30 graphs, and still cannot explain what question they are trying to answer.
Performance work needs method. CPU, memory, disk, network, filesystems, locks, schedulers, runtimes, databases, containers, and cloud infrastructure all interact. If you do not have a model, you are going to chase symptoms.
This book gives you the model. Latency, saturation, utilization, profiling, tracing, flame graphs, kernel behavior, and the relationship between symptoms and causes. It is the bridge between knowing concepts and being able to diagnose real systems under pressure.
Designing Data-Intensive Applications
Martin Kleppmann and Chris Riccomini
This is the distributed systems book most working engineers need. Not because academic distributed systems do not matter. They do. But most engineers meet distributed systems through data.
Databases. Queues. Logs. Streams. Caches. Replication. Partitioning. Transactions. Indexes. Consistency. Durability. Failure.
This book teaches tradeoffs. That is the part people need. Consistency is a tradeoff. Replication is a tradeoff. Partitioning is a tradeoff. Caching is a tradeoff. Streaming is a tradeoff. Eventual consistency is not a magic phrase that makes correctness problems disappear.
There is no "just use Kafka." There is no "just shard it." There is no "just cache it." There is no "just make it eventually consistent." There is no "just" in distributed systems.
Security Engineering
Ross Anderson
Security gets taught too narrowly. Some people reduce it to cryptography. Some reduce it to pentesting. Some reduce it to compliance, vulnerability scans, IAM policy, secret rotation, or whatever tool the security team bought this year.
That is not enough. Security is adversarial system design.
This book earns a spot because it treats security as a broad engineering discipline. Threat models, incentives, protocols, hardware, software, economics, human behavior, fraud, abuse, and failure modes.
For infrastructure engineers, this matters because security is not something you bolt on after the system exists. Identity, access, isolation, secrets, trust boundaries, auditability, encryption, supply chain, network exposure, tenancy, and operational procedures are architecture decisions.
If you do not design with those things in mind, you are not going to fix it all later with a scanner and a policy engine.
Site Reliability Engineering
This is where technical foundation turns into production discipline.
SRE is not "the team that owns the alerts." It is not "ops with a new title." It is not "people who write Terraform and get paged." The useful parts are bigger than that.
Reliability is a product feature. Risk has to be managed, not wished away. SLOs give teams a language for tradeoffs. Error budgets connect reliability to product velocity. Toil destroys engineering capacity. Monitoring should answer user-impact questions. Automation should reduce operational entropy. Incidents should produce learning, not blame.
This book belongs near the end because it connects the technical layers to operational judgment. It also helps correct one of the industry mistakes that still drives me nuts: treating devops like a job title instead of a set of practices, interactions, feedback loops, and cultural changes.
Kubernetes: Up and Running
Kelsey Hightower, Brendan Burns, Joe Beda, and Lachlan Evenson
I went back and forth on this one. A tool-specific book in a foundation library is risky. Most tool books age badly. Some are just expanded documentation. Some teach commands without teaching the model. That is exactly the garbage I am trying to avoid here.
Kubernetes earns the spot because it is not just a tool in the usual sense. It is a meeting point for a pile of older ideas: Linux, networking, storage, scheduling, declarative configuration, reconciliation loops, service discovery, identity, isolation, and reliability patterns.
That is also why it should come late. If someone starts with Kubernetes before understanding the foundations, it turns into YAML ritual. They memorize object types. They copy Helm values. They restart pods. They cargo-cult probes. They misread resource requests and limits. They confuse deployment with availability. They treat deployment tooling like an operational strategy.
Once the foundation is there, Kubernetes looks a lot less magical. Pods are process boundaries. Services are networking abstractions. Controllers are reconciliation loops. Deployments are rollout strategy. Probes are failure signals. Requests and limits are scheduling and isolation inputs. ConfigMaps and Secrets are configuration distribution. Ingress is L7 routing. RBAC is authorization. Admission control is policy enforcement.
Kubernetes is built out of older ideas. That is why it belongs at the end, not the beginning.
Why This Matters
Modern engineering is mostly abstraction layered on top of older foundations. That is not an insult. Good abstractions are useful. They let us move faster, build larger systems, and stop solving the same low-level problems over and over again. The mistake is pretending the abstraction erased the older discipline.
Containers packaged up Linux isolation into a cleaner model. Cloud moved infrastructure behind APIs, quotas, managed services, billing models, regional boundaries, control planes, and provider-specific failure modes. Managed databases hide some operational pain, but indexes, transactions, replication, durability, backups, query behavior, and consistency still matter.
Queues and streaming platforms expose teams to ordering, delivery guarantees, backpressure, retries, replay, idempotency, partitions, consumer lag, and schema evolution. Observability platforms provide more telemetry than ever, but telemetry without a model just produces prettier confusion. Infrastructure as code makes state, dependency graphs, drift, lifecycle management, and provider APIs part of the workflow. Deployment platforms give us better ways to express rollout, promotion, rollback, drift detection, and desired state, but they do not remove the need to understand release engineering.
Security tooling is the same story. Scanners, policies, SBOMs, secrets managers, and identity providers help. They do not replace threat modeling, trust boundaries, least privilege, abuse cases, and operational discipline.
The pattern is everywhere. The modern tool gives you leverage. The foundation tells you what that leverage is actually doing.
Without the foundation, engineers learn interfaces instead of systems. They know which manifest to edit, which dashboard to open, which command to run, or which button to press, but they struggle when the failure crosses a boundary.
That is the reason I care about this list. Not because every engineer needs to become a specialist in every layer. Because every serious engineer eventually has to reason across layers.
The Short Version
If I had to make the compact list, it would be this:
The Linux Command Line by William Shotts
How Linux Works by Brian Ward
Computer Networking: A Top-Down Approach by James Kurose and Keith Ross
Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau
The Linux Programming Interface by Michael Kerrisk
Systems Performance by Brendan Gregg
Designing Data-Intensive Applications by Martin Kleppmann and Chris Riccomini
Security Engineering by Ross Anderson
Site Reliability Engineering by Google
Kubernetes: Up and Running by Kelsey Hightower, Brendan Burns, Joe Beda, and Lachlan Evenson
There it is. Not a certification path. Not a trophy shelf. Not a list of whatever tool is fashionable this year. A foundation.
Because once you understand the substrate, the tools stop looking like magic.
-Villain