Part 2 · Networking for DevOps

In Part 1 we made one machine do useful work — processes, files, services, logs. But almost nothing in production runs on one machine talking only to itself. A user’s browser talks to a load balancer, which talks to your app, which talks to a database, which talks to a cache, across hosts, racks, datacenters, and continents. The network is the substrate everything else sits on. Get it wrong and your app is unreachable, slow, or quietly leaking data — and the symptoms rarely point at the real cause.

This part answers one deceptively simple question: how does a request from a user actually reach your code, and how does the reply get back? We’ll build the answer the way we build everything here — in dependency order, lowest layer first, so each page only uses ideas already covered.

Why a DevOps engineer must know this

You don’t need to be a network engineer. But you will spend real hours of your career staring at “connection refused,” “503 Service Unavailable,” an expired certificate, or a DNS change that hasn’t propagated — and every one of those is a networking problem wearing an application’s clothes. The recurring thread of this book is what manual, error-prone step does this remove — and how does it make production safer? Networking is where that thread gets sharp: the difference between “I SSH’d in and edited a config by hand” and “the load balancer health-checked the bad node out automatically” is the difference between an outage and a non-event.

This also makes the Fallacies of Distributed Computing concrete. The network is reliable. Latency is zero. The network is secure. Topology doesn’t change. Every one of those is true on a single laptop and false the instant a network is involved. The rest of this part is, in a sense, the bill for distributing your system.

The path of a single request

Here is the whole journey at a glance. Each box is a page in this part.

   You type https://app.example.com  in a browser
        |
        v
   [ DNS ]   name  ->  IP address          (which machine?)
        |
        v
   [ TCP/IP ]   open a connection          (a reliable pipe)
        |
        v
   [ Ports / Firewall ]   :443 allowed?    (may I even knock?)
        |
        v
   [ TLS ]   prove identity, encrypt       (is this really them?)
        |
        v
   [ HTTP ]   GET /  ->  200 OK            (the actual request)
        |
        v
   [ Load Balancer / Proxy ]  pick a healthy backend
        |
        v
   [ Service Discovery ]  where are the backends right now?
        |
        v
   your app  ->  response  ->  back up the whole chain

Read it top to bottom and you have the table of contents. Read it bottom to top and you have a debugging runbook: when “the site is down,” you walk the chain until you find the broken link.

The roadmap

We’ll take that path one layer at a time.

1. The Network Stack (TCP/IP) — the layered model, IP addresses and subnets, TCP vs UDP, the three-way handshake, and the packets everything is made of. The foundation every other page stands on.
2. DNS — turning app.example.com into an IP address: record types, resolvers, caching, and TTL. Also the single most common cause of outages, so we treat it with respect.
3. HTTP & TLS — the request/response protocol the web runs on (methods, status codes, headers), and the encryption layer that makes it HTTPS: certificates, certificate authorities, and why rotation matters.
4. Ports & Firewalls — how a process claims an address to listen on, how NAT lets many machines share one public IP, and how default-deny firewalls expose only what’s needed.
5. Load Balancing & Proxies — spreading traffic across many copies of your app, health-checking the bad ones out, and the L4-vs-L7 and forward-vs-reverse proxy distinctions that confuse everyone at first.
6. Service Discovery — the problem of finding services that move: how do components locate each other when addresses change constantly? This is the bridge into Containers and Orchestration with Kubernetes.

How to read this part

Networking rewards hands-on poking more than almost any other topic, because the tools are right there on every Linux box. Throughout, we’ll lean on a small kit you can run yourself:

ping example.com        # is the host reachable at all?
dig example.com         # what IP does the name resolve to?
curl -v https://example.com   # walk the whole HTTP+TLS handshake, verbosely
ss -tlnp                # what's listening on this machine, on which ports?

Type the commands

Reading about a three-way handshake is fine; watching one in curl -v makes it permanent. Keep a terminal open as you read. Every page ends with commands you can run on your own laptop — and the laptop itself is a full TCP/IP host, so almost everything works locally.

By the end you’ll be able to trace a request from URL to response and back, and — more importantly — know exactly which layer to suspect when something breaks.

Check your understanding

1. Why does a DevOps engineer need networking knowledge even without being a network engineer? Give a concrete failure that looks like an app bug but is really a network problem.
2. Put these in the order a request encounters them: TLS, DNS, HTTP, TCP, load balancer. Why is the order forced rather than arbitrary?
3. The path-of-a-request diagram doubles as a debugging tool. Explain how you’d use it when someone reports “the site is down.”
4. State the recurring thread of this book in your own words, and give one networking example of a manual, error-prone step that automation removes.
5. Which fallacy of distributed computing does “I hard-coded the database’s IP address” violate, and which later page in this part addresses it?

Show answers

1. Most outages that look like application bugs are really networking problems — “connection refused,” an expired TLS certificate, a 503, or a DNS change that hasn’t propagated. You don’t need to design networks, but you’ll spend real hours diagnosing them, so you need to recognize the layer at fault.
2. DNS → TCP → TLS → HTTP → load balancer (name resolves to an IP, a connection opens to it, TLS secures the channel, HTTP carries the request, then the balancer picks a healthy backend). The order is forced because each layer depends on the one beneath it: you can’t open a TCP connection without an IP, and you can’t speak HTTP before the encrypted channel exists.
3. The diagram is a debugging runbook read as a chain — walk it link by link (is the name resolving? is the port reachable? is the cert valid? is the balancer returning a healthy backend?) until you find the first broken link, instead of guessing.
4. The thread: what manual, error-prone step does this remove, and how does it make production safer? A networking example: a load balancer health-checking a bad node out automatically replaces a human SSHing in to pull it from rotation by hand.
5. It violates “topology doesn’t change.” Addresses move constantly in a real system, and Service Discovery is the page that solves finding services whose addresses change.