We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
At 2:47am on February 28, 2017, an Amazon S3 engineer ran a command to remove a small number of servers from a subsystem used by the S3 billing process. A typo in the command removed a much larger set of servers than intended. The result was a four-hour outage that took down a significant portion of the internet, including Slack, Trello, and the AWS service health dashboard itself.
The command was typed by hand. There was no code review, no plan output, no diff to approve. A human typed a dangerous command into a terminal, made a mistake, and the blast radius was the entire Eastern US.
Infrastructure as code exists so that infrastructure changes go through the same review process as application code. You write the desired state in a file. A tool computes the diff between what exists and what you want. A reviewer reads the diff. Only after approval does the tool apply the change. The review is the safety net.
Traditional infrastructure management is imperative. You tell the system what to do, step by step. "Create this VPC. Attach this subnet. Open this port. Launch this instance." If step 3 fails, you are in an undefined state. If you run the script again, it might create duplicates.
Infrastructure as code is declarative. You describe what you want to exist. "I want a VPC with these subnets, these security groups, and these instances." The tool figures out what needs to change to reach that state from the current state. Running it twice produces the same result.
| Aspect | Imperative (Scripts) | Declarative (IaC) |
|---|---|---|
| Style | "Create X, then modify Y" | "X should exist with these properties" |
| No, re-running creates duplicates | Yes, re-running changes nothing if already correct | |
| Diff before apply | No, you run it and hope | Yes, the plan shows exactly what will change |
| Rollback | Undo scripts (if they exist) | Revert the code, apply again |
| Drift detection | Not possible without extra tooling | Built in, just run plan against production |
| Review process | Review a shell script | Review a plan diff that lists every resource affected |
HashiCorp , Pulumi, and AWS CDK are the three dominant tools. Terraform uses HCL (a domain specific language). Pulumi uses TypeScript, Python, or Go. AWS CDK uses TypeScript or Python and compiles to CloudFormation. The syntax differs, but the workflow is identical: code, plan, review, apply.