After 14 years in production DevOps and training 400+ engineers, I just launched my most advanced bootcamp to date. 28 weeks. 56 live classes. DevOps + MLOps + AIOps. Built for experienced engineers who want to move into MLOps and AIOps without faking it on their resume. Check it out 👇 livingdevops.com/courses/28-… Launch offer: up to 30% off if you book by 15th June.

Terraform is great. Until you have to run it across three environments. You write the code once. Then you copy it for staging. Then again for prod. It feels clean at first. Each environment has its own folder, its own state, its own everything. A few months later, you fix a bug in dev and forget staging. Someone patches prod during a late-night hotfix. A one-line change becomes three PRs. And nobody can explain why prod behaves differently. The problem is no longer writing Terraform. The problem is keeping the same Terraform in sync across environments. The approach I have found useful is simple: Keep one codebase. Move the differences into config. terraform/ ├── modules/ ├── main.tf ├── variables.tf └── vars/ ├── dev.tfvars ├── dev.tfbackend ├── prod.tfvars └── prod.tfbackend The code defines the infrastructure. The .tfvars define the environment. The .tfbackend defines where the state lives. Fix something once, and it's fixed everywhere. The only pain left was the flags: terraform init -backend-config=vars/prod.tfbackend terraform plan -var-file=vars/prod.tfvars Every single time. For every environment. And one wrong filename away from planning prod with dev values. That is why I built Toffee. Instead of remembering flags, you just say which environment: toffee dev plan toffee prod apply It does not replace Terraform. It does not add a new layer to learn. It just removes the repetitive part. That is how I think infrastructure tooling should work. Less copy-paste. Fewer flags to remember. More time building infrastructure. It's open source; try it and tell me what's missing: github.com/akhileshmishrabiz…

We should start writing our docs in YAML. AI agents are reading them anyway. At least we’ll save some tokens. 😂

The Kubernetes trap about being "Production ready"

Why do Terraform docs still exist when no one is reading them anymore?

- One guy collaborates with a billionaire to create OpenAI for the welfare of humans. - As soon as the project starts getting traction, he turns it into for-profit. Gets billions of dollars in investment to build AGI. That's the pitch. - Tells the world humans are not needed, they can duck off. - Sees big competition from China building competitive models. - Then his AI models hack Hugging Face( basically orchestrated) - Now he yells out "wolf is coming" and urges everyone to slow down AI model improvement. - Launches his newer models within weeks. - Now going to the Senate to give a speech on safety. Is this concern for humanity or just a smart business move?

Kubernetes has started to become Jenkins for containers I know a lot of people run clusters that have more CRDs than pods. Every operator promises to make your life easier. Cert management, Ingress, eso, argocd, service mesh, CNPG, and list goes on and on. Each one solves a real problem on its own. But When stack ten of them together, You’re not running Kubernetes anymore. You’re running a distributed system of controllers reconciling other controllers.😀😀 And then comes the Kubernetes upgrade. Now you have to worry about operator versions, CRD compatibility, dependencies and whether that project is still maintained. Jenkins didn’t die because plugins were bad. It died because nobody owned the plugin list. Kubernetes operators are heading the same way I mean, how many plugins and operators is too many before it becomes unmanageable dependency hell?

Agentic AI interview question: An agent can refund up to ₹10,000 automatically but needs approval above that. Where would you enforce this rule: the prompt, model, tool, or backend?

Before you learn Terraform, understand why to learn Terraform. Or should you? Around 2006, AWS emerged and changed everything. For the first time, you could spin up a server in minutes with a few clicks. No $50,000 hardware. No weeks of setup. Just click, click, done. Pay only for what you use. Scale on demand. Microsoft launched Azure. Google launched GCP. Cloud computing was born. For startups, this was revolutionary. Launch without buying a single server. But a new problem emerged. Managing 5 servers manually? Easy. Managing 500 servers across multiple environments? Nightmare. You'd log into the AWS console. Click to create a server. Select instance type. Choose network. Configure security groups. Add storage. Click, click, click, submit. Need the same setup in staging? Repeat all those clicks. Production? Repeat again. One wrong click and your production looked nothing like staging. "It works in staging" became the new "it works on my machine." Disaster recovery was a joke. Your infrastructure got deleted? Good luck remembering every single configuration you clicked through. No documentation. No history. No way to track who changed what and when. Configuration drift was constant. Three environments that should be identical gradually became completely different. Nobody knew why. Want to recreate your infrastructure? Better hope someone documented every single step. Spoiler: nobody did. Scaling was painful. Black Friday coming? Start clicking to provision servers two weeks early. One by one. Teams worked in silos. Ops managed infrastructure through console clicks. Developers had zero visibility. Compliance audits were nightmares. "Show us all infrastructure changes from last quarter." Impossible. This is exactly what Infrastructure as Code solved. The idea was simple. Stop clicking. Start coding. Define your infrastructure in code files. Version control them. Deploy infrastructure the same way you deploy applications. AWS built CloudFormation for AWS. Azure built ARM templates for Azure. Google built Deployment Manager for GCP. Better than clicking. But there was a problem. Different syntax for each cloud. Want to use AWS and Azure? Learn two completely different tools. Different commands. Different workflows. Organizations were adopting multi-cloud strategies. Using AWS for compute. GCP for machine learning. Azure for enterprise apps. Managing three different IaC tools was still painful. Then came Terraform in 2014. HashiCorp saw the gap. They built one tool that works with all clouds. Same syntax. Same workflow. Whether you're on AWS, Azure, GCP, or even managing GitHub repositories. Write once. Deploy anywhere. Terraform used HCL (HashiCorp Configuration Language). Simple. Readable. Declarative. You describe what you want, not how to create it. Built in Go. Fast. Reliable. Creates resources in parallel. But here's what made Terraform win: it was cloud-agnostic when everyone else was cloud-specific. Your infrastructure became code. Track changes in Git. Review in pull requests. Roll back when needed. Recreate entire environments in minutes. No more clicking. No more guessing. No more drift. Why did Terraform win? Perfect timing. Cloud adoption was exploding. Multi-cloud was becoming the norm. Companies needed one tool to manage infrastructure across all clouds. Terraform solved that exact problem. It's idempotent. Run the same code 100 times, get the same result. It's modular. Reuse code across projects. It manages state. Knows what exists and what needs to change. 12 years later, Terraform is the de facto standard for IaC. Now Terraform skills are in massive demand. Senior DevOps engineers with Terraform expertise command premium salaries. Understanding this story is more important than memorizing terraform commands. Now go learn Terraform already.

Most Kubernetes engineers don't know these kubectl tricks that save hours during outages 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗲𝘃𝗲𝗻𝘁𝘀 -𝗔 -𝘄 | 𝗴𝗿𝗲𝗽 -𝘃 "𝗡𝗼𝗿𝗺𝗮𝗹" --> Watch only the bad stuff across the entire cluster > It streams warnings and failures from every namespace in real time so you can catch issues before they turn into incidents. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗱𝗶𝗳𝗳 -𝗳 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁.𝘆𝗮𝗺𝗹 --> See exactly what will change before applying > It helps catch accidental changes like wrong image tags, deleted environment variables, or broken resource limits before deployment. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗽𝗼𝗱𝘀 -𝗔 --𝘀𝗼𝗿𝘁-𝗯𝘆='.𝘀𝘁𝗮𝘁𝘂𝘀.𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝗦𝘁𝗮𝘁𝘂𝘀𝗲𝘀[𝟬].𝗿𝗲𝘀𝘁𝗮𝗿𝘁𝗖𝗼𝘂𝗻𝘁' --> Find unstable pods instantly > This sorts pods by restart count so the most unstable workloads appear first. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝘁𝗼𝗽 𝗽𝗼𝗱𝘀 -𝗔 --𝘀𝗼𝗿𝘁-𝗯𝘆=𝗺𝗲𝗺𝗼𝗿𝘆 --𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀 --> Find who is actually consuming memory > The `--containers` flag breaks usage down per container instead of showing only pod-level metrics. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗱𝗲𝗯𝘂𝗴 -𝗶𝘁 <𝗽𝗼𝗱-𝗻𝗮𝗺𝗲> --𝗶𝗺𝗮𝗴𝗲=𝗯𝘂𝘀𝘆𝗯𝗼𝘅 --𝗰𝗼𝗽𝘆-𝘁𝗼=𝗱𝗲𝗯𝘂𝗴-𝗽𝗼𝗱 --> Debug a pod without touching the original workload > This creates a copy of the failing pod with a debug container attached for investigation. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗽𝗼𝗱𝘀 -𝗔 -𝗼 𝘄𝗶𝗱𝗲 --𝗳𝗶𝗲𝗹𝗱-𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿 𝘀𝗽𝗲𝗰.𝗻𝗼𝗱𝗲𝗡𝗮𝗺𝗲=<𝗻𝗼𝗱𝗲-𝗻𝗮𝗺𝗲> --> See every workload sitting on a node before you touch it > Run this before cordoning or draining a node during maintenance. 𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗲𝘃𝗲𝗻𝘁𝘀 --𝗳𝗶𝗲𝗹𝗱-𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿 𝗶𝗻𝘃𝗼𝗹𝘃𝗲𝗱𝗢𝗯𝗷𝗲𝗰𝘁.𝗻𝗮𝗺𝗲=<𝗽𝗼𝗱-𝗻𝗮𝗺𝗲> --𝘀𝗼𝗿𝘁-𝗯𝘆='.𝗹𝗮𝘀𝘁𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽' --> Get the full chronological event history for one object. > kubectl describe only shows recent events. This pulls the complete timeline for a specific pod, useful when you're trying to reconstruct what happened over the last hour.