Forem: kaustubh yerkade

I Built an AI-Powered Infrastructure Documentation Generator Using GitHub Copilot CLI

kaustubh yerkade — Sun, 15 Feb 2026 17:27:05 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

As a DevOps engineer, one recurring pain point I’ve experienced is infrastructure documentation.

We write Terraform.
We deploy Kubernetes.
We build Docker images.

But documentation? It often gets delayed or skipped.

So I built AI-Powered Infra Doc Generator. A CLI tool that turns Infrastructure as Code into structured, enterprise grade documentation using GitHub Copilot CLI.

This tool:

Reads Terraform / YAML / Dockerfiles
Sends structured prompts to GitHub Copilot CLI
Generates:
- Architecture Overview
- Component Breakdown
- Security Risk Analysis
- Cost Optimization Suggestions
- Mermaid Architecture Diagram

All automatically in seconds. Instead of manually writing documentation, infrastructure can now explain itself.

Demo

Run the CLI-

$infra-doc-gen main.tf

The tool creates:

INFRA_DOC.md

Example output:

# Architecture Overview

This Terraform configuration provisions:
- AWS EC2 instance
- Application Load Balancer
- Security Group
- RDS Database

## Security Risks
- Security group allows 0.0.0.0/0 on port 22
- RDS encryption not enabled
- No IAM least-privilege enforcement

## Cost Optimization
- Use smaller instance types for non-production
- Enable autoscaling
- Consider Reserved Instances

Screenshots-

It also generates a Mermaid diagram:

graph TD
User --> ALB
ALB --> EC2
EC2 --> RDS

GitHub Repo: https://github.com/kaustubhyerkade/infra_doc_gen

My Experience with GitHub Copilot CLI

GitHub Copilot CLI completely changed how I approached this project.

Instead of building API wrappers or integrating SDKs, I could:

Work directly inside the terminal
Use natural language prompts
Iterate rapidly on structured AI responses
The biggest learning for me was prompt engineering.

Instead of asking:
“Explain this Terraform file”

I used structured instructions like:

You are a senior cloud architect.

Analyze the following infrastructure code and generate:

1. Architecture Overview
2. Key Components
3. Security Risks
4. Cost Optimization Suggestions
5. Mermaid diagram

This dramatically improved the quality and structure of the output.
It genuinely felt like pairing with a Cloud Architect inside my terminal.

Linux Internals Everyone Must Understand

kaustubh yerkade — Sun, 18 Jan 2026 19:29:42 +0000

Linux Internals Every DevOps Engineer Must Understand

(Let's go Beyond “I know Linux”)

If you claim DevOps, Linux isn’t just an OS. it’s your runtime, debugger, firewall, scheduler, and autopsy report.
This article covers the Linux internals that secretly gets you tested.

1. Linux File System Internals: `/proc` & `/sys`

Linux exposes its own brain as files.

`/proc` – Process & Kernel Runtime View

Virtual filesystem (no disk I/O)
Created at boot
Reflects current kernel state

Key paths:

/proc/cpuinfo      # CPU architecture, cores
/proc/meminfo      # Memory stats
/proc/loadavg      # Load average
/proc/<PID>/fd     # Open file descriptors
/proc/<PID>/maps   # Memory mapping

Production insight
If a Java app is leaking memory:

ls -l /proc/<PID>/fd | wc -l

You’ll instantly know if file descriptors are leaking.

`/sys` – Hardware & Driver Control Layer

Used by udev, drivers, containers
Allows controlled kernel interaction

Example:

/sys/class/net/eth0/speed
/sys/block/sda/queue/scheduler

Great takeaway

/proc = What is happening now
/sys = How hardware & kernel are wired

2. Process Lifecycle: fork → exec → zombie

Understanding processes separates juniors from seniors.

The Lifecycle

fork() → child process created
exec() → program replaced
wait() → parent collects exit status

fork();
exec("/bin/java");
wait();

Zombies (are Not Horror, Just Bad Parenting)

Process finished execution
Parent did not collect exit code
PID still exists

Check:

ps aux | grep Z

Fix:

Restart parent
Or fix application signal handling

Interview gold line

“Zombies don’t consume memory, but they exhaust PID space.”

3. Memory, CPU & Load Average (The Most Misunderstood Topic)

Load Average ≠ CPU Usage

uptime
# 1.2 0.9 0.7

Means:

Avg runnable or waiting processes over 1, 5, 15 minutes

Scenario	Meaning
Load = 4 on 4 cores	Healthy
Load = 10 on 4 cores	Overloaded
High load, low CPU	I/O bottleneck

Memory: Why “Free” Lies

free -m

Focus on:

available, not free
Linux aggressively uses cache

Clear myth:

“High memory usage is bad” ❌
“Unused memory is wasted memory” ✅

Real Debug Workflow

vmstat 1
iostat -x
top / htop

Can correlate:

CPU wait
Disk latency
Run queue

4. Networking Basics: Ports, Sockets & Reality

Port ≠ Process

A socket = IP + Port + Protocol

ss -tulnp

Example:

LISTEN 0 128 0.0.0.0:8080 java

Connection States You Must Know

State	Meaning
LISTEN	Waiting
ESTABLISHED	Active
TIME_WAIT	Normal close
CLOSE_WAIT	App bug

A signal
If you see many CLOSE_WAIT → application is leaking connections.

5. Permissions & SELinux (Where “It Works on My VM” Dies)

Linux Permissions Refresher

-rwxr-x---

But permissions alone are not enough.

SELinux (Mandatory Access Control)

Modes:

getenforce
# Enforcing | Permissive | Disabled

Why prod apps fail:

Correct permissions
Wrong SELinux context

Fix properly:

ausearch -m avc -ts recent
semanage fcontext
restorecon

Senior rule

Never disable SELinux in production, fix policies.

6. systemd: The Real Init System

systemd Is More Than “service start”

It handles:

Process supervision
Logging
Dependency management
Auto-restart

Example unit:

[Service]
ExecStart=/app/start.sh
Restart=always
MemoryMax=2G

Check failures:

journalctl -u myapp --since today

Why DevOps Love systemd

Built-in watchdog
CGroup resource limits
Deterministic startup

How they Evaluate This Knowledge

They won’t ask:

“Explain /proc”

They’ll ask:

“Why is load high but CPU idle?”

Or:

“App restarted but port still busy”

If you understand internals, answers come naturally.

Linux is:

Your observability platform
Your runtime security layer
Your truth source

Tools change.
Containers evolve.
Linux fundamentals compound forever.

The "Aha!" Moment: Why Understanding the JVM Changed How I Write Java

kaustubh yerkade — Thu, 01 Jan 2026 10:27:07 +0000

I Used Java for Years, Then I Finally Understood the JVM

I’ve scaled Java services, increased heap sizes and blamed GC for multiple times.

And for a long time, I still didn’t understand what the JVM was really doing.

If you’ve ever:

Given a service more RAM and watched latency get worse
Seen CPU spike while traffic was low
Hit OutOfMemoryError on a machine with free memory

This post is for you.

This isn’t a JVM reference guide. This is something I wish I had before debugging JVM issues in production.

The JVM Is Not “Java Runtime”

It’s a whole Runtime Operating System

Most people think of the JVM as:

“The thing that runs Java code.”

and I think that’s dangerously incomplete.

The JVM is:

A memory manager
A thread scheduler
A Just-In-Time (JIT) compiler
A runtime optimizer
A portable execution platform

In practice, the JVM behaves more like a mini operating system inside your OS. (Thats why its call Java Virtaul Machine)

Once you see it that way, a lot of “mysterious” behavior suddenly makes sense.

From Code to CPU: What Actually Happens

Here’s the real journey of your Java code:

.java → bytecode (.class) → interpreted → JIT compiled → machine code

Key insight:

Your Java code does not run the same way for its entire lifetime.

At startup:

Code is interpreted
It’s slow but flexible

Over time:

Hot code paths are detected
JIT compiles them into optimized native code
Optimizations are speculative and reversible

That’s why:

First requests are slow
Benchmarks lie
Restarting a JVM “fixes” performance (temporarily)

ClassLoaders: The Hidden Source of Insanity

ClassLoaders aren’t just about loading classes.
They define identity.

Two classes with the same name:

Loaded by different ClassLoaders
Are not the same class

This explains:

ClassCastException that makes no sense
Plugin architecture bugs
Dependency conflicts in fat JARs
Spring Boot classpath nightmares

So Basically

ClassLoaders are namespaces, not folders.

Once a class is loaded, unloading it is complicated.
And sometimes impossible.

JVM Memory: Why “Just Increase Heap” Is Bad Advice

This is where most JVM myths live.

JVM Memory ≠ Heap

The JVM uses more memory than you think:

Heap (Young + Old)
Metaspace (class metadata)
Thread stacks
Native memory
Direct buffers
Code cache

Important truth:

-Xmx limits the heap not the JVM.

This is why:

Containers OOM-kill Java apps
Kubernetes limits feel “ignored”
Metaspace OOMs happen unexpectedly

Why Bigger Heap Can Make Things Worse

A larger heap:

Means longer GC cycles
Increases pause time risk
Can hide memory leaks until it’s too late

In production:

A stable, smaller heap often performs better than a massive one.

Garbage Collection: Not About Speed but About Predictability

Garbage Collection exists because:

Manual memory management does not scale for humans.

But GC is not free.

Every GC strategy is a tradeoff between:

Throughput
Latency
Memory footprint
Predictability

Modern collectors (G1, ZGC, Shenandoah) optimize for:

Shorter pauses
More consistent latency

Key realization:

GC tuning is about controlling pauses, not eliminating them.

And yes Stop The World(STW) still exists.
It’s just shorter and smarter now.

JIT Compilation: Your Code Changes While Running

This part blows minds.

The JVM:

Profiles your code
Assumes patterns
Optimizes aggressively
Deoptimizes when assumptions break

This explains:

Why traffic shape matters
Why long running services behave differently
Why redeploying can reset performance

The JVM is constantly asking:

“Is this still the fastest way to run this code?”

Threads, CPU, and the Illusion of Parallelism

Java threads map to OS threads.

Which means:

Context switching is expensive
More threads ≠ more throughput
Blocking IO kills scalability

This is why:

CPU spikes on “idle” systems
Thread dumps reveal chaos
Virtual threads exist (finally)

SO Behind the scenes:

Threads compete. They don’t cooperate.

Why JVM Apps sometimes Fail in Production ?

Most JVM outages are not caused by:

Java being slow
The GC being broken
The JVM being bad !

They’re caused by:

Wrong thinking
Blind tuning
Ignoring runtime behavior
Treating JVM like a black box

Common mistakes:

Increasing heap without GC analysis
Ignoring native memory
No GC logs
No understanding of startup vs steady state

The JVM Debugging Toolkit (Minimal, Powerful)

You don’t need fancy tools to understand the JVM.
Just learning these would be sufficient:

jcmd
jstack
jmap
GC logs

Most production mysteries can be explained with these tools alone.

The JVM (If You want Remember Only One Thing)

Then Remember this:

The JVM is a self-optimizing runtime that trades predictability for performance.

Once you accept that:

Java feels less random
Performance issues feel explainable
Production debugging gets calmer

Conclusion

Java doesn’t run on your machine.

It negotiates with it.
Continuously.
Aggressively.

And once you understand the JVM, Java stops feeling slow
and starts feeling honest.

A 5 Minute GC Log Walkthrough (That Actually Helps)

GC logs look scary until you know what to look for.
Let’s decode the only things that matter.

1. Enable GC Logging (Modern JVM)

-Xlog:gc*:stdout:time,level,tags

This gives you:

When GC happened
Which collector ran
How long the pause was
How much memory was reclaimed

2. A Real GC Log Line (Simplified)

[3.421s][info][gc] GC(12) Pause Young (Normal) 512M->128M(2048M) 45.6ms

3. How to Read It (Left → Right)

3.421s
→ Time since JVM start
If this is early, you’re still warming up.

GC(12)
→ 12th GC cycle
High frequency = allocation pressure.

Pause Young
→ Minor GC
Usually healthy. Frequent is okay until latency matters.

512M->128M(2048M)
→ Before → After (Heap size)
If “after” keeps growing, you’re promoting objects too fast.

45.6ms
→ Stop-the-world pause
This is the number users feel.

4. What Healthy GC Looks Like

✔ Young GC
✔ Short pauses (<50ms)
✔ Old Gen stays mostly flat
✔ No Full GC during normal load

5. Red Flags to Watch For

Pause > 200ms → Latency spikes
Old Gen always growing → Memory leak or bad object lifetime
Frequent Full GC → Heap too small or wrong GC
GC during low traffic → Memory fragmentation

6. One Golden Rule

GC logs tell a story. Don’t read them line by line look for patterns.

Most JVM issues are visible 10 lines into the log.

7. When GC Logs Save Production

If you ever think:

“CPU is high but traffic is low”
“Latency spikes every few minutes”
“Heap increase didn’t help”

GC logs will usually explain why.

If you liked this post , Just let me in the comments.

Building a Global Scale App in 2026: Treating Zero Latency as a Lie (Here’s What Actually Works)

kaustubh yerkade — Thu, 25 Dec 2025 20:44:25 +0000

“Zero latency is just latency we haven’t measured yet.”

Every few months, someone asks:

How do I build an app that works worldwide with zero latency and minimum cost?

Short answer: You can’t.
Long answer: You don’t need to.

In 2026, the best global applications don’t beat physics but
they outsmart perception, architecture, and failure modes.

This article explains how teams actually build “instant” global apps without burning money or their on call engineers.

The Hard Truth (Let’s Get This Out of the Way)

The speed of light exists
Packets still travel through oceans
Users live far away from your servers

If someone promises zero latency worldwide, they are selling slides, not systems.

But here’s the twist

Users don’t care about latency.
They care about responsiveness.

That’s the game in 2026.

The 2026 Model

Move code to users, not users to code.
Cache everything you legally can.
Fail locally, not globally.

If you remember only this, you’ll already outperform most systems.

High-Level Architecture (2026 Edition)

Three layers. No more.

Edge (closest to users)
Regional
Core (rarely touched)

If a request reaches your core backend…

“Congratulations, you just paid extra for latency.”

1. Frontend: Static Is the New Fast

In 2026, the fastest frontend is still the simplest one.

What winning teams do:

Static first rendering
Aggressive CDN usage
Minimal JavaScript on first load

Why?

Static content served from the edge is:

Cheap
Predictable
Globally fast

“The fastest query is the one you never run.”

2. Edge Compute: The Real Backend

“Edge compute: because the backend was too far away.”

Edge compute isn’t a toy anymore.
It’s where real logic lives.

What belongs at the edge:

Authentication checks
Feature flags
A/B testing
Request routing
Lightweight APIs
Response shaping

What doesn’t:

Heavy transactions
Long running jobs
Strongly consistent workflows

“If your edge function needs a database, you missed the point.”

Edge code must be:

Stateless
Fast
Disposable

Stateless code travels better.

3. Data Strategy: Latency Lives Here

This is where most global apps fail.

Common mistake

One global database. One source of truth. One giant bottleneck.

The cool 2026 approach: Data by behavior

Data Type	Strategy
Sessions	Edge KV
User profiles	Geo-replicated
Feeds	Precomputed + cached
Analytics	Async events
Payments	Regional strong consistency

“Strong consistency is great until customers want speed.”

Not all data deserves the same guarantees.
Treat it accordingly.

4. APIs: Fewer, Bigger, Lazier

2026 APIs are boring and that’s a compliment.

Modern API rules:

Fewer round trips
Larger responses
Cacheable by default
Idempotent writes
Async side effects

“Every API call is a tax on latency.”

If your frontend makes 12 calls to render a page —
the problem isn’t the network.

5. Caching: Your #1 Performance Tool

Caching hierarchy that actually works:

Browser cache
Edge cache
Regional cache
Core backend (last resort)

Caching is the only performance optimization that actually works.

Yes, cache invalidation is hard.
No, that doesn’t make skipping caching acceptable.

6. Designing for Failure (Lessons from 2025)

Big recent outages taught us painful lessons:

Central auth can kill everything
Global rollouts can cascade instantly
One bad deploy ≠ one bad region

2026 design rules:

Login should degrade, not block
Feature flags must fail open
Rollouts must be regional
Blast radius must be small

“Everything is highly available until the deploy.”

Failure isn’t optional.
Graceful failure is.

7. Cost Optimization (Because Finance Is Watching)

How fast global apps stay cheap:

Serverless over always-on
Edge over regional compute
Async over synchronous
Cache over compute
Events over polling

“Cloud bills are just performance bugs with receipts.”

Edge requests are often 10-100× cheaper than traditional backend calls.

A Realistic 2026 Stack (Example)

Layer	Choice
Frontend	Static + partial hydration
CDN	Global edge network
Compute	Edge functions + serverless
Data	Geo-replicated DB + edge KV
Messaging	Event streaming
Auth	Stateless tokens
Observability	Distributed tracing

Notice what’s missing?
No giant always-on clusters
No global locks
No central chokepoints

Final Takeaways

You can’t beat physics but you can beat perception
Simpler systems scale better
Global ≠ centralized
Users forgive slowness but not inconsistency

“If one region fails and no one notices, you designed it right.”

Closing Thought

In 2026, the best applications won't be impressive because they’ll be complex.

They’ll be impressive because most of the system quietly stays out of the way.

That’s real engineering.

Oracle AI Database 26ai in Production

kaustubh yerkade — Tue, 23 Dec 2025 04:12:50 +0000

Oracle AI Database 26ai is released. It is a next-generation AI-native database release from Oracle that brings artificial intelligence into the core of the database engine.

https://www.oracle.com/in/database/free/get-started/

Oracle AI Database 26ai: Redefining the Database for the AI Era

Databases have traditionally been designed to store data and answer structured queries.Artificial intelligence systems, on the other hand, evolved as separate platforms that required data to be copied, transformed, and synchronized outside the database.

Oracle AI Database 26ai changes this model.

Instead of moving data to AI systems, it brings AI capabilities directly into the database engine. Vector search, semantic similarity, and AI-ready retrieval now operate alongside SQL, transactions, and security controls. This allows engineers to build AI-powered applications without introducing new data pipelines or external vector databases.

This article explains how Oracle AI Database 26ai works from a technical perspective and how it can be used to build real production-grade AI systems.

What Is Oracle AI Database 26ai?

Oracle AI Database 26ai is Oracle’s newest long-term support release of its flagship database, designed for enterprises that need AI enabled data platforms. It replaces the earlier Oracle Database 23ai release, and all features from 23ai are included in 26ai.

The core idea is to architect AI into the foundation of data management, enabling intelligent processing, analytics, and application support without exporting data to external systems.

Key highlights :

AI built into the data engine
Native vector support and similarity search
Unified support for relational, document, JSON, graph, spatial, and other data types
Developer productivity features like AI assisted code generation
Enterprise-grade performance, governance, and security
Distributed and multicloud deployment options

Why AI in the Database ?

Traditional AI architectures often rely on multi-tier systems where data is moved from the database to feature stores, vector layers, or external services. This movement introduces complexity, latency, and security challenges.

Oracle’s approach is different:

The database itself becomes a unified platform for data storage, vector computation, intelligence, and AI-driven workflows.

This design delivers benefits in:

Performance: Analytics and AI run where the data resides, reducing round-trip costs.
Security: Data governance and access control are enforced at the database level.
Simplicity: Fewer systems and pipelines to manage.
Scalability: Enterprise workloads can scale with distributed database features.

Key Technical Innovations

Native Vector Search and Multimodal Support

Oracle AI Database 26ai includes built-in support for vector data types, enabling semantic and similarity searches directly within SQL queries. This means you can index and search vectors generated from text, images, or other media without external systems. (Oracle)

Multimodal data becomes first-class: structured tables, JSON documents, graphs, and spatial data can all participate in vector-enabled workflows. (Oracle Docs)

This enables use cases like:

Semantic search across enterprise knowledge bases
Hybrid relational + vector queries
Business logic combined with nearest-neighbor search

Agentic AI Workflows

Oracle AI Database 26ai introduces support for in-database AI agents, frameworks that can execute autonomous or semi-autonomous tasks on behalf of applications. These agents can combine data access, analysis, decision logic, and actions without leaving the data platform. (Futurum)

By making agents part of the database ecosystem, Oracle simplifies complex AI workflows that would otherwise require external orchestration layers.

Unified Lakehouse and Data Fabric

A major component of the 26ai strategy is the Oracle Autonomous AI Lakehouse, which supports open data formats like Apache Iceberg. This brings analytics, data governance, and AI together over large datasets that may reside in data lakes. (Oracle)

The lakehouse capability blurs the traditional lines between OLTP, OLAP, and AI workloads, enabling:

Unified governance
Real-time analytics
Schema flexibility
Efficient storage for large datasets

Developer Productivity and App Development

Oracle AI Database 26ai also focuses on making AI development easier:

Integrated support for AI-enhanced code generation
Built-in APEX enhancements with AI assistant support
JavaScript stored procedures and modern language support
SQL and PL/SQL enhancements for AI-centric logic (Oracle Blogs)

This means developers can build intelligent applications using familiar database tools and languages.

Enterprise Readiness

Oracle has positioned 26ai for mission-critical workloads:

Availability on leading cloud platforms (OCI, AWS, Azure, GCP)
On-premises support with upcoming releases for Linux x86-64
Distributed database capabilities with Raft-based replication
Integrated security, auditing, and governance features
Free and developer editions to experiment with core features

These capabilities make 26ai suitable for large enterprises that need both AI power and operational reliability.

What This Means for Practitioners

For engineers and architects, Oracle AI Database 26ai represents a shift in how we build AI-powered systems:

Move complex AI logic closer to the data
Reduce dependency on external vector databases or feature stores
Leverage a single platform for analytics, AI, and transaction processing
Maintain security and governance at enterprise scale

Adopting AI at the database layer simplifies many traditional challenges in AI pipelines, especially for regulated industries where data governance is critical.

By architectural design, 26ai turns the database from a passive data store into an active AI platform. This represents a significant evolution in database engineering and opens a path for building high-performance, secure, AI-driven applications without complex external stacks.

If you’re exploring AI for enterprise workloads, 26ai is worth serious technical evaluation.

Oracle AI Database 26ai positions the database as an AI execution engine. That claim only matters if it holds up under:

Query planning
Real retrieval pipelines
Operational constraints
Comparison with existing open-source stacks

Let’s validate it properly.

1. EXPLAIN PLAN for Vector Queries (What the Optimizer Actually Does)

A common concern is whether vector search is treated as a first-class citizen or just an expensive function call.

Consider this query:

EXPLAIN PLAN FOR
SELECT doc_id, title
FROM knowledge_base
WHERE category = 'payments'
ORDER BY VECTOR_DISTANCE(embedding, :query_embedding)
FETCH FIRST 5 ROWS ONLY;

Sample EXPLAIN PLAN Output (Simplified)

------------------------------------------------------------
| Id | Operation                 | Name                |
------------------------------------------------------------
|  0 | SELECT STATEMENT           |                     |
|  1 |  SORT ORDER BY             |                     |
|  2 |   VECTOR INDEX RANGE SCAN  | KB_VECTOR_IDX       |
|  3 |    TABLE ACCESS BY INDEX   | KNOWLEDGE_BASE      |
------------------------------------------------------------

Why This Matters

Key observations:

VECTOR INDEX RANGE SCAN is a native access path
Relational predicates (category = 'payments') are applied early
Vector distance calculation is costed by the optimizer
The plan is parallelizable like any other Oracle query

This is fundamentally different from:

External vector DB calls
Post-filtering results in application code
Pulling large candidate sets into memory

In Oracle 26ai, vector search participates in the same optimization framework as joins, filters, and aggregates.

2. End-to-End RAG with OCI Generative AI

Now let’s build a real Retrieval-Augmented Generation flow.

Architecture Overview

Flow:

User submits a natural language query
Application generates an embedding
Oracle 26ai retrieves relevant context securely
Context is sent to OCI Generative AI
Model generates a grounded response

Step 1: Generate Query Embedding

Typically done using OCI Generative AI embedding models.

Pseudo-code (application layer):

query_embedding = generate_embedding(
    model="cohere.embed-english",
    text=user_query
)

Step 2: Secure Context Retrieval in Oracle 26ai

SELECT content
FROM knowledge_base
WHERE VECTOR_DISTANCE(embedding, :query_embedding) < 0.30
ORDER BY VECTOR_DISTANCE(embedding, :query_embedding)
FETCH FIRST 5 ROWS ONLY;

Important points:

Row-level security applies automatically
Masked columns remain masked
Auditing records the access

This step is where most RAG systems fail from a governance perspective. Oracle does not.

Step 3: Call OCI Generative AI with Retrieved Context

Prompt template example:

You are an enterprise assistant.
Answer the question using only the context below.

Context:
{{retrieved_documents}}

Question:
{{user_query}}

The database never exposes unauthorized data, and the model never hallucinates beyond approved context.

3. Oracle 26ai vs PostgreSQL + pgvector Comparison

This comparison is not about ideology. It is about architecture.

Dimension	Oracle AI Database 26ai	PostgreSQL + pgvector
Vector type	Native kernel type	Extension
Query optimizer	Fully vector-aware	Limited cost awareness
Security	Row-level, masking, auditing	Partial, app-driven
RAG governance	Strong	Weak by default
HA and DR	Built-in enterprise-grade	DIY
Operational overhead	Low	Moderate to high
Compliance readiness	High	Depends on setup

Key Insight

pgvector works well for:

Prototypes
Research
Small to medium workloads

Oracle 26ai is designed for:

Regulated enterprises
Mission-critical systems
Large-scale operational AI

The difference is not performance alone.
It is operational correctness under pressure.

4. Production Checklist for AI Databases

Most AI failures are not model failures.
They are architecture and operations failures.

Here is a practical checklist for running AI workloads inside a database.

Data and Schema Design

Choose embedding dimension deliberately
Separate raw text and embeddings
Version embeddings if models change
Normalize metadata for relational filtering

Indexing and Performance

Create vector indexes explicitly
Monitor vector index usage
Validate EXPLAIN PLAN regularly
Use relational predicates to reduce search space

Security and Governance

Enforce row-level security on source tables
Mask sensitive columns before RAG
Enable auditing for AI access paths
Treat embeddings as sensitive data

Operational Readiness

Include vector indexes in backup strategy
Test DR scenarios with AI workloads
Monitor vector query latency separately
Capacity-plan for mixed OLTP + AI workloads

Model and Prompt Hygiene

Store prompt templates in versioned tables
Log prompts and responses for traceability
Use strict system prompts for RAG
Avoid free-form context injection

DevOps and Platform Integration

Treat AI queries as first-class workloads
Add SLOs for AI retrieval latency
Monitor plan regressions after upgrades
Align AI deployments with DB change management

Final Perspective

Oracle AI Database 26ai does not try to replace models. It replaces fragile architecture.

By making vectors, retrieval, security, and optimization part of the database engine, Oracle reduces the number of places AI systems can fail.

For enterprises, this matters more than novelty.

AI is not impressive when it works in a demo.
It is impressive when it works every day, under load, under audit.

Oracle 26ai is clearly designed for that reality.

⚡ RDMA: The Networking Tech That Quietly Runs the Modern Internet

kaustubh yerkade — Sun, 21 Dec 2025 11:40:00 +0000

It’s 2:17 AM.
Your dashboard is green.
CPU usage is low.
Latency graphs look… too good to be true.

Yet your distributed database is pushing hundreds of gigabytes per second across machines.

No magic.
No cheating.

Just RDMA.

first, the uncomfortable truth

Most of us learned networking like this:

“Send data → TCP/IP → kernel → CPU → copy buffers → receive → copy again”

And we accepted it.

But modern systems looked at this and said:

“Why are CPUs doing delivery jobs?”

And that’s where RDMA was born.

What is RDMA ?

RDMA (Remote Direct Memory Access) allows one machine to directly read or write the memory of another machine over the network without involving the remote CPU or OS kernel.

Yes, thats right.

Memory-to-memory communication over the network.

How networking traditionally works ?

When you send data over TCP:

App → Kernel
Kernel → Network stack
CPU handles interrupts
Data copied multiple times
Receiver CPU wakes up
Kernel copies again
App finally gets data

Result:

Good latency
CPU overhead
Cache pollution
Context switching hell

How RDMA works ?

With RDMA:

App tells NIC where memory is
NIC sends data directly
Remote NIC writes straight into RAM
Remote CPU is not disturbed

Result 🚀:

Zero-copy
Sub-microsecond latency
Near-zero CPU usage
Line-rate throughput (100–400 Gbps)

The “wait… what?” moment

The remote CPU doesn’t even know data arrived.

No syscall.
No interrupt.
No kernel involvement.

This is called one-sided communication.

Key RDMA concepts

1. Memory Registration

Memory is “pinned”
NIC gets permission to access it
Prevents OS from moving it

2. Queue Pairs (QP)

Send Queue + Receive Queue
Managed entirely by hardware

3. One-sided ops

RDMA WRITE → write remote memory
RDMA READ → read remote memory
RDMA SEND/RECV → like messaging, but faster

RDMA vs TCP

Feature	TCP/IP	RDMA
CPU usage	High	Almost zero
Memory copies	Many	Zero
Latency	~10–100 µs	< 1 µs
Throughput	Limited	Line rate
Kernel involvement	Required	Bypassed

Where RDMA is ACTUALLY used

This isn’t theory. RDMA powers real systems:

Distributed Databases

In-memory DBs
Sharded OLTP engines

Storage

NVMe over Fabrics
Distributed file systems

AI / ML

GPU-to-GPU communication
Large model training

Finance

High-frequency trading
Real-time risk engines

If something is fast + distributed, RDMA is probably underneath.

RDMA doesn’t mean “new cables”

RDMA runs over existing networks:

Technology	Runs On
InfiniBand	Native RDMA
RoCE	Ethernet
iWARP	TCP/IP

Most cloud data centers use RoCE today.

RoCE Header format-

Examples of RDMA NICs:
Intel: Ethernet 810/820 Series (iWARP & RoCEv2).
Marvell: FastLinQ (Universal RDMA, RoCE & iWARP).
Chelsio: Known for high-performance RDMA adapters.

Why RDMA isn’t everywhere

Because RDMA is powerful but dangerous:

Requires special NICs
Needs lossless networks
Hard to debug
Memory bugs = catastrophic
Not beginner-friendly

RDMA is like giving your NIC root access to RAM.

So, Handle with care

Even if you never write RDMA code:

Your databases use it
Your cloud storage depends on it
Your AI workloads require it
Your latency SLAs benefit from it

Understanding RDMA explains:

Why cloud infra feels “unreasonably fast”
Why CPUs aren’t the bottleneck anymore
Why networking is becoming hardware-driven

The mental model that sticks

TCP/IP =
“Please OS, copy this data safely and let me know”

RDMA =
“Hey NIC, write directly into that memory address over there”

One-line takeaway

RDMA is how modern data centers move data at near-memory speed across machines.

RDMA isn’t hype.
It’s invisible infrastructure. the kind that changes everything quietly.

The next time you see:

insane throughput
suspiciously low CPU
lightning-fast distributed systems

You’ll know.

RDMA is working.

References -
https://wiki.debian.org/RDMA
https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet
https://resource.fs.com/mall/resource/intel-e810-series-ethernet-network-adapters-datasheet-20251125121144.pdf

Google Cloud Platform (GCP) Explained | The Engineer’s Cloud ☁️

kaustubh yerkade — Sat, 20 Dec 2025 06:03:03 +0000

“AWS feels like a supermarket. Azure feels like enterprise paperwork.
GCP feels like... an engineer built it.”

If you’ve ever opened the GCP console and thought:

“This looks clean. but different”
“Why is everything so data centric?”
“Why do Kubernetes and BigQuery feel native here?”

This blog is for you.

Let’s demystify Google Cloud Platform, how it works, why it exists, and why engineers quietly love it.

What is Google Cloud Platform (GCP)?

Google Cloud Platform is Google’s public cloud offering. the same backbone that powers:

Google Search
YouTube
Gmail
Google Maps
Android ecosystem

Unlike other clouds that adapted to scale later, Google was born at planetary scale.

That DNA matters.

GCP’s Philosophy (This Is the Big Difference)

Most clouds say:

“Here’s infrastructure. You manage it.”

GCP says:

“Here’s a distributed system. Don’t worry about servers.”

Core ideas:

Containers first
Data everywhere
Managed > Manual
SRE > SysAdmin

Google doesn’t want you babysitting servers.
They want you shipping systems.

How GCP Is Structured

1. Global Infrastructure

Regions → Zones
Private global fiber network
Same network Google uses internally

Your VM in Mumbai talks to BigQuery in the US without touching public internet

2. Core Layers

Think in layers, not services.

Layer	Purpose
Compute	Run code
Storage	Store data
Networking	Connect everything
Data	Analyze everything
DevOps	Build & deploy
Security	Protect by default

3. Compute: Where Your Code Runs

Compute Engine (GCE)

Virtual machines
Custom machine types
Per-second billing

Google Kubernetes Engine (GKE)

Kubernetes created by Google
Industry gold standard
Auto-scaling, auto-repair, auto peace :)

Cloud Run (Serverless)

Deploy a container
Zero infrastructure thinking
Scales from 0 → millions

If AWS is EC2-first, GCP is Kubernetes first.

Storage & Databases (Google Loves Data)

Cloud Storage

Object storage
Simple, fast, global
Ideal for logs, backups, media

BigQuery - The Star🌟

Serverless data warehouse
Query TBs in seconds
SQL without infra pain

BigQuery feels like cheating, and that’s the point.

Cloud Spanner

Globally consistent SQL database
Horizontal scaling
Used by Google internally

Data Engineering & Streaming (GCP’s Superpower)

🔸 Pub/Sub

Global messaging system
Event-driven architectures
Handles insane throughput

🔸 Dataflow (Apache Beam)

Unified batch + streaming
Managed Flink-like pipelines
No cluster management

If you’re a data engineer, GCP feels like home.

DevOps on GCP (Clean & Opinionated)

🔹 Cloud Build

Serverless CI/CD
YAML pipelines
GitHub / GitLab friendly

🔹 Artifact Registry

Docker, Maven, npm, Python
One registry to rule them all

🔹 Cloud Operations (Stackdriver)

Logs
Metrics
Traces
Alerts

Logging on GCP is ridiculously good.

Security: Quietly Excellent

IAM is resource centric
Default encryption everywhere
Zero Trust mindset
VPC Service Controls

You don’t add security later, it’s baked in.

GCP vs AWS vs Azure (Quick Reality Check)

Area	GCP	AWS	Azure
Kubernetes	Best	Good	Good
Data & Analytics	Best	Good	Average
UI Simplicity	Clean	Cluttered	Corporate
Enterprise Legacy	Meh	Good	Best
Learning Curve	Moderate	Steep	Moderate

Who Should Choose GCP?

Choose GCP if you are:

A DevOps / SRE
A Data Engineer
A Java + Beam + Flink developer
Building event-driven systems
Tired of managing servers

Avoid GCP if:

You need legacy enterprise tooling
You want every service under the sun (AWS wins here)

Why Engineers Fall in Love with GCP

Kubernetes just works
BigQuery changes how you think about data
Clean console
Less ops, more engineering
Google grade infrastructure

GCP doesn’t scream.
It delivers quietly.

Final Thoughts

AWS teaches you cloud.
Azure teaches you enterprise.
GCP teaches you distributed systems.

If you truly want to understand how modern systems are built, GCP is not optional — it’s essential.

Hope you like this introductory post on GCP.
If you want next part, Please let me know in the comments.

Building a Production-Grade Java App on GCP
GCP Data Engineering Pipeline (Beam + Dataflow + BigQuery)
AWS vs GCP Architecture War Stories
How Google Runs SRE Internally

Chaos Engineering: Breaking Production on Purpose (So It Never Breaks Again)

kaustubh yerkade — Sat, 13 Dec 2025 10:00:07 +0000

1. The 2 AM Pager Story

It’s 2:00 AM. You are deep asleep like makka pakka.
Then your phone vibrates like it’s possessed.
Slack is exploding. Grafana dashboards are red.

The message says:

🚨 Production Down - High Error Rate

But wait…
This system was highly available.
Multi-AZ. Auto scaling. Health checks. Load balancers.
All the right boxes were checked.

So what went wrong ?

A single node died.
A cache dependency slowed down.
Retries snowballed.
Threads got exhausted.
And suddenly... everything collapsed.

That night teaches you one painful truth-

Just because a system looks reliable on paper doesn’t mean it survives real failure.

A legend once said- The Best Way to Prevent Outages? Cause Them First.

Welcome to Chaos Engineering.

2. What Is Chaos Engineering ?

One-liner:

Chaos Engineering is the practice of intentionally breaking things to learn how your system behaves under failure.

In simple words:
You don’t wait for outages to teach you lessons.
You create controlled failures on your terms; during working hours so production doesn’t teach you lessons at 2 AM.

Why it exists:

Modern systems are distributed
Failures are inevitable
Humans are bad at predicting edge cases

Chaos Engineering accepts reality instead of fighting it.

3. Why Traditional Testing Is Not Enough

Let’s be honest.

We already do:

Unit tests
Integration tests
Load tests
UAT
Pre-prod validations

And yet production still fails.

Why?

Because traditional testing assumes:

Dependencies behave normally
Networks are reliable
Latency is predictable
Partial failures won’t cascade

In Reality:

Databases slow down, not just crash
Networks lie
Third-party APIs timeout randomly
Distributed systems fail in creative ways

Most outages come from unknown unknowns , not code bugs.

Chaos Engineering is how you discover those unknowns before users do.

4. Core Principles of Chaos Engineering

1. Define Steady State

What does “healthy” look like?

Request success rate
Latency percentiles
Error budgets
Business KPIs

If you don’t define this, you’re just breaking stuff blindly.

2. Inject Real Failures

Not mocks. Not simulations but Real failures like:

Killing pods
Adding latency
Breaking network calls
Throttling CPU

3. Run Experiments in Production (Carefully)

Yes, production.

Why?
Because only production has:

Real traffic
Real data
Real chaos

But this is done:

Gradually
During safe windows
With rollback plans
Scheduled downtimes

4. Automate and Learn Continuously

Chaos is not a one-time stunt.
It’s a continuous feedback loop.

5. Common Chaos Experiments With Examples

Here’s what teams actually break

Kill Pods / Instances

kubectl delete pod payment-service-xyz

Question:
Does traffic reroute smoothly?
Do users notice?

Network Latency & Packet Loss

Add 500ms latency between services
Drop 10% packets

Exposes:

Retry storms
Timeout misconfigurations

Dependency Failures

Database slows down
Redis unavailable
Third-party API returns 500

Reality check:
Can your service degrade gracefully?

Resource Starvation

CPU throttling
Memory pressure
Disk full

These failures are far more common than total crashes.

AZ / Region Failure

Simulate:

One Availability Zone going down
Load balancer losing backends

This is where “multi-AZ” claims are tested.

6. Chaos Engineering in Kubernetes & Cloud

Kubernetes makes chaos easy (sometimes too easy).

Kubernetes Chaos

Kill pods randomly
Drain nodes
Evict workloads
Break DNS

Cloud-Native Chaos

Terminate EC2 instances
Throttle IAM permissions
Break network routes

Popular Tools

Chaos Monkey - OG chaos tool
LitmusChaos - Kubernetes-native, open source
Gremlin - Controlled, enterprise-grade chaos
AWS FIS - Native AWS fault injection

Tools don’t do chaos engineering.
Mindset does.

7. A Short, Realistic Scenario

Setup

Java Spring Boot microservice
Kubernetes (EKS)
HPA enabled
Redis cache + PostgreSQL DB

Chaos Experiment

Kill 50% of pods during peak traffic

What Failed

Connection pool exhausted
Retry logic hammered DB
Latency spiked beyond SLA

What Chaos Exposed

No circuit breaker
Aggressive retries
Poor timeout configuration

What Was Fixed

Added Resilience4j
Tuned retries & timeouts
Improved readiness probes

Result:
Same failure today -> users don’t even notice.

That’s chaos engineering working.

8. Myths & Misconceptions

“1. Chaos engineering is reckless”

No.

Uncontrolled production outages are reckless.

“2. Only Netflix-scale companies need it”

If your system:

Has users
Has SLAs
Has on-call engineers

You need it.

“3. It means randomly breaking things”

Wrong.

Chaos is:

Hypothesis-driven
Measured
Reversible

Random breaking is just… bad ops.

9. When You SHOULD and SHOULD NOT Do Chaos Engineering

You SHOULD when:

Monitoring & alerts are solid
Rollback is easy
Error budgets exist
Team understands the system

You SHOULD NOT when:

You can’t observe failures
You don’t know steady state
You don’t have on-call coverage
Everything is already unstable

Chaos without observability is just noise.

10. Benefits You Actually Get

Not buzzwords. Real outcomes:

Fewer production outages
Faster incident response
Safer deployments
Better system design
Confident on-call engineers

You stop hoping things work.
You know they do.

11. How to Start Chaos Engineering, Beginner-Friendly.

Step-by-Step Starter Plan

Pick one critical service
Define steady-state metrics
Start in non-prod
Kill a single pod
Observe everything
Fix weaknesses
Repeat
Slowly move to prod

First Chaos Experiments

Pod kill during low traffic
Add latency to one dependency
Simulate DB slowness

Small chaos beats no chaos.

12. Conclusion

Chaos Engineering is not about breaking systems.It’s about breaking assumptions.

Failure is feedback.
Ignore it, and production will remind you loudly.

The best SREs and DevOps engineers don’t fear failure.
They schedule it.

Your Turn

If you killed one thing in your production system today,
what do you think would break first?

Drop your thoughts, war stories, or doubts in the comments.
Let’s learn from each other before the pager rings again.

AWS for Developers: The Guide

kaustubh yerkade — Sat, 13 Dec 2025 08:25:44 +0000

Cloud is no longer a “nice to have.” If you are building, scaling, shipping, or even experimenting. AWS is where most of the world runs its production workloads.

But here’s the problem -> AWS has over 200 services. New developers often feel like they’re entering a jungle with no map.

This article is that map.
Short. Concise. Practical.

Let’s go.

Why AWS Still Rules the Cloud

Even with big players like Azure and GCP growing fast, AWS dominates because:

Most complete ecosystem (Compute, Storage, Database, AI, DevOps… literally everything)
Battle tested global infrastructure
Deep enterprise adoption
Strong tooling for DevOps, automation, and infra-as-code
Leader in serverless (Lambda), container orchestration (ECS/EKS), and data engineering

If you're a developer, AWS is more than a cloud provider, it's a career multiplier.

The AWS Big 5:

The Only Services Every Developer Must Know. These are workload services used to run actual applications:

Amazon EC2 - Virtual Machines, Classic Style
Amazon S3 - The Unlimited Storage Bucket
AWS Lambda - Serverless Magic
Amazon RDS - Databases Without the Ops Pain
Amazon DynamoDB - The NoSQL Supercharger

Forget the 200+ service list.
These are the 5 services that drive 80% of real-world applications.

Let's see them one by one -

1. Amazon EC2- Elastic Compute Cloud

The foundational compute service of AWS.

Why it’s top tier:

Runs your applications on virtual servers
Full OS-level control
Autoscaling + Load Balancing support
Best for legacy applications, backend services, batch jobs

Example uses:

Application servers
Backend microservices
Game servers
High-performance web apps

2.Amazon S3- Simple Storage Service

The backbone of modern cloud storage.

Why everyone uses it:
Unlimited file storage
Extremely durable (99.999999999% durability)
Cheap and scalable
Stores everything from images to logs to ML datasets

Example uses:
Static website hosting
Backup & archiving
Data lakes
CI/CD artifacts

3.AWS Lambda- Serverless Compute

Run code without managing servers.

Why it’s a top 5 service:

Only pay when code runs
Scales automatically
Integrates with 200+ AWS services
Ideal for event-driven architectures

Example uses:

API backend
Automation scripts
CRON jobs
Data processing

4.Amazon RDS- Relational Database Service

Managed SQL databases without DBA overhead.

Why it’s essential:

Automated backups
Multi-AZ replication
High availability built-in
Supports MySQL, PostgreSQL, SQL Server, Oracle, Aurora

Example uses:

Banking apps
ERP / CRM systems
Transactional websites

5. Amazon DynamoDB- Fully Managed NoSQL Database

A super-fast, massively scalable NoSQL solution.

Why top companies love it:

Millisecond low-latency reads/writes
Auto-scaling to millions of requests
Zero-downtime operations
Serverless + event-driven

Example uses:

Shopping carts
Gaming state data
IoT device storage
Microservices

AWS Developer Workflow:

How Modern Teams Build Apps on AWS

Here’s what a typical production-grade AWS architecture looks like:

Frontend → CloudFront → S3
API → API Gateway → Lambda/ECS
Database → RDS / DynamoDB
Messaging → SNS / SQS
CI/CD → CodePipeline / GitHub Actions
Infra → Terraform / CDK
Monitoring → CloudWatch / X-Ray

This stack is scalable, fault-tolerant, and cost-efficient.

AWS DevOps Essentials

Infrastructure as Code (IaC)

Tools:
Terraform
AWS CDK
CloudFormation

Using IaC ensures:

Version-controlled infra
Consistent deployments
Automated scaling + repeatability

CI/CD with AWS

Common choices:

AWS CodePipeline
GitHub Actions
GitLab CI
Jenkins on EC2

Typical pipeline:

Build → Test → Security Scan → Deploy → Verify

Monitoring & Logging

CloudWatch Logs & Metrics
AWS X-Ray for tracing
CloudTrail for auditing
OpenSearch for log analytics

Observability is non-negotiable in 2025.

Quick Summery Cheat Sheet

Rank	AWS Service	Category	Why It's Top 5
⭐ 1	EC2	Compute	Full control, flexible, widely used for apps
⭐ 2	S3	Storage	Durable, cheap, global, foundation for many systems
⭐ 3	Lambda	Serverless	Zero server management, event-driven apps
⭐ 4	RDS	Database	Managed SQL, scalable, secure
⭐ 5	DynamoDB	NoSQL	High-speed, fully managed, microservice-friendly

Part 2

How AWS works
What the core services are
How they connect together
A mental model to stop AWS from feeling chaotic

I’ve written this in simple language, with engineering intuition, not marketing fluff.

AWS Without the Headache: A Simple Mental Model That Finally Makes Sense

“AWS is not hard. AWS is too big to explain at once.”

If you’re new to AWS (or even experienced), you’ve probably felt this:

Too many services
Weird names (EC2, IAM, VPC, ALB, EKS... why?)
Every tutorial starts in the middle, never at the beginning

So let’s do something different.

We won’t start with services
We’ll start with how AWS actually works

First: AWS is like a Massive Digital City

AWS is infrastructure, rented by the hour.

Imagine AWS as a city:

City Concept	AWS Equivalent
Land	AWS Regions
Buildings	Data Centers
Electricity	Compute (EC2, Lambda)
Roads	Networking (VPC, Subnets)
Security Guards	IAM
Warehouses	S3
Post Office	SNS / SQS

Once you see this, AWS stops feeling scary.

Regions & Availability Zones -The Foundation

Before any service, AWS gives you geography.

Region

Physical location (Mumbai, Frankfurt, Virginia)
Completely isolated from other regions
A region is basically a cluster of data centers.

Availability Zone (AZ)

One region has multiple AZs
Each AZ = independent data center
Used for high availability

Mumbai region is having 3 AZs -
ap-south-1a -
ap-south-1b
ap-south-1c

Region Code (e.g., us-east-1, ap-south-1): Identifies the broad geographical area (e.g., US East, Asia Pacific) and its specific location.

Letter Suffix (e.g., a, b, c, 1, 2, 3): Designates the individual, physically separate data center within that region, with unique power, cooling, and networking.

Rule of thumb

Deploy across multiple AZs, not multiple regions (unless required).

The Core AWS Building Blocks (90% of AWS)

Most AWS architectures boil down to 5 core pillars.

Compute - “Where Code Runs”

This is your CPU + RAM.

Service	When to Use
EC2	Full control, legacy apps
Lambda	No servers, event-driven
ECS	Simple containers
EKS	Kubernetes workloads

If you understand EC2 + Lambda, you already understand compute.

Storage - Where Data Lives

Service	What It Is
S3	Object storage (files, backups)
EBS	Disk for EC2
EFS	Shared filesystem

Golden Rule

Files / backups → S3
OS disk → EBS

Networking

This is where most people panic

VPC (Virtual Private Cloud)

Your private network inside AWS.

Inside a VPC:

Subnets (public / private)
Route tables
Internet Gateway
NAT Gateway

💡 Simple idea

VPC = Your own data center network, but virtual

4. Security – “Who Can Do What”

IAM (Identity & Access Management)

Controls:

Who can access
What they can do

Key concepts:

Users (humans)
Roles (services)
Policies (permissions)

Never use root user
Always use roles for EC2/Lambda

5. Databases – “Where Structured Data Lives”

Service	Type
RDS	SQL (MySQL, Postgres)
Aurora	Cloud-native SQL
DynamoDB	NoSQL, massive scale

How AWS Services Connect -The Flow

Let’s connect everything with a real example.

A Simple Web App Flow

User hits your website
Route53 resolves DNS
Load Balancer receives traffic
EC2 / ECS / Lambda processes request
Data fetched from RDS / DynamoDB
Files served from S3
Logs go to CloudWatch

Okay....
That’s 80% of AWS architectures.

Why AWS Feels Overwhelming ?

AWS looks huge because:

Every feature is a separate service
Names are technical, not friendly
Docs assume prior cloud knowledge

But underneath…

AWS = Compute + Storage + Network + Security + Database

Everything else is just an add-on.

How I Recommend Learning AWS with a Practical Path

As a DevOps engineer, this is the order that actually works:

EC2
VPC basics
IAM roles
S3
RDS
Load Balancer
Auto Scaling
Then containers & serverless

Don’t start with EKS.
Don’t chase certifications blindly.

Final Thought

AWS is not meant to be learned top-down.
It’s meant to be learned layer-by-layer.

Once you build the mental model, AWS stops being scary
and starts feeling like Lego blocks for engineers

🔥Java Spring Framework & Spring Boot : A simple, no-nonsense guide that actually makes sense

kaustubh yerkade — Fri, 12 Dec 2025 03:26:11 +0000

Spring Framework & Spring Boot quietly run half the world’s backend systems including banking, fintech, telecom, e-commerce, logistics, and even government platforms.

Five'ish years ago, when I first started working Spring project, I was completely confused. Everything felt overwhelming. Annotations, beans, IoC, DI, controllers, configurations…

I still remember the exact moment my manager walked up to me and said:

“Hey, can you build this module on Spring?”

I confidently replied:
“Yes, of course!”
(because saying no felt illegal on day one.)

But inside my head I was like:

“Spring? Which Spring?"

I had already worked with Servlets, JSP, Struts…
I understood MVC…
I had deployed Java apps…

But Spring felt like an alien framework that landed straight from another planet.

When I opened the project on STS, My screen was full of strange things like:

@Autowired
@Controller
@Component
beans
contexts
configurations
application.properties
XML vs annotation
IoC container

And I remember thinking:

“Bro… where is main()?”
“Who is creating objects?”
“What is this magic? Why is nothing obvious?”

I tried reading docs, blogs, StackOverflow. Chatgpt wasn't a thing back then...
But every explanation used even more confusing words:

Inversion of Control
Dependency Injection
AOP
Bean lifecycle
Application context

I still remember the day I managed to create my first @RestController and return "Hello World".

It felt like I had cracked the top secret code.But those early days were full of head-scratching.

Despite knowing the old-school Java concepts like Core Java OOP, Servlets & JSP, Struts, JDBC etc. Spring felt totally different. Even with Java experience, Spring felt like a brand-new world, almost a different mindset.

Over time, after working on real projects, breaking things, fixing things, and understanding the architecture deeply, everything finally clicked. But that learning curve was steep.Long. And honestly… unnecessary.

I’m writing this blog because I don’t want today's beginners to feel the same confusion I had, even though I came from traditional Java technologies, Spring still felt like a big shift.

If you’re new to Spring, I hope this blog becomes the explanation I wish I had 6 years ago.

Why Does Spring Exist?

Before Spring came into the market, Java developers were struggling.
Even if you knew Core Java concepts, building enterprise applications was painful. Everything was tightly coupled , too much XML , hard to test , slower build times. And dependent on heavy J2EE servers (WebSphere, WebLogic). Means Java was powerful, but not developer-friendly.

Imagine you’re building a big Java application using traditional way.
Suddenly you realize:

You are writing too much boilerplate
You’re manually managing objects
You’re copying repetitive code
You’re configuring things every 5 minutes
You’re stressed, tired, and thinking of switching careers

Spring Framework saved devs from this suffering , Spring said:

“Let’s make Java development simple again.”

Rod Johnson wrote a book in 2002 called “Expert One-on-One J2EE Design and Development.”

In that book, he proposed a new, simple approach using:

lightweight containers
dependency injection
POJOs instead of EJBs

This idea became the foundation of the Spring Framework, released in 2003.
The goal was simple:

“Make enterprise Java simpler, more productive, and more enjoyable.”
Spring completely transformed Java by introducing:

Old Java (Before Spring)	With Spring
Heavy EJB containers	Lightweight IoC containers
XML everywhere	Annotations & auto config
Hard testing	Easy unit tests
Manual object wiring	Dependency Injection
Slow, expensive deployment	Fast startup with embedded servers
Strict, rigid design	Flexible, modular architecture

Spring made Java modern, and later Spring Boot made it effortless.

What is the Spring Framework?

The Spring Framework is a set of tools and features that help you build Java applications easily.

The secret superpower of Spring is:

1.Dependency Injection (DI)
Spring says:
“Bro, don’t create objects manually… Let me handle that for you.”

It manages the lifecycle of objects, so your code becomes clean, testable, readable.

2.Inversion of Control (IoC)
Instead of you controlling the app, the framework controls the flow.

You simply tell Spring: “When someone needs a Car, give them this CarService.”

Spring says: “Say less.”

3.A Giant Swiss Army Knife for Java
Spring provides ready to use modules:
Spring MVC → web apps
Spring Data JPA → working with databases
Spring Security → login, JWT, OAuth
Spring AOP → cross-cutting concerns
Spring Test → testing made easy

AND THEN SPRING BOOT ARRIVED !!

What is Spring Boot?

Spring Framework was great but configuring it also felt like assembling IKEA Desk.

Enter Spring Boot (2014).
It changed everything.

Spring Boot =

Spring, but with nitrous included
Zero config
Auto-magic setup
Production ready
Faster than instant noodles

Spring Boot is a framework that helps you build production ready Java apps with minimal configuration.

You don’t need:

❌ xml configuration
❌ server setup
❌ WAR files
❌ complicated deployments

Boot gives you:

✔ Embedded servers (Tomcat, Jetty)
✔ Auto-configurations
✔ Starters for everything
✔ Actuator for monitoring
✔ Easy integration with databases, JMS, Kafka, Redis, etc.

Feature	Spring Framework	Spring Boot
Setup	Heavy	Super light
Configuration	Manual	Auto-config
Packaging	WAR	JAR
Embedded Server	No	Yes
Speed	Slower	FAST FAST!!
Ideal For	Complex, legacy apps	Microservices, cloud, DevOps

Final Thoughts, Why You Should Learn Spring Boot ?

Massive job market
Real-world impact
Clean code
Cloud-first architecture
Future-proof skills

And honestly, it’s fun to build with.....

How to Read & Understand Config Files.

kaustubh yerkade — Sun, 07 Dec 2025 20:52:24 +0000

config files are everywhere.

They decide how your app starts, how your servers run, how your test pipeline behaves, how your Kubernetes pods survive, and sometimes… why your app randomly crashes at 2 AM (because someone used a tab instead of space).

But here’s the truth:

Most of us don’t know how to properly read a config file.
We search for error, guess, trial-and-error and hope for the best.

I am Writing this guide to change that.

Whether it’s .YAML, .JSON, HCL, .INI, Or the og .XML, we’ll learn a universal method to read, understand, debug, and master any configuration file like a pro.

Lets start with basics -

Why Config Files Even Exist

Config files let us separate code from behaviour.

Your code stays clean.
Your logic stays flexible.
Your ops team stays sane.

Examples:

application.properties → Java Spring Boot
values.yaml → Helm chart
terraform.tf → Terraform
config.json → Node.js app
docker-compose.yml → Multi-container setup
nginx.conf → Web Server rules
httpd.conf → Web server rules

Configs = Data, Not Logic

Config files describe things. They don’t execute things.
So when reading a config:

Don’t look for logic. Look for structure.

Don’t guess meaning. Understand relationships.

Don’t treat it like code. Treat it like a map.

How to Read ANY Config File

1.Identify the Format
2.Read Top to Bottom like a Story
3.Identify Sections
4.Look for Dependencies
5.Find Defaults & Overrides
6.Validate Against Documentation
7. Always Check Env-Specific Overrides

1.Identify the Format

Before understanding meaning, understand syntax.
Here’s a quick cheat sheet:

Format	Common Use	What It Looks Like
YAML	Kubernetes, Ansible, GitHub Actions	Indentation is everything
JSON	APIs, Node.js, configs	`{ "key": "value" }`
INI	Legacy apps	`key=value`
Properties	Java apps	`port=8080`
HCL	Terraform	`resource "aws_s3_bucket" {}`
XML	Maven, Android	`<tag>value</tag>`

2.Read Top to Bottom like a Story

All config files have a hierarchy.

server:
  port: 8080
  security:
    enabled: true

Read it as a story:

It’s about a server
Server has a port
Server has a security section
Security has a property called enabled

You're not reading code, you're reading a description.

3.Identify Sections

Most configs contain:

Metadata (version, name)
Inputs (environment, variables)
Rules (policies, limits, resources)
Outputs (final results or settings)

Example: Kubernetes Deployment

metadata:
  name: webapp
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: node:18

Breakdown:

metadata → Label
spec → What to deploy
replicas → How many
template/spec → What runs inside
containers → Which Docker images

Make mental buckets.

4.Look for Dependencies

Some parts depend on others.

services:
  backend:
  frontend:
    depends_on:
      - backend

Understanding dependency flow is crucial.

5.Find Defaults & Overrides

Configs often override inherited defaults.

resources:
  limits:
    cpu: 500m

If something behaves unexpectedly, it's usually:

inherited from elsewhere
overridden somewhere

6. Validate Against Documentation

Never assume meaning. Every config has a reference:

Kubernetes: kube docs
Terraform: registry.terraform.io
Spring Boot: spring-boot-properties list
AWS: official docs

1 misinterpreted parameter = hours of debugging.

7.Always Check Env-Specific Overrides

Prod overrides dev.
Ops overrides engineering.
Secrets override defaults.

Example (application-prod.properties):

db.password=${SECRET_DB_PASSWORD}

Configs are layered. Always check:

.env
values-prod.yaml
overrides.tfvars
secret.yaml

Common Mistakes While Reading Config Files

❌ Using tabs in YAML
YAML hates tabs.

❌ Misunderstanding indentation
Indentation = hierarchy.
Hierarchy = meaning.

❌ Assuming a property exists
e.g., restart: always for Docker is not valid in Kubernetes.

❌ Copy-pasting from StackOverflow
Different environments ≠ same config.

❌ Missing commas in JSON
JSON breaks easily.

Let’s Read a Complex Terraform Block

resource "aws_instance" "web" {
  ami           = var.web_ami
  instance_type = "t3.medium"

  tags = {
    Name = "web-server"
  }

  lifecycle {
    create_before_destroy = true
  }
}

Let's Breakdown:

resource "aws_instance" "web" → This block creates an EC2
ami → Which OS image
instance_type → How big
tags → Metadata
lifecycle → Special behaviour
create_before_destroy = true → Ensure zero downtime

You’re reading infrastructure as a story.

Keep a mental model:
Config = Hierarchical Data Structure

Always validate (YAML lint, JSON lint)
Saves hours.

Document your configs
Future-you will thank you.

Don’t fear big configs
Break them into sections → read → interpret.

Railway.app - DevOps Friendly Deployment Tool

kaustubh yerkade — Sat, 06 Dec 2025 15:18:06 +0000

What if deploying an app was as easy as pushing to GitHub?
Railway heard this… and said: Challenge accepted.

Because nearly every developer & DevOps engineer (especially in Java, Node, Python, Go) hits the same wall:

“Where do I deploy this small project quickly?”
“I don’t want to set up EC2, VPC, ALB, IAM, etc.”
“Why is deployment harder than writing the actual code?”

And suddenly… Railway.app entered the scene.

Its like Heroku 2.0 cleaner, faster, cheaper, and more dev-friendly.

This blog will explain:

What Railway is
Why it is exploding in popularity
Whether it is free or paid
How it compares to AWS/Render/Vercel
Who should use it
A full deployment workflow
And a final verdict (from a DevOps perspective)

Let’s go.

What Exactly Is Railway?

Railway is a cloud deployment platform (PaaS) where you can deploy apps by simply connecting your GitHub repo.

No servers.
No EC2 instances.
No manual Dockerfiles unless you want to.
No “it works on my machine.”

Railway handles:

Build → Deploy → Run → Logs → Metrics

Databases → Secrets → Networking → SSL

Auto deployments on GitHub push

It’s like AWS, but:
without 20 dropdowns
without 100 services to configure
without IAM nightmares
Perfect for busy developers.

Basically Railway is a PaaS abstraction layer, similar to: Heroku, Render , Vercel.

Their goal is to hide the cloud provider and offer developers
Simple deployments , A unified dashboard , Automatic builds and No cloud complexity

You care about your app, not the infrastructure.

*How it works ? *

When you connect a GitHub repo:

Railway clones it
Detects language (Java, Node, Python, Go, etc.)
Auto-generates a Docker container if you don’t have one
Builds the container image
Pushes it to Railway’s private registry
Railway = CI + Docker builder + deployment engine.

Railway schedules your app on managed compute.
Once your container is built, Railway deploys it onto its internal compute layer. This compute layer is not VMs created by Railway, but:

✔ GCP VMs
✔ Kubernetes-like orchestration
✔ Multi-tenant container scheduling
✔ Cloudflare at the edge

Railway focuses on simplicity, hiding everything behind:
GitHub deployment
One-click databases
Auto environment variables
Auto SSL
Live logs
Clean UI

And Isolation is done via:

Linux namespaces
cgroups
Container sandboxing
Kubernetes pod separation

Why Railway Is Becoming the Developer Favourite
1. Ridiculously Simple Deployment

Push → Build → Deploy → URL ready.
No YAML. No infra. No pain.

2. Automatic Dockerization

Even if you don’t write a Dockerfile, it will build one for you.

Amazing for Node, Python, Java, Go, Rust.

3. Built-in Databases

Click → Create PostgreSQL / MySQL / Redis
And Railway injects their connection strings automatically.

4. Logs, Metrics & Live Terminals

No more SSHing into servers.
Everything is on one beautiful dashboard.

5. CI/CD without configuring CI/CD

Every GitHub push becomes a deployment.
Zero setup.

Is Railway Free or Paid? (Breakdown)

Railway has two sides:

FREE (Trial/Starter Credits)

New users get $5 free credits
Some user gets ~$1 free credits/month

Good for:

**- Prototypes

Hackathon projects
Testing APIs
Learning DevOps workflows**

But not enough for production.

PAID (Usage-Based Pricing)

Starts at $5/month (Hobby Plan)

You pay for:

CPU
RAM
Storage
Bandwidth

Still way cheaper and simpler than AWS for small projects.

✔ Perfect for side projects
✔ Perfect for indie devs
✔ Perfect for POCs
✘ Not ideal for big enterprise workloads

Railway vs AWS vs Render vs Heroku

Feature	Railway	AWS	Heroku	Render
Ease of Use	⭐⭐⭐⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐⭐
Free Tier	Limited	Good	None	Limited
Deployment Speed	Fastest	Slow	Medium	Fast
DB Setup	1-click	Complex	1-click	1-click
Logs & Metrics	Built-in	Requires setup	Built-in	Built-in
Best For	Devs, startups	Enterprises	Students, hobbyists	Small production apps

How to Deploy an App on Railway (Step-by-Step)

Here’s how deploying a Java Spring Boot, Node.js, or Python Flask app looks:

1. Push Your Code to GitHub

Railway works best when connected to GitHub.

2. Click “New Project → Deploy from GitHub Repo”

Railway auto-detects:

Language
Framework
Build tool
Start command
No config needed.

3. Add Environment Variables

Everything is managed through a simple UI.

4. Add a Database (Optional)

Click → PostgreSQL → Done.
Railway injects DATABASE_URL automatically.

5. Watch the Build Logs

It builds your code in the cloud.

6. Get Your Live Production URL

You're app is deployed. In minutes. No infra.

Why DevOps Engineers Should Care

Railway is becoming the ultimate prototyping and lightweight hosting platform best for -

✔ Microservices
✔ Event-driven jobs
✔ CI/CD experiments
✔ API services
✔ ML inference micro-apps
✔ MVP deployments
✔ Bootstrapping startup ideas

Railway will save you hours and help you ship faster.

https://railway.com/
https://docs.railway.com/
https://blog.railway.com/

Bounty Program - https://station.railway.com/

Let me know you thoughts.......

Forem: kaustubh yerkade

I Built an AI-Powered Infrastructure Documentation Generator Using GitHub Copilot CLI

What I Built

Demo

My Experience with GitHub Copilot CLI

Linux Internals Everyone *Must* Understand

Linux Internals Every DevOps Engineer Must Understand

1. Linux File System Internals: /proc & /sys

/proc – Process & Kernel Runtime View

/sys – Hardware & Driver Control Layer

2. Process Lifecycle: fork → exec → zombie

The Lifecycle

Zombies (are Not Horror, Just Bad Parenting)

3. Memory, CPU & Load Average (The Most Misunderstood Topic)

Load Average ≠ CPU Usage

Memory: Why “Free” Lies

Real Debug Workflow

4. Networking Basics: Ports, Sockets & Reality

Port ≠ Process

Connection States You Must Know

5. Permissions & SELinux (Where “It Works on My VM” Dies)

Linux Permissions Refresher

SELinux (Mandatory Access Control)

6. systemd: The Real Init System

systemd Is More Than “service start”

Why DevOps Love systemd

How they Evaluate This Knowledge

The "Aha!" Moment: Why Understanding the JVM Changed How I Write Java

I Used Java for Years, Then I Finally Understood the JVM

The JVM Is Not “Java Runtime”

It’s a whole Runtime Operating System

From Code to CPU: What Actually Happens

ClassLoaders: The Hidden Source of Insanity

JVM Memory: Why “Just Increase Heap” Is Bad Advice

JVM Memory ≠ Heap

Why Bigger Heap Can Make Things Worse

Garbage Collection: Not About Speed but About Predictability

JIT Compilation: Your Code Changes While Running

Threads, CPU, and the Illusion of Parallelism

Why JVM Apps sometimes Fail in Production ?

The JVM Debugging Toolkit (Minimal, Powerful)

The JVM (If You want Remember Only One Thing)

Conclusion

A 5 Minute GC Log Walkthrough (That Actually Helps)

1. Enable GC Logging (Modern JVM)

2. A Real GC Log Line (Simplified)

3. How to Read It (Left → Right)

4. What Healthy GC Looks Like

5. Red Flags to Watch For

6. One Golden Rule

7. When GC Logs Save Production

Building a Global Scale App in 2026: Treating Zero Latency as a Lie (Here’s What Actually Works)

The Hard Truth (Let’s Get This Out of the Way)

The 2026 Model

High-Level Architecture (2026 Edition)

Three layers. No more.

1. Frontend: Static Is the New Fast

What winning teams do:

Why?

2. Edge Compute: The Real Backend

What belongs at the edge:

What doesn’t:

3. Data Strategy: Latency Lives Here

Common mistake

The cool 2026 approach: Data by behavior

4. APIs: Fewer, Bigger, Lazier

Modern API rules:

5. Caching: Your #1 Performance Tool

6. Designing for Failure (Lessons from 2025)

2026 design rules:

7. Cost Optimization (Because Finance Is Watching)

A Realistic 2026 Stack (Example)

Final Takeaways

Closing Thought

Oracle AI Database 26ai in Production

Oracle AI Database 26ai: Redefining the Database for the AI Era

What Is Oracle AI Database 26ai?

Why AI in the Database ?

Key Technical Innovations

Native Vector Search and Multimodal Support

Linux Internals Everyone Must Understand

1. Linux File System Internals: `/proc` & `/sys`

`/proc` – Process & Kernel Runtime View

`/sys` – Hardware & Driver Control Layer