It's Sept 2, 2026. Starting today, I'll be investing more on my Personal branding. I will be taking more time on X and other online platforms. So for new people here or seeing me for the first time, here's a bit about me 👇👇 I’m Srinivas Karnati, a DevOps Engineer turned Sales Engineer / Forward Deployed Engineer, working at the intersection of engineering, AI, and enterprise adoption. I kinda work with enterprises to know their technical and business challenges, design solutions around their existing environments, and help them move from PoC to production. My work spans AI workflows, cloud infrastructure, DevOps, observability, application deployments, and enterprise integrations. Over past years, I’ve worked with teams to deploy applications across enterprises, build and improve CI/CD and cloud infrastructure, troubleshoot production systems, and design solutions that actually scale. With the current AI age, I’ve been helping enterprises adapt their engineering and business workflows for AI, identifying where AI and agentic workflows can create real value, integrating them into existing systems, and helping teams deploy and operate them reliably in production.

Your pod says "Running" but the app is down. Running doesn't mean ready to serve requests. One place to look: readiness vs liveness probes. Readiness asks: should this pod get traffic? A failed check marks it not ready. Normal Service traffic stops going to it, but the container isn't restarted. Liveness asks: does this container need a restart? After the configured number of consecutive failures, the kubelet restarts it. Two mistakes worth avoiding: - No readiness check: traffic can reach an app before it's ready. - Overly strict liveness checks: a slow-starting app can get stuck restarting. Slow to boot? Use a startup probe with enough time for startup. Readiness and liveness checks wait until it succeeds. Readiness controls traffic. Liveness controls restarts. Which has bitten you more: missing readiness checks or an over-eager liveness probe? #Kubernetes #DevOps #SRE

Getting agents to work in a demo is one thing. But making it reliable enough for people to use every day in an enterprise environment is another. I worked with orgs to build cloud infrastructure and CI/CD for enterprise environments earlier. Now, as a forward-deployed engineer, I work with enterprises to take solutions from understanding the problem to running them in production. For me, that means a few practical questions: - Can the solution connect to the tools and data the team already uses? - How can we determine whether its answers and actions are correct? - Can it access only the data it's allowed to use? - Can we be able to figure out what happened when something goes wrong? - Who fixes it, and can we undo a bad change? A demo/PoC shows what's possible. Production means people can rely on it for their daily work. If you've taken agentic systems from a demo to production, what was the hardest part?

Disaster Recovery & Business Continuity: Most teams pick a DR strategy before they know their numbers. It works better the other way around. Sketch 1: the four classic DR strategies - Backup & Restore, Pilot Light, Warm Standby, and Multi-Site (Active-Active) - and the core trade-off: faster recovery and lower data loss cost more. Sketch 2: the metrics that drive the decision: - RPO: how much data you can afford to lose - RTO: how long you can be down - MTD: the maximum tolerable downtime - the real deadline - WRT: catch-up time after systems are back - MTTR & MTBF: and how they add up to the availability "nines" Rule of thumb: agree RPO and RTO with the business first. The strategy picks itself after that. #DevOps #SRE #SystemDesign #DisasterRecovery #BusinessContinuity

Working as an FDE is cool.

This is how your production EKS cluster should look like 👇👇 VPC • Multiple AZs • Private subnets for nodes • Public subnets only for load balancers EKS Control Plane • Managed by Amazon Elastic Kubernetes Service • Endpoint access restricted Worker Nodes • Managed Node Groups • Spread across multiple AZs Networking • Amazon VPC CNI • AWS Load Balancer Controller for ALB/NLB • Security Groups for Pods when needed Ingress • Application Load Balancer for HTTP services • Network Load Balancer for TCP workloads Autoscaling • Cluster Autoscaler or Karpenter • Horizontal Pod Autoscaler Security • IAM Roles for Service Accounts (IRSA) • Pod Identity • Secrets stored in AWS Secrets Manager with KMS • Network policies enabled Observability • Metrics → Amazon Managed Service for Prometheus • Logs → Amazon CloudWatch • Tracing → AWS X-Ray Reliability • Multi-AZ node groups • Pod disruption budgets • Readiness & liveness probes Storage • Amazon EBS via CSI driver • Amazon S3 for object storage Deployment • GitOps via Argo CD

Should we start a Badminton Community?

++++++++

So what is a "Harness"? LangChain gave a simple and great definition for agents and harness: Simply stating , "Agent = Model + Harness" "If you're not the model, you're the harness." A "Harness" is everypeice of code, tool scripts, loops, enforcements, policies, and execution logic that basically is not the "Model". A "Model" alone is nothing, and we cannot call it an agent unless it has things like state, tool execution, feedback loops, retry logic, policies, enforceable constraints, execution logic, etc. And all these extra things apart from the model are "Harness"

Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once. An application can be concurrent but not parallel, which means that it processes more than one task at the same time, but no two tasks are executing at the same instant. An application can be parallel but not concurrent, which means that it processes multiple sub-tasks of a task on a multi-core CPU at the same time. An application can be neither parallel nor concurrent, which means that it processes all tasks one at a time, sequentially. An application can be both parallel and concurrent, which means that it processes multiple tasks concurrently in multi-core CPU at the same time.

GOATed Advice,