Forem: Nitesh More

AWS Networking Demystified: VPC, Subnets, Security, and Beyond

Nitesh More — Fri, 22 Aug 2025 05:44:59 +0000

When you first dive into AWS, networking feels like a maze. Between VPCs, subnets, routing tables, security groups, and NACLs, it’s easy to get lost.

This guide breaks it down step by step, so you’ll walk away knowing how all the pieces fit together.

1. Virtual Private Cloud (VPC)

A VPC is your own private section of the AWS cloud.
Think of it as your own data center in the cloud, isolated from others.

You define the IP address range (CIDR block, e.g., 10.0.0.0/16).
Inside it, you place subnets, route tables, and security rules.
You can connect your VPC to the internet (via Internet Gateway) or keep it private.

👉 Every AWS account comes with a default VPC, but for production, you almost always create custom ones.

2. Subnets

Inside a VPC, you slice the network into subnets.

Public subnet → connected to the internet via an Internet Gateway.
Private subnet → no direct internet access, usually behind a NAT Gateway or used for internal services.

📝 Example:

Public subnet hosts a web server.
Private subnet hosts a database (never exposed directly to the internet).

3. Route Tables

Subnets don’t know where to send traffic by default. That’s where Route Tables come in.

Each subnet is associated with a route table.
Example route: 0.0.0.0/0 → Internet Gateway (for internet access).
Private subnets may instead route 0.0.0.0/0 → NAT Gateway (so they can access the internet outbound but remain unreachable from outside).

4. Internet Gateway (IGW) & NAT Gateway

Internet Gateway (IGW) → attaches to a VPC to allow resources in public subnets to connect to the internet.
NAT Gateway → allows private subnets to initiate outbound traffic to the internet (like downloading updates) while blocking inbound traffic.

👉 Rule of thumb:

Public subnet = IGW.
Private subnet = NAT Gateway.

5. Security Groups (SG)

A Security Group is like a firewall at the instance level (EC2, RDS, etc).

Stateful: If you allow inbound traffic, the response is automatically allowed.
Works on allow rules only (no explicit deny).
Example:
- Allow inbound TCP 22 (SSH) from 10.0.0.0/16.
- Allow inbound TCP 443 (HTTPS) from anywhere.

6. Network ACLs (NACLs)

A NACL is like a firewall at the subnet level.

Stateless: You must define both inbound and outbound rules.
Works with allow and deny rules.
Example:
- Deny inbound TCP 22 (SSH) from everywhere.
- Allow inbound TCP 443 (HTTPS) from 0.0.0.0/0.

👉 Quick comparison:

Security Groups = “Who can talk to this server?”
NACLs = “What traffic can pass through this subnet?”

7. VPC Peering

What if you have two VPCs and want them to talk?

VPC Peering connects two VPCs privately using AWS backbone network.
It’s one-to-one and doesn’t support transitive peering (VPC A can’t automatically talk to C via B).
Alternative for larger architectures → Transit Gateway.

8. Transit Gateway (TGW)

A Transit Gateway is like a hub for multiple VPCs and on-prem networks.
Instead of managing many VPC peerings, you connect each VPC to TGW once.
Supports transitive routing.
Great for enterprise-scale multi-VPC setups.

9. PrivateLink & VPC Endpoints

Sometimes you don’t want your private subnet to talk to AWS services (like S3, DynamoDB) over the public internet.

VPC Endpoint (Gateway/Interface) → private connection between your VPC and AWS service.
PrivateLink → lets you securely connect to services in another VPC without exposing traffic to the internet.

10. Putting It All Together (Example)

Imagine a simple 3-tier architecture:

Public Subnet → Load Balancer (ALB)
Private Subnet A → App Servers (EC2 in Auto Scaling Group)
Private Subnet B → Database (RDS)

Traffic flow:
User → ALB (Public Subnet) → App Server (Private Subnet) → Database (Private Subnet)

Security Layers:

ALB SG → allows inbound HTTPS from internet.
App Server SG → allows inbound only from ALB SG.
DB SG → allows inbound only from App Server SG.
NACLs → add subnet-wide restrictions for extra defense.

11. Key Best Practices

Use least privilege rules (narrow CIDR ranges).
Split workloads across AZs for resilience.
Use NAT Gateway for private subnets needing outbound access.
For many VPCs, prefer Transit Gateway over complex peering meshes.
Use VPC Flow Logs to monitor traffic.

✅ Takeaway

AWS networking isn’t just about connecting resources — it’s about designing secure, scalable, and maintainable networks.

If you understand VPC, subnets, routing, security groups, NACLs, and peering, you’ve got the foundation to handle real-world AWS architectures.

Into the Future: What is Agentic AI (and How You Can Try It Today?)

Nitesh More — Tue, 19 Aug 2025 22:57:02 +0000

1. What is Agentic AI?

Agentic AI goes beyond chatbots. Instead of waiting for you to type prompts, agents act proactively and independently. They:

Plan tasks
Call APIs and use tools
Adapt to new information
Automate workflows (like triaging tickets, deploying code, or managing data pipelines)

Think of it as moving from “ask me something” to “I’ll get it done.”

2. Why It Matters

Traditional AI = reactive.
Agentic AI = autonomous + adaptive.

This opens the door for:

Developers automating repetitive DevOps tasks.
Businesses streamlining support, ticketing, and triage.
Knowledge workers offloading research, writing, and analysis.

3. Building Your First Agent (Hands-On)

Build a Free, Open-Source Agent: GitHub Issue Triage with Ollama

What you’ll build

A small Python agent that:

Reads open GitHub issues
Thinks locally via an open-source LLM (Ollama)
Decides labels (bug/feature/docs/etc.)
Applies labels via the GitHub API

No cloud LLM keys required.

Prereqs (all free)

Python 3.10+
Ollama (local LLM runtime)

Install: https://ollama.com
Start Ollama server (if it isn’t already):
```
 ollama serve
```

Pull a small instruct model (pick one):

 ollama pull llama3.1:8b-instruct-q2_K
 # or smaller options if RAM is tight:
 # ollama pull qwen2.5:1.5b-instruct
 # ollama pull phi3:mini

Verify the server & model

 curl http://localhost:11434/api/tags
 # expect: {"models":[{"name":"llama3.1:8b-instruct-q2_K", ...}]}

GitHub Personal Access Token (classic or fine-grained) with repo scope

Save it to an env var: export GITHUB_TOKEN=ghp_...

Project layout

agent/
  triage_agent.py
  tools.py
  prompts.py
  requirements.txt

requirements.txt

requests>=2.31.0
pydantic>=2.7.0

Install:

pip install -r requirements.txt

Step 1: Define “tools” (GitHub API helpers)

Create tools.py:

import os
import requests
from typing import List, Dict

GITHUB_TOKEN = os.getenv("GITHUB_TOKEN")
REPO = os.getenv("REPO")
if not REPO:
    raise RuntimeError("Set REPO env var, e.g. export REPO=owner/repo")

HEADERS = {
    "Authorization": f"Bearer {GITHUB_TOKEN}",
    "Accept": "application/vnd.github+json"
}

def get_open_issues(limit: int = 20) -> List[Dict]:
    url = f"https://api.github.com/repos/{REPO}/issues?state=open&per_page={limit}"
    r = requests.get(url, headers=HEADERS, timeout=30)
    r.raise_for_status()
    # Filter out PRs (GitHub returns PRs in /issues)
    issues = [i for i in r.json() if "pull_request" not in i]
    # Keep only fields we need
    simplified = [
        {
            "number": i["number"],
            "title": i["title"],
            "body": i.get("body") or ""
        }
        for i in issues
    ]
    return simplified

def add_labels(issue_number: int, labels: List[str]) -> None:
    if not labels:
        return
    url = f"https://api.github.com/repos/{REPO}/issues/{issue_number}/labels"
    r = requests.post(url, headers=HEADERS, json={"labels": labels}, timeout=30)
    r.raise_for_status()
    print(f"[agent] Labels applied to issue #{issue_number}: {labels}")

Step 2: A clear system prompt for the model

Create prompts.py:

ALLOWED_LABELS = [
    "bug", "feature", "enhancement", "docs", "question",
    "performance", "refactor", "security"
]

SYSTEM_PROMPT = f"""
You are a GitHub issue triage agent.

Return ONLY a JSON array. No prose, no markdown, no code fences.

Allowed labels (use up to two):
{ALLOWED_LABELS}

For each issue object in the input, produce an object:
{{
  "number": <issue_number>,
  "labels": ["bug"] // labels MUST be from the allowed list
}}

If you are unsure, use one generic label: "question" or "enhancement".
If you cannot determine labels, return an empty array [].

Output format examples:
[
  {{ "number": 123, "labels": ["bug"] }},
  {{ "number": 456, "labels": ["docs","enhancement"] }}
]
"""

Step 3: Minimal agent loop using Ollama’s local API

Create triage_agent.py:

import os
import json
import requests
from typing import List, Dict, Any
from tools import get_open_issues, add_labels
from prompts import SYSTEM_PROMPT, ALLOWED_LABELS

MODEL = os.getenv("MODEL", "llama3.1:8b-instruct")
OLLAMA_BASE = os.getenv("OLLAMA_BASE", "http://localhost:11434")
OLLAMA_URL = f"{OLLAMA_BASE}/api/generate"
DEBUG = os.getenv("DEBUG", "1") == "1"

def dprint(*args):
    if DEBUG:
        print(*args, flush=True)

def extract_json_array(text: str) -> List[Dict[str, Any]]:
    text = (text or "").strip()
    # Try to extract first JSON array (handles stray prose)
    start = text.find("[")
    end = text.rfind("]")
    if start != -1 and end != -1 and end > start:
        try:
            return json.loads(text[start:end+1])
        except Exception:
            pass
    return []

def ask_llm(issues: List[Dict[str, Any]]) -> List[Dict[str, Any]]:
    user_prompt = "Issues:\n" + json.dumps(issues, ensure_ascii=False, indent=2)
    prompt = f"{SYSTEM_PROMPT.strip()}\n\n{user_prompt}"

    payload = {
        "model": MODEL,
        "prompt": prompt,
        "stream": False,
        "options": {"temperature": 0}
    }
    dprint(f"[agent] POST {OLLAMA_URL} (model={MODEL})")
    r = requests.post(OLLAMA_URL, json=payload, timeout=300)
    dprint(f"[agent] LLM status: {r.status_code}")
    r.raise_for_status()

    data = r.json()
    raw = (data.get("response") or "").strip()
    dprint("[agent] Raw model reply (first 500 chars):")
    dprint(raw[:500] + ("..." if len(raw) > 500 else ""))

    arr = extract_json_array(raw)
    dprint(f"[agent] Parsed suggestions: {len(arr)}")
    return arr

def sanitize_labels(labels: List[str]) -> List[str]:
    out = []
    for l in labels:
        if l in ALLOWED_LABELS and l not in out:
            out.append(l)
        if len(out) == 2:
            break
    return out

def main():
    repo = os.getenv("REPO")
    if not repo:
        print("ERROR: Set REPO env var, e.g. export REPO=owner/repo")
        return

    print(f"[agent] Using repo: {repo}")
    issues = get_open_issues(limit=20)
    print(f"[agent] Open issues (non-PR): {len(issues)}")
    if not issues:
        print("[agent] No open issues found. Create one and rerun.")
        return

    suggestions = ask_llm(issues)
    if not suggestions:
        print("[agent] Model returned no suggestions or parsing failed.")
        return

    any_applied = False
    for s in suggestions:
        num = s.get("number")
        raw_labels = s.get("labels", [])
        labels = sanitize_labels(raw_labels)

        print(f"[agent] Suggestion → issue #{num}: raw={raw_labels} -> filtered={labels}")

        # Guardrail: never auto-apply "security"
        if "security" in labels:
            labels.remove("security")

        if num and labels:
            any_applied = True
            print(f"[agent] Applying {labels} to issue #{num}")
            try:
                add_labels(int(num), labels)
            except Exception as e:
                print(f"[agent] Failed to apply labels to #{num}: {e}")

    if not any_applied:
        print("[agent] Nothing to apply (no labels or numbers).")

if __name__ == "__main__":
    main()

Run it:

export REPO=owner/repo
export GITHUB_TOKEN=ghp_yourtoken
# (optional) pick a smaller model if needed
export MODEL=llama3.1:8b-instruct-q2_K  

python triage_agent.py

You should see it print which labels it applied. Open an issue with “crash, error, stacktrace” and watch it label bug.

How this is “agentic”

The model reasons over multiple issues and decides actions (labels).
The Python loop executes tools (GitHub API) based on those decisions.
You can add reflection (e.g., if labels empty, re-ask with a hint), memory (store past choices in a JSON file), and approval gates (dry run mode).

4. Real-World Ecosystem: Where Claude Fits In

Now that you understand the basics, here’s where things get exciting:

🟣 Anthropic’s Claude Agents
Anthropic recently launched Claude Agents. These are production-ready frameworks for building safe, reliable, long-context AI agents. They integrate with:

Claude API – the core brain.
Workbench – an environment for prototyping and testing agents.
MCP (Model Context Protocol) – a way for agents to connect to external tools and APIs safely.

Essentially, Claude is positioning itself as the enterprise-grade agentic AI platform.

🔵 Other Ecosystem Players

OpenAI: AutoGPT, GPTs, and upcoming agent frameworks.
LangChain & LlamaIndex: Open-source toolkits for chaining agent logic.
Startups (e.g., Cognition’s Devin, Cursor): Agents for specific verticals like coding.

5. Debugging the Hype: Gotchas to Watch Out For

Agents aren’t perfect — they can still hallucinate or make bad decisions.
Cost can grow if you let an agent loop endlessly.
Security matters — don’t give agents unrestricted API keys.

6. The Future

The real magic will come when agents:

Collaborate with each other (multi-agent systems).
Stay persistent (remember context across weeks).
Work seamlessly with human approval loops.

We’re at the early days, but just like cloud and Kubernetes once felt futuristic, agentic AI will soon feel normal.

Pods, ReplicaSets, Deployments, and StatefulSets: What’s the Difference?

Nitesh More — Tue, 19 Aug 2025 04:02:09 +0000

When I started with Kubernetes, one of the most confusing things was figuring out why there are so many different objects just to run a container. I thought, “Why can’t I just run my app as a Pod and be done with it?”

Turns out, Pods are just the beginning. As you scale, update, and manage real-world apps, you’ll need ReplicaSets, Deployments, and sometimes StatefulSets. Let’s walk through each one in plain English.

🟦 Pod: The Basic Building Block

A Pod is the smallest thing you can run in Kubernetes. It usually holds one container, sometimes more if they’re tightly coupled (like a sidecar).

Think of a Pod as a little wrapper around your app. It gives it an IP address, some storage, and a place to live inside the cluster.

The catch? Pods are ephemeral. If one dies, it’s gone. Kubernetes won’t automatically bring it back unless you add another layer on top.

👉 Example Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Great for testing. Not so great for production.

🟧 ReplicaSet: Keeping Things Alive

That’s where a ReplicaSet comes in. Imagine you want three Pods running at all times. If one crashes, the ReplicaSet creates a new one.

It’s like a babysitter for Pods — making sure the right number are always running.

👉 Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Still, ReplicaSets are rarely used directly. We usually let Deployments handle them.

🟨 Deployment: The Real Hero

A Deployment is what you’ll use most of the time. It manages ReplicaSets for you and makes rolling updates painless.

Say you want to update your app to a new version. With a Deployment, Kubernetes replaces Pods one by one, so your service never goes down. And if something breaks, you can roll back instantly.

👉 Example Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

This is the bread and butter for running web apps, APIs, or really any stateless service.

🟩 StatefulSet: For Apps That Remember Things

Finally, there’s the StatefulSet. This one is special. While Deployments treat Pods as disposable, StatefulSets give each Pod a stable identity — along with its own persistent storage.

This is exactly what you need for databases, queues, or anything that can’t just “forget” its data when restarted.

Pods get predictable names (db-0, db-1, db-2).
Each Pod can have its own volume that sticks around even if the Pod is deleted.

👉 Example StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Now each Pod (web-0, web-1) has its own storage that won’t get mixed up.

💡 Wrapping It Up

Here’s how I like to remember it:

Pod → Just runs your container. Great for testing, not production.
ReplicaSet → Babysits Pods, keeps the right number running.
Deployment → The real workhorse. Handles updates and rollbacks.
StatefulSet → For stateful apps like databases that need stable IDs and storage.

If you’re starting out, you’ll almost always use Deployments. When you need databases or apps that care about persistence, that’s when you bring in StatefulSets.

Everything else (Pods, ReplicaSets) are still there under the hood, but you don’t usually manage them directly.

👉 Next time you see kubectl get all showing Pods, ReplicaSets, Deployments, and maybe a StatefulSet, you’ll know exactly what role each one plays.

Automating DNS with ExternalDNS on EKS and Istio: Lessons From Real-World Gotchas

Nitesh More — Sun, 17 Aug 2025 02:58:53 +0000

When I first set up Istio on Amazon EKS, I thought DNS automation would be the easy part. Just install ExternalDNS, connect it to Route 53, and boom — api.yourdomain.com and grafana.yourdomain.com should resolve to my cluster.

Most of it did work smoothly. The EKS add-on installed fine, IAM permissions were clear from the docs, and Route 53 was wired up. But there was one thing missing in the documentation that cost me a lot of time: how to make ExternalDNS notice Istio hostnames.

In this post, I’ll explain:

How ExternalDNS, cert-manager, and Istio fit together
The exact setup I used
The one gotcha that slowed me down (annotations!)
A debugging checklist you can use when DNS records don’t appear

🧩 The Basics

🔹 ExternalDNS

A Kubernetes controller that creates and updates DNS records automatically in providers like Route 53. Annotate a Service or Ingress with a hostname, and ExternalDNS will manage the record for you.

🔹 cert-manager

cert-manager is a Kubernetes add-on that automates the management of TLS certificates. It integrates with Let’s Encrypt, Vault, or private CAs to issue and renew certificates automatically.

At its core, cert-manager uses two main components:

Issuer/ClusterIssuer → defines where certificates are requested from (e.g., Let’s Encrypt).

Certificate → defines what domain you want the cert for (e.g., *.yourdomain.com).

In my setup, I used it with a wildcard certificate (*.yourdomain.com) from Let’s Encrypt so all subdomains were automatically covered.

🔹 Istio

A service mesh that adds traffic routing and security. The Istio Gateway terminates TLS and forwards traffic based on the requested host (api.yourdomain.com, grafana.yourdomain.com, etc.).

📐 Architecture

EKS cluster with Istio installed
Istio ingressgateway (type LoadBalancer) → backed by an AWS NLB
ExternalDNS EKS add-on → manages Route 53 records
Route 53 hosted zone for yourdomain.com
cert-manager → wildcard TLS cert
VirtualServices → route subdomains to the right service

Flow:

⚙️ Setup

1. Install ExternalDNS Add-On

With EKS it’s easier to use the managed add-on. Example config:

provider: aws
policy: upsert-only
txtOwnerId: archops
domainFilters:
  - yourdomain.com
sources:
  - service
  - istio-gateway

2. Annotate the Istio IngressGateway

This was the missing piece. ExternalDNS does not see Istio VirtualServices directly. You need to annotate the Istio ingressgateway Service with the subdomains you want managed:

kubectl -n istio-system annotate svc istio-ingressgateway \
  external-dns.alpha.kubernetes.io/hostname="api.yourdomain.com,grafana.yourdomain.com" \
  --overwrite

Once I did this, ExternalDNS created the records in Route 53 instantly.

3. Istio Gateway + VirtualServices

After ExternalDNS creates the DNS records, Istio takes over to handle TLS termination and routing based on host headers.

First, you need a Gateway that uses the wildcard TLS certificate from cert-manager. Then you create separate VirtualService objects for each subdomain.

Gateway with Wildcard Certificate

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway    # use istio’s default ingress gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: wildcard-yourdomain-com   # cert-manager Secret
    hosts:
    - api.yourdomain.com
    - grafana.yourdomain.com

VirtualService for API

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-vs
  namespace: api
spec:
  hosts:
  - api.yourdomain.com
  gateways:
  - istio-system/my-gateway
  http:
  - route:
    - destination:
        host: api-svc.api.svc.cluster.local
        port:
          number: 8080

…and similar VirtualService for Grafana just change host, service name and port.

🚧 The Gotcha: Annotations

Everything else was well-documented, but this part wasn’t obvious:

ExternalDNS doesn’t read Istio VirtualServices
Without annotations, no DNS records get created
Adding external-dns.alpha.kubernetes.io/hostname to the ingressgateway Service solved it

That was the one real stumbling block for me.

🔍 Debugging Checklist

If your DNS records don’t show up, here’s what to check:

Logs
check logs using kubectl logs deploy/external-dns -n kube-system
Domain filter
Make sure domainFilter matches your hosted zone exactly (yourdomain.com).
IAM permissions
ExternalDNS service account needs ChangeResourceRecordSets and ListHostedZones.
Stale TXT records
Sometimes old TXT entries block updates. Clean them in Route 53.
Annotations
ExternalDNS discovers hostnames in different ways:

If you use a standard Kubernetes Ingress, the spec.rules.host field is enough.
If you expose a Service of type LoadBalancer (like Istio’s ingressgateway), add external-dns.alpha.kubernetes.io/hostname with the hostnames.

❌ Why I Didn’t Use AWS Load Balancer Controller

Quick note: I skipped AWS Load Balancer Controller because:

Istio already handled L7 routing
We needed TCP/gRPC in addition to HTTP
TLS was managed inside Istio
One NLB was simpler and cheaper

✅ Final Thoughts

ExternalDNS, cert-manager, and Istio work beautifully together — once you know the trick with annotations.

Now I can add new subdomains like api.yourdomain.com or grafana.yourdomain.com without touching Route 53. ExternalDNS manages the records, cert-manager handles TLS, and Istio routes traffic where it belongs.

Hopefully, this walkthrough saves you the debugging time I went through!

💡 Have you run into similar DNS headaches with Istio on EKS? Share your story — I’d love to compare notes.

📬 Connect with me on LinkedIn

🧠 Building Intelligent Kafka Health Probes in Go

Nitesh More — Sat, 16 Aug 2025 05:21:07 +0000

In production environments, health checks are your early warning system — but not all checks are created equal. While Kubernetes’ liveness and readiness probes can tell you if a service is running, they can’t tell you if it's working. We hit this problem head-on while building a Kafka-based CVE processing pipeline, and it led us to create intelligent probes that know whether the consumer is truly healthy.

🚨 The Problem with Basic Probes

Our Kafka consumer processes CVE data, stores it in Postgres, and runs in Kubernetes. Initially, we used standard HTTP liveness/readiness endpoints that simply returned 200 OK if the process was up.

But we started running into invisible failures:

The consumer would be running but stuck due to a downstream DB issue.
It would be assigned a partition but not progressing.
Or it would silently lag behind, and no alerts were triggered.

These kinds of failures wouldn’t be caught until days later, sometimes after critical delays in CVE ingestion.

🧭 What We Needed

We wanted probes that could:

Detect if the consumer is stuck or not making progress
Track offset movement per partition
Check if the Kafka topic and brokers are reachable
Verify Postgres availability
Handle partition rebalances without stale state

🧪 How We Solved It

We used Go, the Sarama Kafka client, and some smart in-memory tracking. Here’s how it works:

🧮 1. Offset Tracking

We used sync.Map to store:

offsetMap: the most recent offset we’ve seen per partition
lastCommittedOffsets: used to detect if the consumer has stopped progressing

offsetMap.Store(message.Partition, message.Offset)

🔍 2. Intelligent Liveness Check

The /liveness endpoint does more than return 200 OK. It:

Connects to Kafka
Fetches the latest offset for each partition
Compares it with our last seen offset
Checks if there’s no new data OR if the offset hasn’t changed over time (indicating a stuck consumer)

if currentOffset == committedOffset || currentOffset == committedOffset+1 {
    // no new messages to process
} else if lastCommitted == committedOffset {
    // stuck — offset hasn't advanced
    unhealthy = true
}

📦 3. Readiness Check

The /readiness probe ensures:

At least one Kafka broker is reachable
The Kafka topic exists
Postgres is reachable using .PingContext()

Only if all of these are true does the service report itself as “ready.”

🔁 4. Handling Rebalances

During rebalancing, partitions are reassigned, and we clean up the stale state:

offsetMap.Delete(claim.Partition())
lastCommittedOffsets.Delete(claim.Partition())

This prevents invalid health status when the partition is no longer assigned to the consumer.

💡 Why This is "Intelligent"

Unlike typical health checks, our probes:

Track progress, not just availability
Are partition-aware
Can detect silent failures
Check both Kafka and DB dependencies
React to consumer rebalances

This allowed us to catch real issues — like stuck consumers or dead DB connections — before they caused data loss or delays.

📈 Lessons Learned

Don’t rely on basic probes for stateful services like Kafka consumers
Offset movement is a powerful signal for consumer health
Observability is about understanding behavior, not just uptime

✅ Conclusion

This approach has saved us from multiple production incidents by proactively identifying when the consumer isn’t doing useful work. We now treat our consumers like stateful workers — with health checks that are aware of what they’re supposed to be doing, not just whether they’re online.

🙌 Let’s Connect

Thanks for reading! If you enjoyed this post or have thoughts to share, feel free to reach out — I’d love to chat about Kafka, distributed systems, or anything DevOps.

📬 Connect with me on LinkedIn

How I Built Budget Brain🧠💰 in 12 Hours with Kiro as My AI Project Manager

Nitesh More — Sat, 16 Aug 2025 01:41:02 +0000

🚀 The Challenge

Hackathons are always a race against the clock. This time, I set out to build Budget Brain: an AI-powered advertising budget optimizer that uses Monte Carlo simulation and multi-algorithm validation to help businesses allocate ad spend smarter.

The goal?

Real-time pipeline visualization
Multi-algorithm optimization (Monte Carlo + Gradient + Bayesian)
Confidence scoring and validation
Accessibility-first UI
Production quality in just 12 hours

Sounds impossible, right?

It would have been — without Kiro.

🤝 Enter Kiro: My AI Technical Project Manager

Kiro became the organizing brain behind Budget Brain. Instead of drowning in feature creep, last-minute architecture decisions, or messy code, Kiro kept me laser-focused with:

📋 Specs & Planning: Clear requirements, user stories, and acceptance criteria
🏗️ Architecture Blueprints: Interfaces, component structures, and pipeline layouts
✅ Task Tracking: 24 implementation tasks with checkboxes (all completed!)
🪝 Code Quality Hooks: Automated reviews for performance, accessibility, and maintainability

In other words: I was coding at hackathon speed, but with enterprise-level discipline.

🧩 How I Structured Conversations with Kiro

I started with simple prompts, and Kiro turned them into complete systems:

Me: “I want to create a decision pipeline to enhance system accuracy.”
Kiro: Broke this into multi-algorithm validation, ensemble methods, and confidence scoring.

Me: “How do I combine multiple optimization algorithms reliably?”
Kiro: Generated the AccuracyEnhancementService architecture with parallel algorithm execution and result combination.

Me: “What’s the best way to validate optimization results?”
Kiro: Produced a 12-task plan covering gradient optimization, Bayesian modeling, LLM validation, and benchmark comparison.

👉 What began as vague ideas became concrete TypeScript interfaces, workflows, and production code.

🪝 Kiro Hooks: Automated Code Review Under Pressure

Even while sprinting, Kiro kept quality high with automated hooks:

Real-Time Code Review: Flagged long functions, duplicate logic, and type safety issues
Budget Brain–Specific Checks: Verified pipeline stage error handling, algorithm efficiency, and accessibility compliance
Performance Optimization: Detected unnecessary React re-renders, suggested caching in Monte Carlo + AccuracyEnhancementService
Quality Gates: Pre-commit scoring, test coverage checks, maintainability reviews

💡 The result: No technical debt — even in a hackathon sprint.

📑 Spec-to-Code: The Secret Weapon

I paired Kiro with a spec-to-code workflow that looked like this:

Requirements.md → User stories + acceptance criteria
Design.md → Technical architecture + TypeScript interfaces
Tasks.md → 12 concrete implementation tasks with checkboxes

Flow:
👉 User Story → Technical Design → Implementation Tasks → Production Code

This meant:

Zero architecture decisions during coding
Parallel dev (frontend + backend in sync)
Tests and accessibility baked in
No scope creep (24 tasks, nothing more)

🏆 The Outcome

With Kiro’s help, I shipped:

Real-time pipeline visualization with animated stages
Multi-algorithm ensemble (Monte Carlo, Gradient, Bayesian)
Confidence scoring + AI validation
600+ automated tests
Accessible, mobile-optimized UI

All in 12 hours.

Kiro wasn’t just an assistant. It was:

The planner (clear roadmap, specs, and tasks)
The architect (interfaces, algorithms, data models)
The code reviewer (hooks, checks, and optimizations)

🎯 Takeaway

Hackathons usually trade speed for quality. With Kiro, I had both.

I moved fast — but with a plan.
I built complex systems — without messy shortcuts.
I delivered production-quality features — under hackathon pressure.

👉 Bottom line: Kiro acted as my AI project manager, architect, and reviewer all in one. Budget Brain wouldn’t have been possible without it.

🔮 Looking Ahead

Budget Brain is just the start. The spec-to-code structure and Kiro-powered workflow could be applied to:

SaaS MVPs
Enterprise-grade feature sprints
Team collaboration with automated quality gates

Hackathons taught me that AI-assisted engineering discipline is the new superpower.

✍️ Built with ❤️ during [Code with Kiro Hackathon] 2025.

Click here to try
Connect with me