Managing Physical Servers
Before the cloud, servers were expensive physical machines that lived for years — sometimes decades. You didn't replace them when something went wrong; you fixed them. A sysadmin would log in, tweak a config file, and move on. The problem: if you had 50 servers, you had to remember to make that same change on all 50. Miss one, and you had a server behaving differently from the rest — a condition called configuration drift.
Configuration Management (CM) tools like Puppet (2005), Chef (2009), and SaltStack (2011) were built to solve this. Their core promise: describe the desired state of a server in code, and the tool will continuously enforce that state. If someone manually changes a config file, the CM tool will overwrite it at the next check-in. This property is called convergence — the system always converges toward the declared state.
These tools were designed for a world of long-lived servers — what the industry calls "Pets". Pets have names (web-01, db-primary), are carefully maintained, and are never deleted if you can help it. Modern cloud engineering favors "Cattle" — anonymous, disposable servers that are replaced rather than repaired. When a cattle server misbehaves, you terminate it and launch a fresh one from a known-good image. This is called Immutable Infrastructure.
Despite the industry shift toward immutable patterns, you will encounter Chef, Puppet, and Salt in virtually every enterprise environment. Legacy CM codebases can represent years of institutional knowledge — 50,000 lines of Puppet manifests encoding every compliance rule, every tuning parameter, every security baseline. Understanding how these tools work is the prerequisite to modernizing them safely.
Key Point: Legacy CM tools excel at managing "Pets" (long-lived servers that must be kept in sync over time). Modern infrastructure treats servers as "Cattle" (disposable and replaceable). The migration path between these two models is the core skill this lesson teaches.