Akhilesh Mishra

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-wee… Launch offer: up to 30% off if you book by 15th June.

Amazon EKS finally supports Kubernetes version rollbacks, and now I'm not scared of EKS upgrades anymore. For years, EKS upgrades felt like defusing a bomb blindfolded. You test in staging. You cross your fingers. You upgrade prod. And if something breaks, there's no undo button. You're rebuilding the cluster at 2 AM while your team pretends to sleep. That fear had a cost. Teams sat 2-3 versions behind. Not because they were lazy. Because they were scared. Fear is expensive in engineering. It just doesn't show up on the invoice. Here's what changed. EKS now lets you roll back a version upgrade within 7 days. No rebuild. No war room. No "we'll do it next quarter" excuse. Upgrades stop being a once-a-year, hold-your-breath event. They become routine. Boring, even. Which is exactly what infrastructure should be. If you're still running an outdated cluster because upgrades scare you, you got a safety net now.

Kubernetes makes much more sense if you stop thinking like an engineer and start thinking like a founder running a company. Every company has two types of people. Management. They don't do any real work. Their only job is to make sure the company runs smoothly. Employees. They do the actual work. Kubernetes is built the same way. Control plane. Nodes. Control plane is your management. It does zero work itself. Nodes are your employee floor. This is where the real work happens. Let's open up the control plane first. First thing here is API server. Think of it as the front desk of the company. Every request goes through this guy first. No exceptions. It's the single point of communication for the whole cluster. Before it lets you say anything, it checks two things. First, are you even allowed inside. That's authentication. Second, are you allowed to do this specific thing. That's authorization. You don't pass one of them, you get nothing. Not even a "no." Next is the controller. Think of one guy sitting with a dashboard, watching everything happen across the company. If a client wants 20 units of work running, controller's job is simple. Make sure 20 are running. All the time. But this guy can't remember everything on his own. He needs a record of what's going on everywhere. That's etcd. Every job, every status, every current state of the cluster lives here. Controller checks etcd constantly to know what's actually happening. Once controller knows what needs to be done, he doesn't do it himself. He calls the scheduler. Scheduler's whole job is finding who has capacity and handing them the work. That's your full control plane, right there. API server does the gatekeeping. Controller decides what needs to happen. Etcd remembers everything. Scheduler decides who picks it up. Now the work lands on the nodes. But a raw VM can't just join and start working. Same as any new employee, it needs onboarding first. Every node needs three things before it can join the cluster. First is kubelet. Kubelet is what makes you compatible with Kubernetes. No kubelet, no talking to the control plane. Simple as that. If your node won't join the cluster, check kubelet first. Almost always the problem. Second is your container runtime. Usually containerd. Kubelet gets you in the door. Containerd is your actual skill. It's what lets the node run containers at all. Third is kube-proxy. This enables communication across nodes. Not the nodes talking to each other exactly, but the workloads on them. Without it, a container on one node has no way to reach a container on another. Now here's the part that trips people up. Kubernetes never runs a raw container. Ever. It wraps every container inside something called a pod. Think of a pod as a wrapper around your container. Your most fundamental unit in Kubernetes. You can run more than one container in a pod, but you'll only ever run one application container per pod. Never put front end and back end in the same pod. If that pod dies, you lose both. And you lose the ability to scale them separately. Pods are built to die. That's not an accident, that's the design. They're disposable by nature. But a dead pod doesn't come back on its own. Something has to watch it and keep the right number alive. That's your deployment. Think of deployment as a team lead who was told: I want 3 people on shift, always. Someone leaves, the lead replaces them. Fast. You don't manage pods directly in production. You manage deployments, and deployments manage the pods for you. Every time a pod restarts, it gets a brand new IP. Point your users at a pod's IP and the moment it dies, they're stuck talking to nothing. So you don't point users at pods. You point them at a service. Think of it like a group chat for your pods. Doesn't matter who exactly replies, as long as someone healthy in the group does. User hits the service. Service routes traffic to whichever pod is alive right now. That's the whole architecture. API server is your front desk. Controller is your dashboard guy. Etcd is your company memory. Scheduler assigns the work. Kubelet, containerd and kube-proxy are onboarding for every single node. Pod is your workstation. Deployment is your team lead. Service is the group chat that never goes down, even when the people in it do. You're just telling one of these guys what to do.

Case Study: How I Saved $1,000/Month by Automating AWS RDS Migration with Python A client reached out with a simple question: Can you help us reduce our cloud spending on RDS? I looked around their RDS setup and found a few RDS instances with over-provisioned storage. This made me want to look around other instances, too. I wrote a Python script to analyze storage across all databases. Generated an Excel report showing allocated vs used storage. We found - One database: 600GB allocated, only 80GB used, another: 400GB allocated, 120GB used. - Some databases: 500GB+ extra space unused, others: 200GB+ wasted storage They had allocated "just in case" instead of actual needs We calculated the overspending of $1,000+ per month across all accounts. You might say, What's the problem? Just update the storage to the appropriate value. Actually, AWS doesn't let you reduce RDS storage. You can't shrink it or restore from a snapshot with less space. The only solution was to create a new RDS with smaller storage and migrate manually. To do this manually for 100+ RDS instances, it would take 1 month. So I decided to show off my Python skills and build an elaborate Python automation. I built the script that - Pull the details about the RDS instance - Create a duplicate instance with exact same configuration, with a new allocated storage value. - Backed up the older instance with pg_dump - Restore with pg_restore - Swap instances by renaming - Stop the old instance I Dockerized the automation and deployed it as an ECS task, triggered by a Lambda function. But there was a problem: pg_dump/pg_restore were too slow for 500GB+ databases. And it needed a longer downtime window. So I ditched pg_dump/pg_restore and switched to pgsync as it allowed a faster, live migration. Flow: Lambda → ECS → Python script → Migration → Savings Outcome: - Reduced storage waste by 60% - Saved $1,000+ monthly ($12,000+ annually) - Zero downtime (well, almost zero ) - 5 days for complete development/testing/deployment - Fully automated - Showed off this as a reusable asset(companies love this word) This is why Python is essential for DevOps. You can't solve complex cloud problems with bash scripts or CLI commands. It lets you build intelligent automation that saves real money.

@SomayagiAdhitya Thank you

@livingdevops Wel documented bro

BACKSTAGE is the new KUBERNETES

Nobody wakes up and says, "Today I want to learn Kubernetes." They wake up because something is broken. Applications are crashing. Deployments take forever. Scaling is painful. Developers keep saying, "It works on my machine." People think Kubernetes is the solution. It isn't. Kubernetes is the answer to a problem that started almost 20 years ago. Let me tell you the story. Back then, companies bought physical servers. You waited weeks for hardware. Installed the operating system. Configured everything by hand. Copied the application. Installed dependencies. Then someone changed one small configuration. Everything broke. Then came virtual machines. Great improvement. Resource utilization became better. But every VM still needed its own operating system, its own configuration, its own dependency management. The pain never disappeared. Then containers arrived. For the first time, developers could package the application with everything it needed. Now the application behaved the same everywhere. One huge problem solved. Then another problem appeared. How do you run thousands of containers? How do you restart failed ones? How do you scale them automatically? How do you deploy new versions without breaking production? That's the problem Kubernetes actually solved. This is why I always tell people... Don't start by memorizing Pods, Deployments, Services, or Ingress. Start with the pain. Because once you understand why Kubernetes exists, every object inside Kubernetes suddenly makes sense. The biggest mistake I see people making is learning Kubernetes like they're preparing for an exam. Production doesn't ask exam questions. Production asks questions like: "Why did this deployment fail?" "Why is latency suddenly high?" "Why did only one availability zone go down?" "Why did autoscaling make things worse?" Those questions are never answered by memorizing YAML. They're answered by understanding systems. Technology changes every few years. The problems don't. That's why you need to first understand why before what and how. Because tools come and go. Good engineers solve problems. That's the skill that stays valuable.

@proxy_vector Kubernete should only be used to solve a problem that cannot be solved by simpler setup

@livingdevops Exactly. Kubernetes is a coordination layer, not a cure. If the team does not already need scheduling, isolation, and repeatable deploys at that scale, it mostly adds ceremony.

@vivek_naskar Take breaks from the constant pressure of being on top of everything. I am enjoying the partial break from social content and it feels great. I go 2-3 days without posting anything and i don’t mine it. I had burned out in past year with way too much work

What do you do to avoid burnouts?

@devops_nk bhut shi, bhut shi. congratulations

Career Update: Excited to share that I've joined Accenture as a DevOps Engineer. A new chapter begins, and I'm looking forward to learning, contributing, building amazing things, and making the most of this opportunity at Accenture. After 1 year of continuous grinding: - 25+ interviews - 200+ job applications - Countless sleepless nights - Daily studying after work - Weekend Hands-on Practice I finally made my first switch with a 150% hike. One thing I learned from this journey: You don't need 100 perfect interviews. You only need one good interview. - Keep studying. - Keep applying. - Keep showing up. I'm grateful for the incredible 3.5 years at Infosys, where I learned, grew, and built a strong foundation in DevOps. Now it's time for a new chapter, and I'm excited to contribute, learn, and build impactful things at Accenture. Many of you kept asking which company I was joining, so here it is. 😄 I started this X account simply to share my learning while preparing for a switch, hoping it would keep me consistent. I never imagined it would not only help me land my next opportunity but also grow such an amazing community. Thank you all for the constant support, motivation, and encouragement throughout this journey. 🙏 I'll continue sharing everything I learn along the way. The journey is just getting started.

@ingodwetryst @ThePrimeagen @nikitabier When the creator is in the video isn't it obvious), does it need credit? when people post movie clips, do they give credit to movie actor on x?

@livingdevops @ThePrimeagen @nikitabier You gotta give credit in the OP, that's all.

Vibe coders everyday struggle in 15 seconds.

Dear Devops engineers, you are not just Devops engineer. You can also be - SRE - Platform engineers - Telemetry engineers - Cloud engineers - Mlops engineers - AIOps engineers - DevSecOps engineers

@Im_IrushiK Nostalgia hit

Just installed Linux for the first time. What should I do next ?

@vivek_naskar perfect choice for breakfast on Sunday

I had a late breakfast. It was incredibly heavy — Benne Masala Dosa. I'm already feeling under the weather today, and after having this, I'm feeling even more drowsy. This thing is basically a sleeping pill. P.S. there goes my diet. Eating oats in the morning is so boring.