Revision · Networking for DevOps

Part 2 traces a single request from https://app.example.com to your code and back, built lowest layer first. Its throughline is that the same diagram doubles as a debugging runbook: when the site is down, walk the chain until you find the broken link.

What this part covered

• The network stack (TCP/IP) — independent layers (Application → Transport → Internet → Link) where IP addresses and CIDR subnets route to a machine, TCP gives reliable ordered delivery via the SYN/SYN-ACK/ACK handshake, UDP trades reliability for low overhead, and MTU mismatches make “small requests work, big uploads hang.”
• DNS — the distributed, cached, hierarchical phone book that turns names into IPs so services can move; A/AAAA/CNAME/MX/TXT/NS records and TTL matter, and lowering TTL before a migration keeps propagation lag to minutes — “it’s always DNS.”
• HTTP & TLS — a stateless request/response language (methods with idempotency, 2xx–5xx status codes where 502/503 point at the load balancer) wrapped by TLS for encryption, integrity, and CA-signed authentication; one lapsed certificate is a total self-inflicted outage, so rotation via certbot/cert-manager is non-negotiable.
• Ports & firewalls — IP:port routes bytes to the right process; binding 0.0.0.0 versus 127.0.0.1 decides exposure, NAT shares one public IP, and the governing rule is default-deny — open only 443 and maybe 22, as the GitHub 1.35 Tbps memcached amplification showed.
• Security groups vs iptables — enforce firewall rules as stateful, default-deny Infrastructure as Code at the cloud edge rather than drifting per-host iptables.
• Load balancing & proxies — a load balancer is a reverse proxy that makes many identical instances look like one service; L4 versus L7, round-robin/least-connections/IP-hash algorithms, and automatic GET /healthz checks replace the human SSHing in to pull a dead node.
• TLS termination — terminate certificates once at the proxy and forward plain HTTP internally, so rotation happens in one place instead of on every instance.
• Service discovery — the keystone that answers “where is service X right now?” automatically via register/health/lookup, over DNS names or a registry (Consul, etcd), so autoscaling, self-healing, and zero-downtime deploys work when addresses change constantly.

The takeaway

By the end you can trace a request URL-to-response-and-back and know exactly which layer to suspect when something breaks. Service discovery — finding things whose addresses never stop moving — is the bridge into containers, where a fleet of short-lived processes makes that problem the norm rather than the exception.