DEV Community: Srinivasaraju Tangella

DevOps 2.0: From Automated Pipelines to Autonomous Agents

Srinivasaraju Tangella — Sat, 29 Aug 2026 06:51:50 +0000

Welcome to Agentic DevOps
For years, DevOps has been about one powerful idea:
Automate everything that can be automated.
We created CI/CD pipelines.
We automated infrastructure with Terraform.
We packaged applications with Docker.
We orchestrated workloads with Kubernetes.
We monitored systems with Prometheus and Grafana.
We built GitOps workflows.
But there is still a fundamental limitation:
Most DevOps automation waits for us to tell it what to do.
A pipeline executes predefined steps.
A script executes predefined commands.
A monitoring system detects a problem and sends an alert.
An engineer investigates.
An engineer decides.
An engineer executes the fix.
An engineer verifies the result.
What if we could change that?
What if the DevOps system could understand the situation, reason about it, create a plan, execute the plan, verify the result, and learn from the outcome?
That is the idea behind:
Agentic DevOps
From Automation to Autonomy
Traditional automation looks like this:
Human
↓
Automation
↓
Action
↓
Result
For example:
CPU > 80%
↓
Run restart script
↓
Restart service
The logic is predefined.
Agentic DevOps is different:
┌──────────────┐
│ Signals │
│ Logs/Metrics │
│ GitHub/Cloud │
└──────┬───────┘
↓
┌──────────────┐
│ Agent │
│ Understand │
│ Reason │
│ Plan │
└──────┬───────┘
↓
┌──────────────┐
│ Tools │
│ GitHub │
│ Kubernetes │
│ AWS/Linux │
└──────┬───────┘
↓
┌──────────────┐
│ Execute │
└──────┬───────┘
↓
┌──────────────┐
│ Verify │
└──────┬───────┘
↓
┌──────────────┐
│ Learn │
└──────────────┘
The important difference is:
Automation follows instructions.
An agent pursues an objective.
Imagine This Incident
Imagine your production application suddenly becomes slow.
Traditional DevOps might work like this:
Prometheus
↓
Alert
↓
PagerDuty
↓
Engineer
↓
Investigation
↓
Diagnosis
↓
Fix
↓
Verification
Now imagine an Agentic DevOps system.
It receives:
"Production API latency has increased significantly."
The agent investigates:
Check CPU
Check memory
Check disk
Check network
Check application logs
Check recent deployments
Check Kubernetes events
Check Git commits
Check database metrics
It discovers:
Latency increased
↓
No CPU saturation
↓
No memory pressure
↓
Recent deployment detected
↓
New version introduced
↓
Specific API endpoint became slow
↓
Logs show database query latency
The agent now has context.
It creates a plan:

Compare current version with previous version
Inspect database-related changes
Validate hypothesis
Recommend rollback
Execute rollback only if policy permits
Monitor recovery
Verify latency
Document incident That is no longer simple automation. That is reasoning-driven operations. Agentic DevOps Is Not "ChatGPT for DevOps" This distinction is extremely important. An AI chatbot can tell you: "Your Kubernetes pod may be failing because of insufficient memory." An Agentic DevOps system should be able to: Observe ↓ Understand ↓ Reason ↓ Plan ↓ Ask for permission if required ↓ Execute ↓ Verify ↓ Record outcome The difference is the action loop. A useful mental model is: Agentic DevOps = Observe + Reason + Plan + Act + Verify + Learn The Six Capabilities of an Agentic DevOps System
Observe The agent needs visibility. It can consume signals from: GitHub CI/CD Kubernetes AWS Linux Prometheus Grafana Logs Traces Security scanners Incident systems Without observation, an agent is essentially blind.
Understand Raw telemetry is not enough. Suppose the agent receives: CPU = 91% Memory = 87% Pod restarts = 12 Deployment = 8 minutes ago The agent needs to understand the relationship between these signals. It should ask: What changed? When did it change? What systems are affected? Is this a symptom or the root cause? This is where contextual reasoning becomes important.
Reason This is where Agentic DevOps becomes interesting. Instead of: IF CPU > 80 THEN restart server the agent evaluates multiple possibilities. For example: Possible causes:

A. CPU saturation
B. Memory pressure
C. Recent deployment
D. Database latency
E. Network problem
F. External dependency
It gathers evidence.
Then it ranks the hypotheses.
Hypothesis Confidence

Recent deployment 82%
Database regression 74%
CPU saturation 21%
Network issue 8%
Now the system is not merely executing a rule.
It is investigating a problem.

Plan
Once the agent understands the problem, it creates a sequence of actions.
For example:
Plan:
Inspect deployment diff
Compare application versions
Check affected endpoint
Validate database query latency
Determine rollback safety
Roll back if policy permits
Monitor recovery
This is fundamentally different from a fixed pipeline.
A traditional pipeline says:
"Run these steps."
An agent says:
"Achieve this objective."
Act
Agents need tools.
An Agentic DevOps system might have tools such as:
GitHub Tool
Kubernetes Tool
AWS Tool
Linux Tool
Prometheus Tool
Grafana Tool
Terraform Tool
Jenkins Tool
Security Tool
The agent decides which tool is appropriate.
For example:
Agent
↓
"Check Kubernetes deployment"
↓
Kubernetes Tool
↓
Deployment information
↓
Agent reasoning
This is where the boundary between AI reasoning and deterministic engineering tools becomes extremely important.
The AI should not randomly execute shell commands.
The agent should operate through controlled tools with permissions and policies.
Verify
This is one of the most important capabilities.
A dangerous automation system says:
"I executed the command."
A reliable agent says:
"I executed the action and verified that the desired state was achieved."
For example:
Rollback
↓
Pods restarted
↓
Health checks passed
↓
Error rate decreased
↓
Latency returned to normal
↓
Rollback verified
Only then should the agent consider the operation successful.
Memory Changes Everything
Imagine an agent that remembers previous incidents.
Incident #1:
Database connection pool exhausted
Incident #2:
Same application
Same endpoint
Similar symptoms
The agent can compare historical context.
Current incident
↓
Historical incidents
↓
Similar pattern found
↓
Previous solution identified
↓
Validate before execution
Memory transforms an agent from:
"AI that can reason"
into:
"An operational system that becomes increasingly context-aware."
Guardrails Are Mandatory
This is where Agentic DevOps must be treated differently from simple automation.
You should never give an AI unlimited production access.
Instead:
Agent
↓
Policy Engine
↓
Permission Check
↓
Tool
↓
Action
For example:
Low-risk
Read logs
Read metrics
Inspect GitHub issues
Analyze deployments
Generate reports
The agent can perform these automatically.
Medium-risk
Restart application
Scale deployment
Create pull request
Modify configuration
Require policy checks or approval.
High-risk
Delete infrastructure
Drop database
Modify production networking
Rotate critical credentials
Require explicit human approval.
This leads to an important principle:
Autonomous does not mean uncontrolled.
Modern agentic systems are increasingly emphasizing guardrails, security, observability, and human review rather than unrestricted autonomy.
Agentic DevOps Architecture
A practical architecture could look like this:
┌───────────────────────┐
│ Signals │
│ │
│ GitHub │
│ Kubernetes │
│ AWS │
│ Prometheus │
│ Logs │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Agentic Brain │
│ │
│ Context │
│ Reasoning │
│ Planning │
│ Decision Making │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Policy │
│ Guardrails │
│ Permissions │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Tools │
│ │
│ GitHub API │
│ Kubernetes API │
│ AWS APIs │
│ Linux commands │
│ Observability APIs │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Actions │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Verification │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ Memory │
│ History / Outcomes │
└───────────────────────┘
This architecture is not science fiction.
Cloud-native projects and platforms are already exploring agents that interact with Kubernetes, Prometheus, Istio, Argo and other operational systems.
Traditional DevOps vs Agentic DevOps
Traditional DevOps
Agentic DevOps
Rule driven
Goal driven
Predefined workflow
Dynamic planning
Human investigates
Agent investigates
Human decides
Agent can recommend/decide
Automation executes
Agent selects tools
Alerts humans
Investigates incidents
Stateless automation
Context + memory
Fixed paths
Adaptive paths
Execute
Execute + verify
Human-centric
Human + agent collaboration
But this does not mean traditional DevOps disappears.
Quite the opposite.
Agentic DevOps needs the foundations created by DevOps:
Linux
+
Networking
+
Cloud
+
Containers
+
Kubernetes
+
CI/CD
+
GitOps
+
Observability
+
Security
+
AI Agents
Without strong engineering foundations, an agent simply becomes a very intelligent system operating on a poorly understood environment.
The Future DevOps Engineer
The DevOps engineer of the future may spend less time typing commands and more time designing:
Agent capabilities
Tool interfaces
Policies
Guardrails
Memory
Observability
Evaluation
Reliability
Human approval workflows
Instead of asking:
"How do I manually fix this?"
the engineer increasingly asks:
"How do I teach the system to safely detect, reason about, fix, and verify this class of problems?"
That is a very different engineering mindset.
But There Is a Big Problem
Giving an agent the ability to act introduces new risks.
What happens if the agent misunderstands the problem?
What happens if the agent chooses the wrong tool?
What happens if its reasoning is incorrect?
What happens if an attacker manipulates the context?
What happens if the agent performs a destructive action?
What happens if two agents make conflicting decisions?
These are not just AI questions.
They are engineering, security, reliability, and governance questions.
CNCF's emerging work on cloud-native agentic standards explicitly highlights security, observability, availability, interoperability, and governance as important concerns.
Therefore:
The more autonomous the system becomes, the stronger the engineering controls must become.
Agentic DevOps Is a Journey
We don't need to jump directly to a fully autonomous production engineer.
A safer evolution looks like this:
Level 1
AI Assistant
↓
Level 2
AI Advisor
↓
Level 3
AI Investigator
↓
Level 4
AI Planner
↓
Level 5
AI Executor with Approval
↓
Level 6
Bounded Autonomous Agent
↓
Level 7
Multi-Agent Autonomous Operations
Each level increases autonomy.
Each level also requires stronger:
Security
Policies
Observability
Testing
Evaluation
Auditability
Human oversight
The Real Definition
So, what is Agentic DevOps?
I would define it this way:
Agentic DevOps is the evolution of DevOps from predefined automation toward intelligent, goal-driven systems that can observe environments, reason about problems, plan actions, use controlled tools, execute changes, verify outcomes, and learn from operational experience.
Or, more simply:
DevOps automates the work.
Agentic DevOps gives the automation a reasoning and decision-making loop.
The Question We Should Be Asking
The question is no longer:
"Can AI write my DevOps scripts?"
The more interesting question is:
"Can we build a DevOps system that understands its environment, reasons about problems, takes controlled action, verifies the result, and continuously improves?"
That is the real promise of Agentic DevOps.
And perhaps the future looks like this:
Yesterday

Human
↓
Tools
↓
Automation
↓
Infrastructure

Today

Human
↓
DevOps Platform
↓
Automation
↓
Infrastructure

Tomorrow

Human
↓
Agentic DevOps
↓
Reason
↓
Plan
↓
Policy
↓
Tools
↓
Act
↓
Verify
↓
Learn
↺
The future of DevOps may not be about writing more automation.
It may be about building systems capable of safely deciding what automation should happen next.
Welcome to Agentic DevOps.
Final Thought
AI will not eliminate the need for strong DevOps engineers.
It will increase the value of engineers who understand:
systems + software + cloud + automation + AI + security + reliability.
The next generation of DevOps will not simply build pipelines.
They will build intelligent systems that operate those pipelines.
And that is where Agentic DevOps begins.
Author: Srinivasa Raju Tangella

Monitoring Fundamentals for DevOps Engineers: Metrics, Logs, Alerts, Prometheus, Grafana & Observability

Srinivasaraju Tangella — Mon, 17 Aug 2026 06:57:41 +0000

If you don't know what is happening inside your infrastructure and applications, you are not really operating them — you are guessing.

Modern applications run across cloud infrastructure, containers, Kubernetes clusters, databases, microservices, load balancers, and external services.

When something goes wrong in production, a DevOps engineer should be able to answer questions like:

Is the server healthy?
Is the application available?
Are requests becoming slower?
Are errors increasing?
Is the database overloaded?
Are Kubernetes pods restarting?
Is the infrastructure running out of resources?
Which service is causing the problem?
Did something change before the problem started?

This is where monitoring and observability become fundamental DevOps skills.

What Is Monitoring?

Monitoring is the continuous collection and analysis of information about infrastructure, applications, and services.

A simple way to think about monitoring is:

System
↓
Metrics / Logs / Events
↓
Collection
↓
Storage
↓
Visualization
↓
Alerting
↓
Engineer
↓
Action

The goal is not simply to create dashboards.

The real goal is:

«Detect problems early, understand their impact, and respond before they become major incidents.»

What Should a DevOps Engineer Monitor?

Monitoring can be divided into several important areas.

Infrastructure Monitoring

For Linux servers, EC2 instances, VMs, and physical servers, monitor:

CPU utilization
Memory utilization
Disk utilization
Disk I/O
Network traffic
Network errors
Load average
Filesystem usage
Processes
System uptime

For example:

EC2 Server

CPU = 92%
Memory = 88%
Disk = 91%
Load = 8.5
Network = 850 Mbps

This immediately tells us that the server may be under significant pressure.

Application Monitoring

Infrastructure can be healthy while the application is completely broken.

Therefore, application monitoring is equally important.

Monitor:

Request count
Response time
Latency
Error rate
HTTP 4xx errors
HTTP 5xx errors
Timeouts
Application exceptions
Thread count
JVM heap
Garbage collection
Database connection pools

Example:

Requests = 10,000/min
Average latency = 250 ms
P95 latency = 700 ms
5xx errors = 4%

The server may have only 40% CPU utilization, but users may still be experiencing failures.

Database Monitoring

Databases are often critical bottlenecks.

Monitor:

CPU
Memory
Storage
Connections
Connection pool
Query latency
Slow queries
Locks
Transactions
Replication lag
Connection failures

Example:

DB Connections = 95/100
Slow Queries = 120
Replication Lag = 30 seconds
CPU = 90%

This should immediately attract the attention of the operations team.

Kubernetes Monitoring

For Kubernetes and EKS, monitoring needs to happen at multiple levels.

Think of Kubernetes monitoring like this:

Cluster
↓
Node
↓
Pod
↓
Container
↓
Application

Cluster

Monitor:

Cluster health
Node count
API server
Scheduler
Controller Manager
Resource capacity

Nodes

Monitor:

CPU
Memory
Disk
Disk pressure
Network
Node readiness

Pods

Monitor:

Pod status
CPU
Memory
Restarts
OOMKilled
Pending pods
CrashLoopBackOff

Application

Monitor:

Requests
Latency
Errors
Availability

This layered approach becomes extremely important when troubleshooting production Kubernetes environments.

The Four Golden Signals

One of the most important concepts for DevOps and SRE engineers is the Four Golden Signals.

They are:

Latency
Traffic
Errors
Saturation

Let's understand them.

6.1 Latency

Latency tells us:

«How long does the system take to respond?»

Example:

API Request
↓
Response = 200 ms

Don't look only at average latency.

Important percentiles include:

P50 = 100 ms
P95 = 400 ms
P99 = 1.2 sec

P95 and P99 can reveal slow requests that an average may hide.

Traffic

Traffic tells us:

«How much workload is the system receiving?»

Examples:

Requests/sec
Transactions/sec
Messages/sec
Users/sec

Example:

Normal traffic = 500 requests/sec

Current traffic = 5,000 requests/sec

This could indicate:

Traffic spike
Marketing campaign
DDoS attack
Application bug
Retry storm

Traffic must always be considered in context.

Errors

Errors tell us:

«How many requests are failing?»

Example:

Total requests = 10,000
Failed requests = 500

Error rate = 5%

Monitor:

HTTP 4xx
HTTP 5xx
Timeouts
Exceptions
Connection failures

A sudden increase in HTTP 5xx errors can indicate a serious application or infrastructure problem.

Saturation

Saturation tells us:

«How close is the system to its limit?»

Examples:

CPU = 90%
Memory = 95%
Disk = 92%
DB connections = 98%
Thread pool = 95%

Saturation is extremely important because it can help you detect problems before the system completely fails.

Metrics vs Logs vs Traces

This is one of the most important concepts in modern observability.

Metrics

Metrics are numerical measurements over time.

Examples:

CPU = 80%

Memory = 70%

Requests = 500/sec

Latency = 200 ms

Error rate = 2%

Metrics are excellent for:

Dashboards
Alerts
Trends
Capacity planning

Metrics usually tell you:

«Something is wrong.»

Logs

Logs provide detailed information about events.

Example:

2026-08-17 12:10:01
ERROR PaymentService
Database connection timeout

Logs can help answer:

«What happened?»

For example:

Metric:
5xx errors increased

↓

Log:
Database connection timeout

↓

Root cause:
Database connection pool exhausted

Distributed Tracing

Tracing becomes extremely useful in microservices.

Imagine this request:

User
↓
API Gateway
↓
Order Service
↓
Payment Service
↓
Database

The complete request takes:

Total = 2 seconds

Tracing can show:

API Gateway = 50 ms
Order Service = 300 ms
Payment Service = 1.5 sec
Database = 100 ms

Now we immediately know:

«Payment Service is the major contributor to the latency.»

This is why tracing is especially valuable in distributed systems.

The Four Observability Signals

Modern observability goes beyond basic infrastructure monitoring.

A commonly used model includes:

Metrics
Logs
Traces
Profiles

Metrics provide the high-level picture.

Logs provide detailed event information.

Traces show request flow across services.

Profiles help identify code-level CPU and memory bottlenecks.

The important point is that these signals should not be treated as isolated systems.

You want to correlate them.

For example:

Metric
↓
Latency increased
↓
Trace
↓
Payment Service is slow
↓
Log
↓
Database timeout
↓
Root Cause
↓
Database connection exhaustion

That is the real power of observability.

Monitoring vs Observability

These terms are often used interchangeably, but they are not exactly the same.

Monitoring

Monitoring generally focuses on known questions.

For example:

Is CPU > 80%?

Is disk > 90%?

Is error rate > 5%?

Observability

Observability helps you investigate unexpected behavior and understand the internal state of complex systems from their telemetry.

A useful way to remember it:

Monitoring:
"Something is wrong."

Observability:
"Something is wrong.
Where is it?
Why is it happening?
What changed?
Which services are affected?"

Modern distributed systems make this distinction increasingly important.

Prometheus

Prometheus is one of the most important open-source tools for DevOps monitoring.

A simplified architecture is:

Linux Server
↓
Node Exporter
↓
Prometheus
↓
PromQL
↓
Grafana

Prometheus collects and stores time-series metrics.

For example:

CPU
Memory
Disk
Network
Application metrics
Kubernetes metrics

What Is an Exporter?

An exporter exposes metrics that Prometheus can collect.

For Linux:

Linux Server
↓
Node Exporter
↓
Prometheus

Node Exporter can expose system-level metrics such as:

CPU
Memory
Filesystem
Disk
Network
Load

This gives Prometheus visibility into the server.

What Is PromQL?

PromQL is Prometheus's query language.

It allows engineers to ask questions about metrics.

For example:

CPU utilization

or:

Which servers have high CPU?

or:

What is the request rate?

or:

What is the error rate over the last 5 minutes?

PromQL is therefore a critical skill if you want to become strong in Prometheus-based monitoring.

What Is Grafana?

Grafana is used to query, visualize, explore, and alert on observability data.

A typical dashboard might look conceptually like:

+----------------------------------+
| Production Dashboard |
+----------------------------------+

CPU 72%
Memory 68%
Disk 81%

Requests/sec 850
Error Rate 0.5%
P95 Latency 320 ms

Active Pods 24
Pod Restarts 3
DB Connections 72%

Grafana dashboards allow engineers to see system behavior at a glance.

What Is Alerting?

A dashboard tells you what is happening.

An alert tells you:

«Something needs attention.»

For example:

IF disk_usage > 80%
FOR 10 minutes

THEN

Generate alert

A typical flow might be:

Prometheus
↓
Alert Rule
↓
Alertmanager
↓
Email / Slack / PagerDuty / SNS
↓
DevOps Engineer

Avoid Bad Alerts

Consider this alert:

CPU > 80%

This could create many unnecessary alerts.

CPU might temporarily reach 80% during a legitimate workload spike.

A better rule could be:

CPU > 80%
FOR 15 minutes

Even better, consider the user impact:

High CPU
+
High latency
+
Increasing error rate

This gives you stronger evidence that there is an actual service problem.

Grafana's dashboard guidance similarly recommends focusing alerts on symptoms/user impact rather than simply alerting on every underlying cause.

A Real Production Scenario

Imagine your users report:

«"The application is very slow."»

Don't randomly SSH into servers.

Use a systematic approach.

Step 1 — Check availability

Is the application UP?

Step 2 — Check traffic

Did traffic suddenly increase?

Step 3 — Check latency

P95 = ?
P99 = ?

Step 4 — Check errors

4xx = ?
5xx = ?
Timeouts = ?

Step 5 — Check infrastructure

CPU
Memory
Disk
Network

Step 6 — Check Kubernetes

Pod restarts
OOMKilled
Pending pods
Node pressure

Step 7 — Check database

Connections
Slow queries
CPU
Locks
Latency

Step 8 — Check traces

Find which microservice is taking the most time.

Step 9 — Check logs

Find the detailed error.

Step 10 — Find the root cause

For example:

Traffic spike
↓
More requests
↓
Payment Service overloaded
↓
Thread pool exhausted
↓
Requests waiting
↓
Latency increased
↓
Timeouts
↓
HTTP 5xx
↓
Users experienced failures

This is how monitoring becomes a troubleshooting tool, not just a dashboard.

A Practical DevOps Monitoring Architecture

A typical environment could look like:

                   USERS
                     |
                     ↓
              Load Balancer
                     |
                     ↓
               Kubernetes
                     |
      +--------------+--------------+
      |              |              |
      ↓              ↓              ↓
   Service A      Service B      Service C
      |              |              |
      +--------------+--------------+
                     |
              Metrics / Logs / Traces
                     |
      +--------------+--------------+
      |              |              |
      ↓              ↓              ↓
 Prometheus         Loki        OpenTelemetry
      |              |              |
      +--------------+--------------+
                     |
                     ↓
                   Grafana
                     |
                     ↓
                 Alerting
                     |
         +-----------+-----------+
         |                       |
       SNS                     Slack

Grafana can connect to multiple data sources and visualize metrics, logs, traces, and other data from a unified interface.

What Should You Learn as a DevOps Engineer?

I recommend learning monitoring in this order:

Linux monitoring ↓
Infrastructure metrics ↓
Application metrics ↓
Logs ↓
Alerting ↓
Prometheus ↓
PromQL ↓
Grafana ↓
Alertmanager ↓
JVM monitoring ↓
Kubernetes monitoring ↓
EKS monitoring ↓
Distributed tracing ↓
OpenTelemetry ↓
SLI / SLO / SLA ↓
Incident response ↓
SRE practices

The Most Important Mental Model

Whenever you troubleshoot production, ask these questions:

Is the system available?
↓
Is it fast?
↓
Is it failing?
↓
Is it reaching its limits?
↓
Where is the problem?
↓
Why is it happening?
↓
What changed?
↓
What should we do?

This progression takes you from basic monitoring toward observability and SRE.

Final Takeaway

Monitoring is not:

Install Prometheus
+
Install Grafana
+
Create dashboards

That is only the tooling.

Real monitoring means understanding:

Infrastructure
+
Applications
+
Databases
+
Kubernetes
+
Metrics
+
Logs
+
Traces
+
Alerts
+
Troubleshooting
+
SRE practices

The ultimate objective is simple:

«Know that something is going wrong before your users tell you — and have enough information to understand why.»

That is what separates a DevOps engineer who merely operates tools from an engineer who can actually operate production systems.

What's Next?

This article establishes the fundamentals.

The next practical step is to build a complete monitoring lab:

AWS EC2
↓
Node Exporter
↓
Prometheus
↓
Grafana
↓
CPU / Memory / Disk / Network
↓
PromQL
↓
Alert Rules
↓
Alertmanager
↓
SNS / Email

Then extend the same architecture to:

Spring Boot
↓
Actuator
↓
Prometheus
↓
Grafana

Kubernetes / EKS
↓
kube-state-metrics
↓
Prometheus
↓
Grafana

That progression will take you from monitoring fundamentals → production monitoring → Kubernetes monitoring → observability → SRE.

Introducing InfraAgent by Vithiq AI: Building an Autonomous Infrastructure Intelligence Assistant with Python, FastAPI, Ollama & Linux Subtitle

Srinivasaraju Tangella — Tue, 21 Jul 2026 18:14:22 +0000

🚀 Introducing InfraAgent by Vithiq AI

Every infrastructure engineer has asked these questions at some point:

Why is my Linux server slow?
Which process is consuming all the CPU?
Why is memory usage increasing?
Why is disk space suddenly full?
Why is my Docker container restarting?
Why is my Kubernetes Pod stuck in CrashLoopBackOff?
What exactly happened?
Finding these answers often means running dozens of Linux commands, searching through logs, correlating metrics, and relying on years of operational experience.
I wondered:
What if AI could understand infrastructure the way an experienced Linux and DevOps engineer does?
That idea led me to build InfraAgent.
Meet InfraAgent

InfraAgent is an AI-powered infrastructure assistant developed under the Vithiq AI platform.
It combines Linux system intelligence, Python automation, FastAPI, and a local Large Language Model (Ollama + Llama 3.2) to transform raw infrastructure data into meaningful operational insights.
Instead of simply showing command outputs, InfraAgent explains what they mean and suggests what to do next.

The Vision

Infrastructure is becoming increasingly complex.
Today's engineers manage:
Linux Servers
Docker
Kubernetes
AWS
Azure
Google Cloud
CI/CD Pipelines
Observability
Security
Platform Engineering
The amount of operational data grows every day.
InfraAgent's mission is simple:
Turn infrastructure data into actionable intelligence.

What Makes InfraAgent Different?

Instead of asking engineers to interpret hundreds of lines of command output, InfraAgent works like an experienced infrastructure engineer.
It follows a simple workflow:
Observe

↓

Analyze

↓

Explain

↓

Recommend

↓

Automate
Current Architecture

             User

               │

               ▼

          FastAPI API

               │

               ▼

         InfraAgent

               │

  ┌────────────┴────────────┐

  ▼                         ▼

Linux Commands Ollama (LLM)

  │                         │

  └────────────┬────────────┘

               ▼

      Intelligent Explanation

Technologies Used

Python
FastAPI
Ollama
Llama 3.2
Linux
REST APIs
Pydantic
Subprocess
Prompt Engineering
Current Capabilities
InfraAgent can already analyze Linux systems using real system commands.
Current modules include:

Memory Intelligence

Collects memory information using Linux commands and explains:
Memory utilization
Swap usage
System health
Optimization recommendations

CPU Intelligence

Instead of relying on a single command, InfraAgent combines multiple Linux utilities:
uptime
mpstat
nproc
lscpu
This provides a concise CPU snapshot that allows the AI to analyze:
CPU utilization
Load average
Core count
Architecture
Performance bottlenecks

Why Multiple Linux Commands?

Production AI agents should never depend on a single command.
Instead of:
top
InfraAgent collects focused information from specialized tools.
uptime

↓

mpstat

↓

nproc

↓

lscpu

↓

Combined Report

↓

AI Analysis
This produces cleaner inputs and more accurate AI reasoning.

What Happens Internally?

When you ask:
Analyze my CPU usage
InfraAgent performs the following steps:
Question

↓

Detect Intent

↓

Run Linux Commands

↓

Collect Metrics

↓

Build AI Prompt

↓

Send to Ollama

↓

Generate Infrastructure Analysis

↓

Return Human-Friendly Explanation

Example

Instead of returning:
free -h

top

lscpu
InfraAgent responds with explanations such as:
Memory utilization is healthy.
CPU load is within acceptable limits.
No immediate performance bottlenecks detected.
Disk usage on /data is approaching capacity.
Monitor the Python process consuming the highest CPU.
This transforms raw command output into operational knowledge.

Roadmap

InfraAgent is only getting started.
Upcoming modules include:
Disk Intelligence
Process Intelligence
Network Intelligence
Log Intelligence
Service Intelligence
Docker Intelligence
Kubernetes Intelligence
AWS Intelligence
Azure Intelligence
GCP Intelligence
Security Intelligence
Cost Optimization
Autonomous Remediation

Long-Term Vision

The ultimate goal is to build a complete AI-powered infrastructure platform.
InfraAgent

                    │

  ┌─────────────────┼──────────────────┐

  ▼                 ▼                  ▼

Linux Agent Docker Agent Kubernetes Agent

  ▼                 ▼                  ▼

AWS Agent Security Agent Cloud Agent

                    ▼

            Autonomous Operations

One intelligent platform capable of understanding your entire infrastructure.

Why I Built InfraAgent

I've spent years working with Linux, DevOps, Cloud, Kubernetes, and Platform Engineering.
One thing became clear:
Infrastructure generates enormous amounts of data, but engineers still spend too much time converting that data into decisions.
InfraAgent is my attempt to bridge that gap using AI.
The goal isn't to replace engineers.
The goal is to give them an intelligent partner that helps them diagnose issues faster, understand systems more deeply, and spend more time building instead of troubleshooting.

What's Next?

This is just the beginning.
The next version of InfraAgent will introduce:
AI Tool Selection
Multi-Agent Architecture
Autonomous Infrastructure Diagnostics
Self-Healing Workflows
Predictive Operations
AI-Powered DevOps & SRE Assistance

Final Thoughts

InfraAgent is more than a Linux assistant.
It's the first step toward an Autonomous Infrastructure Intelligence Platform—one that helps engineers observe, understand, optimize, and eventually automate infrastructure operations with AI.
If you're passionate about AI, Linux, DevOps, Platform Engineering, or Cloud Infrastructure, I'd love to hear your thoughts and ideas.
The journey has just begun. 🚀

I Didn't Follow a Roadmap. I Connected the Dots.

Srinivasaraju Tangella — Sun, 12 Jul 2026 02:02:41 +0000

Most people learn technologies one by one. I wanted to understand how every technology depends on every other technology. That curiosity led me to create this engineering ecosystem.

Introduction
For years, I searched for the perfect roadmap.
Every roadmap looked like this:
Learn Linux
Learn Python
Learn Docker
Learn Kubernetes
Learn AWS
Learn AI

But something was missing.

They teach technologies. They don't teach relationships.
Modern engineering isn't about knowing individual tools.

It's about understanding how everything connects.

That realization inspired me to draw my own architecture—not copied from anywhere, but built from months of observation, learning, and connecting concepts.

This isn't a learning roadmap.
It's a technology ecosystem.

Why Maths?

Most engineers underestimate mathematics.
Mathematics develops:
Logical thinking
Optimization
Probability
Machine Learning
Data Science
Algorithms
Performance Engineering
Maths doesn't directly build software.
It improves how you think.

Why Python?

Python is the bridge.
It connects
AI
ML
Automation
DevOps
Cloud
APIs
Data Engineering
Agentic AI
Python has become the engineering glue of modern software.

Why Java?

Java dominates enterprise software.
It powers
Banking
Telecom
Insurance
Healthcare
Government systems

Understanding Java means understanding enterprise architecture.

Why Linux?
Everything eventually runs on Linux.
Containers
Cloud
Kubernetes
Databases
AI clusters

Production servers
Linux is the operating system behind modern computing.

Why Docker and Kubernetes?

Applications no longer run directly on servers.
They run inside containers.
Docker packages applications.
Kubernetes manages thousands of containers automatically.
Without Kubernetes,
AI platforms
Microservices
Cloud-native applications
cannot scale efficiently.

Why APIs are the Center

Every modern application communicates through APIs.
Python
Java
AI Models
Databases
Microservices
Cloud
Agentic AI
Everything eventually exposes or consumes APIs.
APIs are the language of software communication.

Why Databases Matter

Without data,
AI doesn't exist.
Applications don't exist.
Businesses don't exist.
A modern engineer should understand
PostgreSQL
MySQL
MongoDB
Redis
Each database solves a different problem.

Why Terraform and Ansible?

Infrastructure should be treated like code.
Terraform provisions infrastructure.
Ansible configures infrastructure.
Together they automate cloud operations.

Why Security Covers Everything

Security isn't another phase.
It's part of every phase.
Code
Infrastructure
Containers
Cloud
Kubernetes
APIs
AI
Everything must be secured.

Why PerformanceEngineering
Covers Everything
Performance isn't just testing.
It's engineering.
Questions every engineer should ask:
Can this handle one million users?
Can latency be reduced?
Can cloud costs be optimized?
Can APIs respond under heavy load?
Performance engineering affects every technology.

Why Agentic AI?

We're entering an era where software won't just execute commands.
Software will reason.
Plan.
Observe.
Correct itself.
Collaborate with humans.
Agentic AI will become a standard capability in engineering systems.

Why Forward Deployed Engineer (FDE)?

Many people think an FDE only deploys software.
I see it differently.
An FDE combines:
Software Engineering
DevOps
Cloud
AI
APIs
Security
Performance Engineering
Customer Communication
Production Troubleshooting
Solution Architecture
An FDE doesn't own one technology.
An FDE understands the entire ecosystem.

The Biggest Lesson

I stopped asking:
"What should I learn next?"
Instead, I asked:

"How does this technology depend on every other technology?"

That single question completely changed how I learn.

Final Thoughts

Technology is no longer about mastering isolated tools.
The future belongs to engineers who understand connections rather than components.

Don't build a checklist.
Build an ecosystem in your mind.
That's where real engineering begins.

Finally one statement about my view is

"I don't just learn technologies—I connect them."

AWS July 2026 Outage Explained for DevOps Engineers – Part 2: AWS Global Infrastructure, Control Plane, Data Plane, and Dependency Chains

Srinivasaraju Tangella — Mon, 06 Jul 2026 10:33:49 +0000

Welcome to Part 2 of this series.
In Part 1, we learned:
1.What happened during the AWS July 2026 outage

2..Why the incident was important

3.The difference between Control Plane and Data Plane

4.Why many running applications continued working
Note:
Now let's understand how AWS is built internally and why a problem in one component can affect multiple AWS services.
Note: This article explains AWS architecture concepts and relates them to the July 2026 incident. AWS had reported a multi-service operational issue, but a complete engineering RCA was not yet publicly available at the time of writing. The architecture explanations below are based on publicly documented AWS design principles and common cloud engineering practices.

Why Understanding AWS Architecture Matters

Many engineers think AWS is simply:
EC2
S3
RDS
Lambda
But internally AWS is made of thousands of interconnected services.
Each service depends on many other services.
For example:
Customer

↓

AWS Console

↓

AWS APIs

↓

Authentication

↓

Authorization

↓

Resource Manager

↓

Compute

↓

Storage

↓

Networking
If one foundational service has problems, multiple AWS services may be affected.

AWS Global Infrastructure

AWS infrastructure is organized into multiple layers.
Global Infrastructure

↓

Regions

↓

Availability Zones

↓

Data Centers

↓

Racks

↓

Physical Servers

↓

Hypervisors

↓

Virtual Machines

↓

Applications
Every layer provides redundancy.

Regions
A Region is a separate geographical location.
Examples:
US-East-1
US-West-2
Europe-West
Asia Pacific Regions
Each Region operates independently.
However, some AWS global services interact with multiple Regions.

Availability Zones

Each Region contains multiple Availability Zones.
Example:
US-East-1

├── AZ-A

├── AZ-B

├── AZ-C

└── AZ-D

Each Availability Zone has:
Independent power
Independent cooling
Independent networking
Independent physical security
This helps AWS achieve High Availability.

Inside an Availability Zone

Inside every AZ there are many Data Centers.
AZ

↓

Data Center 1

↓

Data Center 2

↓

Data Center 3
Each Data Center contains:
Thousands of servers
Storage arrays
Network switches
Firewalls
Routers
Load balancers

Physical Server Layer

Every physical server contains:
CPU
RAM
SSD/NVMe Storage
Network Cards
Power Supplies
These physical servers host virtual machines.

Hypervisor Layer

AWS uses a hypervisor to create EC2 instances.
Physical Server

↓

Hypervisor

↓

EC2 Instance A

EC2 Instance B

EC2 Instance C
The hypervisor isolates customers from one another while efficiently sharing hardware.

Control Plane Architecture

Control Plane is the management layer.
It performs operations such as:
Create EC2
Delete EC2
Attach EBS
Modify Security Groups
Create IAM Roles
Launch Auto Scaling Groups
Everything is controlled through AWS APIs.
Customer

↓

AWS Console

↓

AWS API

↓

Control Plane

↓

Infrastructure

Data Plane Architecture
The Data Plane runs your workload.
Example:
Customer

↓

Application Load Balancer

↓

EC2 Instance

↓

Spring Boot Application

↓

Database
The Data Plane handles:
User requests
Business logic
Database queries
API responses

Why Control Plane Problems Don't Always Stop Applications

Suppose your application is already running.
Internet

↓

Load Balancer

↓

EC2

↓

Application
Customers can continue using your application.
However:
Launch EC2

↓

Fails

Attach Volume

↓

Fails

Modify Security Group

↓

Fails
This is because these operations depend on the Control Plane.
Dependency Chains
This is one of the most important concepts in cloud engineering.
AWS services rarely work alone.
Example:
IAM

↓

EC2

↓

EBS

↓

CloudWatch

↓

Auto Scaling
If IAM or another foundational service has issues, many higher-level services may also experience problems.
This is called a dependency chain.

Cascading Failures

Sometimes a single failure spreads across multiple services.
Example:
Infrastructure Component

↓

API Failure

↓

EC2 Management

↓

Auto Scaling

↓

CloudFormation

↓

Customer Deployments
This is known as a cascading failure.
Cloud providers design systems to minimize these effects, but complex dependencies can still create widespread operational issues.
Why Recovery Takes Time
People often ask:
"Why didn't AWS recover immediately?"
Recovery involves much more than restarting servers.
AWS engineers typically verify:
Infrastructure health
Storage consistency
Network stability
API availability
Service dependencies
Customer impact
Only after these checks are completed are services fully restored.

Lessons for DevOps Engineers

During any cloud outage:
Don't assume every service is unavailable.
Distinguish between Control Plane and Data Plane.
Design applications to tolerate temporary API failures.
Use retries with exponential backoff.
Build automation that can recover gracefully from transient errors.
Avoid relying on a single Region for critical workloads.

Key Takeaways
AWS is a layered distributed system.
Every AWS service depends on multiple internal components.
Control Plane manages infrastructure.
Data Plane runs customer workloads.
Dependency chains explain why one issue can affect many services.
Cascading failures are a challenge in large-scale distributed systems.
Understanding these concepts helps DevOps Engineers, SREs, and Solution Architects design more resilient s

AWS July 2026 Outage Explained for DevOps Engineers – Part 1

Srinivasaraju Tangella — Mon, 06 Jul 2026 09:51:34 +0000

Note: AWS has published status updates about the incident, but as of now, a full detailed Root Cause Analysis (RCA) may not yet be available. Where AWS has not officially disclosed details, I'll clearly distinguish between confirmed facts and engineering explanations based on how AWS systems work

AWS July 2026 Outage
Part 1 – Introduction
What happened?

On July 5, 2026, AWS reported an operational issue affecting multiple AWS services.

Customers experienced:
API failures
Increased latency
Console errors
Resource creation failures
Delays in service management
Partial service unavailability

Unlike a complete regional power failure, this incident mainly affected the management layer (Control Plane) of AWS services rather than all running workloads.

Why was this outage important?

AWS operates millions of servers worldwide.
Thousands of companies rely on AWS every second.
Examples include:
Banking
Healthcare
E-commerce
Streaming
Government
AI Platforms
SaaS Companies
Even a short outage can impact millions of users.

What is AWS made of?

AWS isn't one giant computer.
It is built from many layers.
Users

↓

Internet

↓

AWS Edge Network

↓

AWS Region

↓

Availability Zone

↓

Data Center

↓

Rack

↓

Physical Servers

↓

Hypervisors

↓

Virtual Machines

↓

Applications
Each layer depends on the one below it.
AWS Region
Example:
US-East-1

AZ-A

AZ-B

AZ-C

AZ-D
Each Availability Zone has:

Independent power
Independent cooling
Independent networking
Independent storage
This is why AWS advertises High Availability.

What customers noticed

Customers reported things like:
Unable to launch EC2

Console loading slowly

IAM request failed

API timeout

CloudFormation failed

Auto Scaling delayed
Many running applications continued serving traffic, but managing AWS resources became difficult.
Running applications vs AWS management
This is extremely important.

Suppose you already have a Java application.
Internet

↓

Load Balancer

↓

EC2 Instance

↓

Spring Boot

↓

Database

Users may still access the application.
But if you try to:
Launch another EC2
Attach EBS
Modify Security Groups
Create IAM Role
those operations may fail because they rely on the AWS

Control Plane.
Control Plane

Think of it as AWS Management.
Examples:
Create EC2
Delete EC2
Attach Volume
Create IAM User
Start Instance
Stop Instance
Everything is managed through AWS APIs.
Data Plane
This is where your application actually runs.

Example:
Customer

↓

Website

↓

EC2

↓

Spring Boot

↓

Database
If the Data Plane is healthy:
Your application may continue running even if the Control Plane has issues.

Why didn't every website go down?
Because:
Control Plane

↓

Management Operations

NOT

↓

Customer Traffic
Many production applications continued running normally.
The biggest impact was on operations teams trying to manage AWS resources.

Why is US-East-1 special?

US-East-1 is AWS's oldest and busiest Region.
Many AWS internal services and customer workloads depend on it.
When something affects this Region, the impact can spread to multiple AWS services.

Key Lesson from Part 1

The biggest lesson is:

Cloud availability is not just about servers staying online. It's also about the management systems that operate those servers.
Even if your application is healthy, operational tasks can fail if the Control Plane is affected.

Building Reusable Terraform Modules: A Beginner-Friendl usy Guide

Srinivasaraju Tangella — Tue, 23 Jun 2026 01:45:27 +0000

Terraform modules help you avoid repeating code and make your Infrastructure as Code (IaC) reusable, scalable, and maintainable.

What is a Terraform Module

A Terraform module is a collection of .tf files that are grouped together to perform a specific task.

Think of a module like a Java java Terraform
Class Module
MethodParameters Variables
Return Values Outputs
Object Creation. Module Call

Instead of writing the same EC2 code multiple times, you create a module once and reuse it everywhere.

Why Use Modules?

Without Modules

resource "aws_instance" "dev" {
ami = "ami-123456"
instance_type = "t2.micro"
}

resource "aws_instance" "test" {
ami = "ami-123456"
instance_type = "t2.micro"
}

resource "aws_instance" "prod" {
ami = "ami-123456"
instance_type = "t2.micro"
}

Problem:
Duplicate code
Hard to maintain
Error-prone

With Modules

module "dev" {
source = "./modules/ec2"

instance_name = "dev-server"
}

module "test" {
source = "./modules/ec2"

instance_name = "test-server"
}

module "prod" {
source = "./modules/ec2"

instance_name = "prod-server"
}

Benefits:
Reusable
Cleaner code
Easy maintenance
Standardization

Project Structure

terraform-project/
│
├── main.tf
│
└── modules/
└── ec2/
├── main.tf
├── variables.tf
└── outputs.tf

Step 1: Create Module

modules/ec2/main.tf

resource "aws_instance" "server" {

ami = var.ami_id
instance_type = var.instance_type

tags = {
Name = var.instance_name
}
}

modules/ec2/variables.tf

variable "ami_id" {
description = "AMI ID"
}

variable "instance_type" {
description = "EC2 Type"
}

variable "instance_name" {
description = "Server Name"
}

modules/ec2/outputs.tf

output "instance_id" {
value = aws_instance.server.id
}

output "public_ip" {
value = aws_instance.server.public_ip
}

Step 2: Call Module

Root main.tf

provider "aws" {
region = "us-east-1"
}

module "webserver" {

source = "./modules/ec2"

ami_id = "ami-0c02fb55956c7d316"
instance_type = "t2.micro"
instance_name = "dev-webserver"
}

Step 3:InitializeTerraform

terraform init

Output:

Initializing modules...

webserver in modules/ec2
Terraform downloads and prepares the module.

Step 4: Validate

terraform validate
Output:

Success! The configuration is valid.

Step 5: Plan

terraform plan

Output:

aws_instance.server
Terraform shows resources that will be created.

Step 6: Apply

terraform apply
Terraform creates:
EC2 Instance
Tags
Networking attachments

Step 7: Access Module
Outputs

Add to root:

output "instance_ip" {
value = module.webserver.public_ip
}

Apply again:

terraform apply

Output:

instance_ip = 54.x.x.x

Real-Time Enterprise Example

VPC Module
modules/vpc
Creates:
VPC
Public Subnets
Private Subnets
Route Tables
Internet Gateway

EC2 Module

modules/ec2

Creates:
EC2 Servers
Security Groups

RDS Module

modules/rds
Creates:
MySQL Database
DB Subnet Group

Root Module

module "vpc" {
source = "./modules/vpc"
}

module "ec2" {
source = "./modules/ec2"

subnet_id = module.vpc.public_subnet_id
}

module "rds" {
source = "./modules/rds"

subnet_ids = module.vpc.private_subnet_ids
}

Architecture:

Root Module
|
+-- VPC Module
|
+-- EC2 Module
|
+-- RDS Module

Best Practices

1. One Module = One Responsibility

Good:

ec2 module
vpc module
rds module

Bad:

everything module

2. Use Variables

Avoid hardcoding:

instance_type = var.instance_type

3. Expose Only Required Outputs

output "instance_id"

Avoid exposing unnecessary values.

4. Version Control Modules

module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.0.0"
}

Simple Interview Questions

What is a Terraform Module?

A reusable collection of Terraform configurations used to create infrastructure components.

What is the difference between Root Module and Child Module?
Root Module → Main Terraform execution directory.
Child Module → Reusable module called by the root module.

How are values passed into modules?
Using input variables.
Hcl
instance_type = "t2.micro"

How do modules return values?

Using outputs.
Hcl
module.ec2.public_ip

Key Takeaway

Terraform Modules are the foundation of enterprise Infrastructure as Code. They promote reusability, standardization, scalability, and maintainability. In large DevOps environments, teams typically create separate modules for VPC, EC2, EKS, RDS, IAM, Security Groups, and Load Balancers, then assemble them through a root module to build complete cloud platforms.

MLOps and AIOps for Beginners: Build, Deploy, Monitor, and Scale an ML Model on Kubernetes

Srinivasaraju Tangella — Tue, 16 Jun 2026 18:44:52 +0000

Let's build a simple House Price Prediction Model and then see where MLOps and AIOps fit.

Step 1: Business Problem

Suppose a real estate company wants to predict house prices.
Input:
House Size (sqft) Bedrooms
1000 2
1500 3
2000 4
2500 5

Output:
Price

50 Lakhs
75 Lakhs
1 Crore
1.25 Crore
Goal:

House Details ↓ ML Model ↓ Predicted Price

Step 2: Build a Basic ML Model

Using Python and Scikit-Learn:
Python

```from sklearn.linear_model import LinearRegression

X = [
[1000, 2],
[1500, 3],
[2000, 4],
[2500, 5]
]

y = [50, 75, 100, 125]

model = LinearRegression()
model.fit(X, y)

prediction = model.predict([[1800, 3]])
print(prediction)```

What happened?

Training Data ↓ Learning Algorithm ↓ Trained Model

The model learned:

More Size = Higher Price More Bedrooms = Higher Price

Step 3: Save the Model
Python

```import joblib

joblib.dump(model,"house-price-model.pkl")```

Now we have an artifact:



Think of it like:



```Java Source Code
      ↓
mvn package
      ↓
employee-service.jar```



For ML:



```Training Data
      ↓
Model Training
      ↓
house-price-model.pkl```



**Step 4: Deploy Model as API
Using FastAPI:**



```Python
from fastapi import FastAPI
import joblib

app = FastAPI()

model = joblib.load("house-price-model.pkl")

@app.get("/predict")
def predict(size:int,bedrooms:int):
    result=model.predict([[size,bedrooms]])
    return {"price":float(result[0])}```


Now:



```User
 ↓
REST API
 ↓
ML Model
 ↓
Prediction```



**Step 5: Containerize**

Dockerfile:



```Dockerfile
FROM python:3.11

COPY . /app

WORKDIR /app

RUN pip install -r requirements.txt

CMD ["uvicorn","app:app","--host","0.0.0.0","--port","8000"]```



Build:



```docker build -t house-price:v1 .```



Run:



```docker run -p 8000:8000 house-price:v1```



**Step 6: Deploy to Kubernetes
Deployment:**



```YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: house-price
spec:
  replicas: 3
Service:
YAML
apiVersion: v1
kind: Service
metadata:
  name: house-price```



Now:



```Client
   ↓
Service
   ↓
Pods
   ↓
ML Model```



At this point we enter the MLOps world.
Where MLOps Starts
Most beginners think:




```Model Built
   ↓
Job Done```


Reality:

``|Model Built
   ↓
Deploy
   ↓
Monitor
   ↓
Retrain
   ↓
Version
   ↓
Govern```

**MLOps Layer 1 - Versioning**


```employee-service-v1.jar
employee-service-v2.jar```
ML:

```house-model-v1.pkl
house-model-v2.pkl
house-model-v3.pkl```

Need to track:
Dataset version
Code version
Model version
Tools:
Git
MLflow
**MLOps Layer 2 - CI/CD**
DevOps:

```Git Push
 ↓
Jenkins
 ↓
Build
 ↓
Deploy```
MLOps:

```Git Push
 ↓
Training Pipeline
 ↓
Validation
 ↓
Model Registry
 ↓
Deployment```
Pipeline:

```Code
 ↓
Train
 ↓
Test
 ↓
Deploy Model```

**MLOps Layer 3 - Monitoring**

Traditional Monitoring:

```CPU
Memory
Disk
Network```

Tools:
prometheus.io⁠�
grafana.com⁠�
But ML requires more.
Monitor:

```Prediction Count
Model Accuracy
Latency
Failed Predictions```
Example:

```Yesterday Accuracy = 95%

Today Accuracy = 72%```

Alert!
**MLOps Layer 4 - Retraining**
Suppose house prices change.
Old Model:

```2024 Data```
Current Market:

```2026 Data```
Predictions become wrong.
Need:

```New Data
 ↓
Retrain
 ↓
Deploy New Model```

This is a core MLOps responsibility.
**Where AIOps Starts**
Now imagine:

```100 Kubernetes Clusters
500 Nodes
5000 Pods```

Humans cannot analyze everything.
AIOps applies AI to IT Operations.
**Traditional Monitoring**
Prometheus says:

```CPU = 95%```

Engineer investigates.
**AIOps Monitoring**

AI analyzes:

```CPU Spike
+
Memory Spike
+
Deployment Event
+
Application Error```

AI concludes:

```Root Cause:
Deployment version v2.1.3```

and automatically opens a ticket.
**AIOps for Our House Model**

Suppose:

```Prediction Latency Increased```

AIOps engine sees:

```Node CPU 95%
Memory 90%
Model Requests Increased```

AI Recommendation:

```Scale Deployment
From 3 Pods
To 8 Pods```

or

```Rollback Model v3
Deploy Model v2```

**Complete Architecture**

```Data
                   │
                   ▼
           Train ML Model
                   │
                   ▼
            Save Model
                   │
                   ▼
           Docker Image
                   │
                   ▼
             Kubernetes
                   │
                   ▼
            User Requests
                   │
                   ▼
             Predictions
                   │
       ┌───────────┴───────────┐
       ▼                       ▼
    MLOps                 AIOps
(Model Lifecycle)    (Operations Intelligence)

Versioning           Root Cause Analysis
Training Pipelines   Anomaly Detection
Model Registry       Auto Remediation
Retraining           Capacity Forecasting
Monitoring           Predictive Alerts```

**DevOps Engineer Perspective
If you already know:**

Linux
Git
Jenkins
Docker
Kubernetes
Prometheus
Grafana
Terraform
then you're already **70–80% of the way to MLOps.**

You add:
Python
Basic ML
Model Serving
MLflow
Kubeflow

For AIOps, you add:
Log Analytics
Anomaly Detection
AI Agents
Root Cause Analysis
Predictive Operations

This is why many experienced DevOps engineers are moving toward MLOps + AIOps + Agentic AI Operations, because it builds directly on the operational foundation they already have.

AI, Machine Learning, and MLOps Explained for DevOps Engineers

Srinivasaraju Tangella — Tue, 16 Jun 2026 17:35:07 +0000

Introduction

Everywhere you look today, people are talking about AI.

ChatGPT writes content.
GitHub Copilot suggests code.
Netflix recommends movies.
Banks detect fraud automatically.

Behind all of these systems are concepts such as Artificial Intelligence (AI), Machine Learning (ML), and MLOps.

As a DevOps engineer, I kept hearing these terms and wondered:

"Do I need to become a data scientist to understand AI?"

The answer is no.

This article explains AI, Machine Learning, and MLOps from the ground up, using concepts familiar to infrastructure and DevOps engineers

What Is Artificial Intelligence?

Artificial Intelligence (AI) is the ability of a machine to perform tasks that normally require human intelligence.

These tasks include:

Understanding language
Recognizing images
Making decisions
Predicting outcomes
Learning patterns

For example:

When you ask ChatGPT a question and receive an answer, you are interacting with an AI system.

When Google Maps predicts traffic, it is using AI.

When your email automatically detects spam, AI is involved.

Think of AI as the broad field whose goal is making machines behave intelligently.

The Traditional Programming Approach

Before understanding Machine Learning, let's look at traditional software.

As DevOps engineers, we work with applications built using explicit rules.

For example:

Input:

Customer age = 25

Rule:

If age >= 18 → Adult

Output:

Adult

The developer writes every rule manually.

The computer simply follows instructions.

The process looks like this:

Data + Rules = Output

This approach works well when the rules are known.

But what if the rules are too complex?

The Problem Traditional Programming Cannot Easily Solve

Imagine building a system that identifies cats in images.

You could write rules:

Two eyes
Two ears
Whiskers
Tail

But cats appear in thousands of different positions, colors, and lighting conditions.

Writing rules for every possible situation becomes impossible.

This is where Machine Learning enters.

What Is Machine Learning?

Machine Learning (ML) is a subset of Artificial Intelligence.

Instead of giving the computer rules, we give it examples.

For example:

Input:

100,000 images labeled as Cat or Not Cat

Machine Learning Model:

Learns patterns automatically

Output:

Can identify cats in new images

Traditional Programming:

Data + Rules → Output

Machine Learning:

Data + Output → Rules (learned automatically)

This is the biggest mindset shift.

The machine discovers the rules.

What Is a Machine Learning Model?

A Machine Learning Model is the result of training.

Think of it as a package of learned knowledge.

For example:

A house price model learns:

Location affects price
Size affects price
Number of rooms affects price

After training, the model can estimate prices for new houses.

The model is similar to a compiled application artifact.

For developers:

Source Code → Binary

For ML:

Training Data → Model

The model becomes the deployable artifact.

How Machine Learning Works

The lifecycle is usually:

Collect data
Clean data
Train model
Evaluate model
Deploy model
Monitor results

Visually:

Data
↓
Training
↓
Model
↓
Deployment
↓
Predictions

At first glance, this seems simple.

The challenge begins after deployment.

The Hidden Problem

Suppose a data scientist creates a fraud detection model with 95% accuracy.

Everyone celebrates.

The model is deployed.

Three months later:

Customer behavior changes
Fraud patterns evolve
Accuracy drops to 70%

Now what?

Questions appear:

How do we monitor the model?
How do we retrain it?
How do we version it?
How do we roll back?
How do we automate updates?

This is exactly why MLOps exists.

What Is MLOps?

MLOps stands for Machine Learning Operations.

It applies DevOps principles to Machine Learning systems.

The goal is to make ML systems:

Reliable
Repeatable
Scalable
Observable
Automated

In simple words:

MLOps is DevOps for Machine Learning.

Why DevOps Engineers Should Care

Consider what DevOps engineers already do.

We automate:

Builds
Deployments
Monitoring
Scaling
Infrastructure

MLOps introduces new assets:

Datasets
Models
Training pipelines

But the operational mindset remains identical.

Instead of deploying application code only, we deploy:

Application Code + Machine Learning Models

DevOps vs MLOps

DevOps Pipeline:

Code
↓
Build
↓
Test
↓
Deploy

MLOps Pipeline:

Data
↓
Train
↓
Validate
↓
Package Model
↓
Deploy
↓
Monitor
↓
Retrain

Notice how deployment and automation still play a central role.

Where Kubernetes Fits

Many AI systems need:

Scalability
GPU resources
High availability
Automated deployment

This makes Kubernetes a natural platform for ML workloads.

A trained model can be packaged as a container and deployed exactly like a microservice.

This is where DevOps knowledge becomes extremely valuable.

Where Kubeflow Fits

Kubeflow is a Kubernetes-native platform for Machine Learning.

Think of it as:

Kubernetes + Machine Learning Tooling

Kubeflow helps teams:

Run training jobs
Build ML pipelines
Manage notebooks
Deploy models
Automate retraining

It provides the operational layer required for large-scale AI systems.

A Practical Learning Path for DevOps Engineers

Step 1:
Understand AI and ML concepts.

Step 2:
Learn Python basics.

Step 3:
Train simple models using Scikit-Learn.

Step 4:
Expose models through APIs.

Step 5:
Containerize models using Docker.

Step 6:
Deploy models on Kubernetes.

Step 7:
Learn MLflow.

Step 8:
Explore Kubeflow.

Final Thoughts

You do not need a PhD in Machine Learning to enter MLOps.

If you already understand:

Linux
Containers
CI/CD
Kubernetes
Cloud Infrastructure
Monitoring

You already possess many of the skills that production AI systems require.

The biggest challenge is not learning advanced mathematics.

It is understanding how Machine Learning systems are built, deployed, monitored, and maintained in the real world.

That intersection is exactly where MLOps lives.

From DevOps to MLOps: A Practical Roadmap for Infrastructure Engineers

Srinivasaraju Tangella — Tue, 16 Jun 2026 17:14:18 +0000

Introduction

Over the past few years, I've noticed a common question among DevOps engineers:

Do I need to become a Data Scientist to work in AI?

The short answer is no.

Most AI projects don't fail because of machine learning algorithms. They fail because deploying, scaling, monitoring, and maintaining models in production is hard.

That's where MLOps comes in.

If you're already working with Kubernetes, Docker, CI/CD pipelines, cloud platforms, and monitoring tools, you're much closer to MLOps than you might think.

In this article, I'll explain:

What AI, ML, and MLOps actually are
How DevOps skills transfer to MLOps
Where tools like Kubeflow fit in
A practical learning roadmap for beginners

Understanding AI, ML, and MLOps

Think of it this way:

AI is the overall field of creating intelligent systems.
Machine Learning (ML) is a subset of AI where systems learn patterns from data.
MLOps is the discipline of deploying and operating ML systems reliably in production.

A machine learning model may achieve 95% accuracy in a notebook, but without automation, monitoring, versioning, and deployment strategies, it provides little business value.

Why DevOps Engineers Have an Advantage

Most DevOps engineers already know:

Linux
Git
Docker
Kubernetes
CI/CD
Cloud Platforms
Monitoring and Observability

These are also the foundations of modern MLOps platforms.

The main difference is that MLOps introduces new artifacts:

Datasets
Trained models
Feature pipelines
Model metrics

Instead of deploying only application code, you're deploying code plus machine learning models.

DevOps vs MLOps

Traditional DevOps Pipeline:

Code → Build → Test → Deploy

MLOps Pipeline:

Data → Train → Validate → Package → Deploy → Monitor → Retrain

Notice that the operational mindset remains the same.

The complexity comes from managing both software and data.

Where Kubeflow Fits

Kubeflow is essentially a Kubernetes-native platform for machine learning workloads.

It helps teams:

Run training jobs
Build ML pipelines
Manage notebooks
Deploy models
Automate retraining workflows

For DevOps engineers, Kubeflow feels familiar because it builds on Kubernetes concepts such as containers, operators, RBAC, and resource scheduling.

However, I would not recommend learning Kubeflow first.

Learn:

Python basics
ML fundamentals
Model serving with FastAPI
MLflow
Kubernetes deployment

Then move to Kubeflow.

A Practical Learning Path

Month 1:

Python
Pandas
ML fundamentals

Month 2:

Scikit-learn
FastAPI
Build a simple prediction API

Month 3:

Docker
Kubernetes
MLflow

Month 4:

Kubeflow
Model monitoring
Production MLOps patterns

Final Thoughts

MLOps is not a replacement for DevOps.

It's an evolution of DevOps principles applied to machine learning systems.

If you're already comfortable with Kubernetes, containers, CI/CD, cloud infrastructure, and observability, you're not starting from scratch.

You're already halfway there.

The challenge isn't learning everything about machine learning.

The challenge is understanding just enough ML to help models operate reliably in production.

And that's exactly where DevOps engineers excel.

From Tap to Transaction: What Really Happens Inside Kubernetes When You Pay ₹1000 Using PhonePe?

Srinivasaraju Tangella — Sun, 14 Jun 2026 12:51:52 +0000

A deep dive into how DNS, Load Balancers, Ingress, Services, kube-proxy, CNI, Pods, Secrets, Databases, Autoscaling, and Observability work together to process a single payment.

1. The User Taps "Pay"
A customer opens the PhonePe app and sends ₹1000.

Mobile App | POST /payment

At this moment Kubernetes hasn't seen the request yet.

2. DNS Finds the Application

The phone asks:

Where is api.phonepe.com?

DNS responds with the public IP of the Load Balancer.

|Mobile | DNS | Load Balancer IP`

3. The Load Balancer Receives Traffic

The cloud Load Balancer becomes the entry gate.

Internet | Load Balancer Responsibilities: SSL/TLS termination Traffic distribution DDoS protection High availability

4. Ingress Becomes the Traffic Police

The request enters Kubernetes.

Load Balancer | Ingress Controller Ingress examines: Http POST /payment

and decides:

Send traffic to payment-service

5. Service Finds the Right Application

A Kubernetes Service acts like a stable virtual address.

Ingress | payment-service

Users never talk directly to pods.
Pods come and go.
Services remain stable.

6. kube-proxy or eBPF Chooses a Backend Pod

The Service may have:

payment-pod-1 payment-pod-2 payment-pod-3 payment-pod-4

Routing happens through:

Service | kube-proxy
or

Service | eBPF (Cilium)

One healthy pod is selected.

7. Endpoints Tell Kubernetes Where Pods Exist

Endpoints contain real Pod IPs.

payment-service | Endpoints | 10.0.1.15 10.0.2.20 10.0.3.18

The request is mapped to an actual pod.

8. CNI Moves the Packet Across the Cluster

Now networking begins.

Node A | CNI | Node B

The CNI plugin:
AWS VPC CNI
Calico
Cilium
ensures the packet reaches the correct pod.

9. Network Policies Check Security Rules

Before reaching the application:

Packet | Network Policy

Kubernetes verifies:

Is this traffic allowed?

If not:

DROP
The request never reaches the application.

10. The Payment Pod Processes the Request

The application finally receives:

POST /payment

Business logic starts.
Examples:
User validation
Balance checks
Fraud detection
Payment creation

11. Secrets Provide Sensitive Information

The application needs credentials.

Database Password UPI Keys API Tokens Certificates

These come from Kubernetes Secrets.

12. ConfigMaps Provide Configuration

The application also needs:

Timeouts Feature Flags Log Levels

These come from ConfigMaps.

13. Internal Microservices Communicate

The payment service rarely works alone.
It may call:

User Service Fraud Service Notification Service UPI Service

Each call again passes through:

Service | kube-proxy/eBPF | Pod

14. Database Stores the Transaction

Payment information is persisted.

Payment Pod | Database

Examples:
PostgreSQL
MySQL
Cassandra
MongoDB
The transaction record is saved.

15. Persistent Volumes Protect Data

Data is stored on:

Persistent Volume
through:

Persistent Volume Claim

Even if pods die, data survives.

16. Observability Captures Metrics

While the payment is being processed:

Latency Request Count Error Rate CPU Usage Memory Usage

are collected.
Typical stack:

Prometheus | Grafana

17. Logging Records Every Event

Every action creates logs.

Payment Started Payment Approved Payment Completed
These logs help engineers troubleshoot problems.

18. Health Probes Continuously Check the Application

Kubernetes performs:

Startup Probe Readiness Probe Liveness Probe

to ensure the service remains healthy.

19. Horizontal Pod Autoscaler Handles Traffic Spikes

Suppose a festival sale begins.
Traffic jumps from:

100 Requests/sec

10000 Requests/sec

HPA responds:
Plain text

4 Pods ↓ 20 Pods ↓ 100 Pods

automatically.

20. Scheduler Places New Pods

Every new pod requires a node.
The Scheduler decides:

Which node should run this pod?

based on:
CPU
Memory
Affinity
Taints
Tolerations

21. Kubelet Starts Containers
After scheduling:

Scheduler | Node | Kubelet

Kubelet ensures the container is running.

22. Container Runtime Launches the Application

The runtime:

containerd

pulls the image and starts the application.

payment:v1

23. Deployment Maintains Desired State

If a pod crashes:

Desired Pods = 10 Current Pods = 9

Deployment immediately creates a replacement.

24. Cluster Autoscaler Adds More Nodes

When the cluster runs out of capacity:

No Space Available

Cluster Autoscaler or Karpenter provisions additional nodes.

10 Nodes ↓ 20 Nodes

"25. The Response Returns to the User*

Finally:

Payment Successful Transaction ID: TXN12345

travels back through:

₹1000 Paid Successfully

Final Architecture:

Closing Thought
A payment that takes less than a second on your phone triggers an entire Kubernetes ecosystem behind the scenes—networking, security, service discovery, routing, storage, autoscaling, observability, scheduling, and self-healing—all working together to process a single transaction reliably

eBPF in Kubernetes: The Technology Quietly Replacing iptables, kube-proxy, and Traditional Networking

Srinivasaraju Tangella — Sun, 14 Jun 2026 11:25:11 +0000

Introduction

For years, Kubernetes networking relied heavily on iptables, kube-proxy, conntrack, and Linux networking primitives.

As Kubernetes clusters scaled from hundreds to thousands of services, networking complexity increased dramatically. Large iptables chains, packet traversal overhead, and observability challenges became common operational problems.

Enter eBPF.

eBPF (Extended Berkeley Packet Filter) is one of the most significant Linux kernel innovations in the last decade. It enables developers to run sandboxed programs directly inside the Linux kernel without modifying kernel source code or loading kernel modules.

Today, technologies such as Cilium, Hubble, Pixie, and modern observability platforms leverage eBPF to provide high-performance networking, security, and visibility for Kubernetes environments

What is eBPF?

eBPF is a programmable execution environment inside the Linux kernel.

Instead of processing packets through long chains of iptables rules, eBPF allows custom programs to execute directly within kernel networking hooks.

Traditional approach:

Application → Service → kube-proxy → iptables → Backend Pod

eBPF approach:

Application → eBPF Program → Backend Pod

This significantly reduces packet processing overhead.

Why Kubernetes Needed eBPF

Consider a cluster with:

500 Nodes
10,000 Pods
2,000 Services

In a traditional environment:

kube-proxy generates thousands of iptables rules
packet traversal becomes expensive
troubleshooting becomes difficult
observability is limited

Common challenges include:

Service latency
Conntrack exhaustion
Slow failovers
Large iptables chains

eBPF solves many of these issues by moving packet decisions closer to the kernel.

eBPF Architecture

+--------------------------------------+
| Kubernetes Components |
| Pods, Services, Ingress |
+--------------------------------------+
|
v
+--------------------------------------+
| Cilium Agent |
+--------------------------------------+
|
v
+--------------------------------------+
| eBPF Programs |
| XDP |
| TC Layer |
| Socket Layer |
| Security Hooks |
+--------------------------------------+
|
v
+--------------------------------------+
| Linux Kernel |
+--------------------------------------+
|
v
+--------------------------------------+
| Network Interface |
+--------------------------------------+

eBPF programs attach to multiple locations inside the kernel.

Examples:

XDP (eXpress Data Path)
Traffic Control (TC)
Socket Layer
Security Layer
Tracepoints
Kprobes

Each hook provides visibility into different parts of the networking stack.

Understanding XDP

XDP is one of the fastest packet-processing paths available in Linux.

Packet Flow:

NIC → XDP → Kernel Networking Stack

XDP can:

Drop packets
Redirect packets
Load balance traffic
Mitigate DDoS attacks

before packets even enter the normal networking stack.

How eBPF Replaces kube-proxy

Traditional Service Routing:

Pod
↓
Service IP
↓
kube-proxy
↓
iptables
↓
Backend Pod

eBPF Routing:

Pod
↓
eBPF Service Lookup
↓
Backend Pod

Benefits:

Lower latency
Faster failover
Reduced CPU usage
Better scalability

eBPF Maps

eBPF programs use data structures called Maps.

Maps store:

Service IPs
Backend Pod IPs
Connection information
Policy rules

Example:

Service:
10.96.0.10

Backends:
10.1.1.2
10.1.1.3
10.1.1.4

Instead of searching through thousands of iptables rules, eBPF performs a direct map lookup.

eBPF for Network Security

Network Policies can be enforced directly inside the kernel.

Traditional Model:

Packet
↓
iptables
↓
Allow/Deny

eBPF Model:

Packet
↓
eBPF Policy Engine
↓
Allow/Deny

Advantages:

Faster enforcement
Better scalability
Rich visibility

eBPF for Observability

One of eBPF's biggest advantages is observability.

It can capture:

DNS Requests
TCP Connections
HTTP Requests
Latency Metrics
Failed Connections

without modifying application code.

This is why platforms such as Hubble and Pixie have become popular.

Essential eBPF Commands

Check kernel version:

uname -r

Verify BPF filesystem:

mount | grep bpf

List loaded eBPF programs:

bpftool prog show

List eBPF maps:

bpftool map show

Show network attachments:

bpftool net show

List Cilium status:

cilium status

Display eBPF service maps:

cilium service list

Show endpoints:

cilium endpoint list

Monitor live packet events:

cilium monitor

View network flows:

hubble observe

Real Kubernetes Troubleshooting Example

Problem:

Application timeout between frontend and backend services.

Traditional investigation:

kubectl logs
tcpdump
iptables inspection
conntrack debugging

eBPF investigation:

hubble observe

Output:

frontend-pod → backend-pod
HTTP GET /api/users
Latency: 325ms

Immediate visibility into application traffic.

Why Every Kubernetes Engineer Should Learn eBPF

eBPF is becoming a foundational technology for:

Kubernetes Networking
Service Mesh
Security
Runtime Protection
Observability
Performance Engineering

Understanding eBPF helps engineers move beyond simply operating clusters and into understanding how traffic actually flows through the Linux kernel.

As cloud-native platforms continue evolving, eBPF is increasingly becoming the preferred foundation for networking, security, and observability.

The future of Kubernetes networking is not more iptables rules.