Devops Concepts

Idempotency

Running an operation multiple times should give the same result.

Run → Same Result
Run → Same Result
Run → Same Result  ...

Why it matters: Makes automation safe and repeatable. If a Terraform apply, an Ansible playbook, or a Kubernetes reconcile loop isn't idempotent, re-running it after a partial failure can leave the system in a worse or inconsistent state instead of just "catching up" to the desired state.

Drift

Actual state of a system diverges from the desired state.

Desired State  ≠  Actual State

Why it matters: Drift creates bugs, security risks, and unpredictable infrastructure. A classic cause: someone SSHes into a server and manually changes something instead of going through code — now your IaC no longer describes reality.

Immutable Infrastructure

Don't update servers. Replace them.

Old Server  ✗ →  New Server

Why it matters: Reduces "snowflakes" (servers so hand-tweaked that no one can reproduce them) and eliminates "works on my machine" problems, since every deployment starts from the same known-good image.

Desired State

You declare how the system should be. The system keeps it that way.

You Declare (Desired) → System Works to Achieve It

Why it matters: Foundation of Kubernetes, Terraform, Ansible, and more. You stop scripting how to get there step by step, and just describe what "there" looks like.

Reconciliation

The system continuously checks and fixes differences to reach the desired state.

Actual → Reconcile Loop → Desired

Why it matters: Keeps your system self-healing. This is the mechanism behind Kubernetes controllers — they don't run once, they loop forever, constantly nudging actual state back toward desired state.

Blue-Green vs Canary

Blue-GreenCanarySwitch traffic all at onceSend traffic to a small group firstblue ⇄ greensmall subset → gradually expand

Why it matters: Both reduce deployment risk. Use based on your system — blue-green gives instant rollback via traffic switch; canary limits blast radius by only exposing a fraction of users to a new version first.

Push vs Pull Deployments

PushPullYou push changes to serversServers pull changes from a repo

Why it matters: Pull is more secure and scalable — the server initiates the connection (no inbound access needed into your infra), and it naturally supports large fleets pulling on their own schedule instead of a central system pushing to everyone at once.

Ephemeral Infrastructure

Infra is temporary and created on demand, then destroyed.

Create → Use → Destroy

Why it matters: Lower cost, less risk, more agility. Nothing sticks around long enough to drift, accumulate cruft, or become a pet.

Configuration Drift

Changes made manually on servers outside of your code.

Code (Git)  ≠  Server (Manual)

Why it matters: Hard to track, easy to break. Automate everything — if a change didn't go through code, it shouldn't exist on the server.

Toil

Manual, repetitive, boring tasks that don't add business value.

Why it matters: Kills productivity. Automate it! Frees humans for high-value work — this is a core SRE concept (Google's SRE book defines it explicitly, tied to capping toil at a percentage of an engineer's time).

Infrastructure as Code (IaC)

Manage and provision infra using code, not manual clicks.

Code (IaC) → Infra

Why it matters: Versioned, repeatable, and scalable. The only way to go — this is the practice that Terraform, CloudFormation, Pulumi, and Ansible all exist to support.