Forem: Sreekanth Kuruba

DevOps vs Platform Engineering in 2026

Sreekanth Kuruba — Wed, 15 Apr 2026 12:29:40 +0000

DevOps transformed how teams build and ship software.
It helped organizations move faster with automation, CI/CD, and shared ownership.

But as companies scale across countries and teams, new challenges start to appear.

What worked for small teams doesn’t always work at global scale.

Why Global Companies Are Quietly Shifting

Main Theme:
At global scale, traditional DevOps starts to crack. Platform Engineering is the next evolution that makes DevOps truly scalable, consistent, and effective across countries and large teams.

Imagine this:

A company has engineering teams in India, the US, Europe, and Singapore.
Hundreds of developers working across time zones.

Yet, releasing even a small feature still takes weeks — not because the developers are slow, but because they’re stuck fighting:

Setting up environments
Fixing inconsistent CI/CD pipelines
Waiting for approvals
Dealing with tool chaos across teams

👉 This is the reality when traditional DevOps tries to scale internationally.

🧩 What DevOps Solved — And Where It Breaks at Global Scale

DevOps was revolutionary. It brought developers and operations together through:

Automation & CI/CD
Infrastructure as Code (IaC)
Shared responsibility (“You build it, you run it”)

It works beautifully for small and mid-sized teams.

But here’s the uncomfortable truth:
👉 At large scale, many developers become part-time infrastructure managers instead of product builders.

At global enterprise scale, DevOps starts showing serious cracks:

Every team picks different tools → massive tool sprawl
Same problems get solved repeatedly
Compliance and regulations (GDPR, data sovereignty, etc.) become extremely hard to manage
Developers waste more time on infrastructure than on actual features
DevOps fatigue kicks in — frustration, burnout, and slower delivery

🏗️ Platform Engineering: The Next Evolution

Here’s the sharper truth:
While DevOps focuses on collaboration, Platform Engineering focuses on developer productivity at scale.

Think of it like this:

DevOps = Every team manages their own kitchen
Platform Engineering = One professional central kitchen with ready tools, standard recipes, and built-in safety

So developers can stop worrying about setup and just focus on cooking great features.

⚙️ What Platform Engineering Actually Delivers

A dedicated platform team builds an Internal Developer Platform (IDP) that offers:

🚀 Self-service environment creation (minutes instead of days/weeks)
🛤️ “Golden Paths” — safe, standardized, and recommended workflows
🔐 Security, compliance, and observability built-in by default
🧭 A clean developer portal for easy self-service

👉 Often powered by tools like Backstage, Crossplane, along with core DevOps tools.

Result: Developers get guided freedom instead of complete chaos or total restriction.

⚖️ DevOps vs Platform Engineering – Clear Comparison

Aspect	DevOps	Platform Engineering
Main Focus	Collaboration between Dev & Ops	Developer productivity & experience at scale
Ownership	Shared by all teams	Dedicated platform team
Approach	Flexible (every team does it their way)	Standardized with smart guardrails
Best Suited For	Small to mid-size teams	Large global organizations
Key Metric	Deployment frequency & speed	Time saved + Developer Experience (DevEx)

One-line summary:
DevOps gives freedom.
Platform Engineering gives freedom that actually scales globally.

🌍 Why Global Companies Are Making This Shift in 2026

At international level, complexity explodes — multi-cloud setups, different regulations, time zone differences, and 100+ engineering teams.

Platform Engineering solves these by:

Drastically reducing repetitive work and cognitive load
Bringing consistency across countries and clouds
Making security & compliance automatic
Improving developer happiness and retention
Delivering faster feature delivery with lower risk

👉 This is exactly why Platform Engineering roles are becoming some of the highest-paying and most strategic positions in 2026.

⚠️ Challenges & Smart Way to Adopt

It’s not effortless. Common pitfalls:

Building the platform without real developer feedback
Making it too rigid
Ignoring legacy systems

Better approach:

Start small (fix one major pain point first)
Treat developers as customers
Iterate continuously based on feedback

🧭 What Should You Learn?

If you're an engineer (especially aiming for global or remote opportunities):

Step 1: Master DevOps fundamentals
→ Docker, Kubernetes, Terraform, CI/CD

Step 2: Level up to Platform Engineering
→ Internal Developer Platforms (IDP)
→ Developer portals (e.g., Backstage)
→ Developer Experience (DevEx) mindset

💡 Pro tip: Build even a small internal platform project — it gives you a massive edge in interviews and LinkedIn.

🔮 Final Thought

DevOps is not going away.

But the companies winning in 2026 are not just “doing DevOps”.
They are building Platform Engineering on top of it — turning DevOps into something scalable, structured, and developer-first at global scale.

👉 The future is DevOps made effortless through smart platforms.

💬 What about you?

What is the biggest time-waster in your current DevOps setup?

Environment setup delays?
CI/CD issues?
Too many tools?

Drop your real experience in the comments — curious to see what teams are struggling with most 👇

Types of APIs Explained: REST, GraphQL, gRPC & SOAP (With Real-World Examples)

Sreekanth Kuruba — Thu, 09 Apr 2026 12:07:06 +0000

Types of APIs Explained: REST, GraphQL, gRPC & SOAP (With Real-World Examples)

When beginners start learning APIs, they usually think there’s only one kind:

“Send a request → Get a response.”

But in reality, there are multiple types of APIs, each built for different purposes — speed, flexibility, security, or simplicity.

In this guide, you’ll learn the main types of APIs with simple explanations, code examples, and real-world use cases.

🧠 What is an API? (Quick Recap)

An API (Application Programming Interface) is a set of rules that allows different software systems to communicate with each other.

One system sends a request → another system processes it → and returns a response.

The style and protocol of this communication decide the type of API.

🔹 Main Types of APIs by Architecture Style

1. REST APIs – The Most Popular Type

REST (Representational State Transfer) is the most widely used API style in 2026.

It uses standard HTTP methods:

GET – Fetch data
POST – Create new data
PUT / PATCH – Update data
DELETE – Delete data

Example:

GET /users/1

Response:

{
  "id": 1,
  "name": "Sreekanth",
  "email": "sreekanth@example.com"
}

Best For: Public APIs, mobile apps, and web applications

Popular Examples: Stripe, Razorpay, GitHub, Google Maps

Why it’s popular: Simple, scalable, and works everywhere.

2. GraphQL – Get Exactly What You Need

GraphQL solves a major problem of REST called over-fetching.

Instead of getting extra data, the client can request exactly the fields it needs.

Example Query:

{
  user(id: 1) {
    name
    email
    posts {
      title
      createdAt
    }
  }
}

Best For: Modern frontend and mobile apps

Popular Examples: Facebook, Shopify, GitHub, Airbnb

Big Advantage: Faster responses and better control for developers.

3. gRPC – The Fastest for Microservices

gRPC is a high-performance framework developed by Google.

It uses Protocol Buffers (binary format) instead of JSON, making it much faster and lighter.

Key Strengths:

Extremely fast and low latency
Smaller data size
Strongly typed
Supports streaming

Best For: Internal microservices communication and high-traffic systems

Popular Examples: Uber, Netflix, Google, Kubernetes

When to choose gRPC: When you need maximum speed between services.

4. SOAP – The Secure Enterprise Option

SOAP (Simple Object Access Protocol) is an older but still important protocol, especially in large organizations.

It uses XML and has strong built-in security features.

Still Used In:

Traditional banking core systems
Government and highly regulated industries

Important Note for India:

Modern systems like UPI, BBPS, and most fintech apps primarily use REST APIs with ISO 20022 standards. They have largely moved away from SOAP for better speed and flexibility.

🔹 Types of APIs by Access Level

Public APIs → Open to everyone (Example: Weather API, Google Maps)
Private/Internal APIs → Used only inside a company
Partner APIs → Shared with specific business partners

🔄 Real-World Architecture Insight

Most modern applications use a hybrid approach:

External-facing (apps & websites) → REST or GraphQL
Internal microservices → gRPC (for high speed)
Legacy systems → SOAP (for security & compliance)

In India’s fintech ecosystem:

UPI and public integrations → REST APIs
High-volume internal services → gRPC
Old core banking systems → Often still use SOAP or hybrid setups

🎯 Final Takeaway

There is no single best API type — each has its own strengths:

REST → Best for simplicity and wide compatibility
GraphQL → Best for flexibility and precise data fetching
gRPC → Best for speed and microservices
SOAP → Best for security in enterprise environments

Understanding these types of APIs helps you design better systems and choose the right tool for every situation.

💬 Your Turn:

Which type of API have you used the most?

Which one do you want to learn next?

Drop your answers in the comments below! 👇

API Explained: From Basics to Real-World Systems (UPI Deep Dive)

Sreekanth Kuruba — Wed, 08 Apr 2026 07:21:54 +0000

When you send ₹100 using PhonePe or Google Pay, it feels instant.

But behind that single tap, multiple systems communicate in real time across different banks.

👉 This seamless communication is powered by APIs.

🧠 What is an API?

An Application Programming Interface (API) is a set of rules that allows one software system to request another system to perform an action and return a result.

In simple terms:

Request → Process → Response

🍽️ Simple Analogy

Think of a restaurant:

You → Client
Waiter → API
Kitchen → Backend

You don’t enter the kitchen yourself

You just place an order, the waiter handles everything, and you get your food

APIs work exactly the same way between different systems.

🔍 Types of APIs (Quick Overview)

REST APIs — Most common (uses HTTP methods: GET, POST, PUT, DELETE)
GraphQL — Client decides exactly what data it needs
gRPC / SOAP — Used in high-performance or enterprise systems

In this blog, we’ll mainly focus on REST APIs, as they power most modern applications including UPI.

⚙️ Basic API Example

Here’s a very simple API call:

GET /users/1

Response:

{
  "name": "Sreekanth",
  "role": "DevOps Engineer"
}

The client requests data → the server processes it → and sends back the response.

📲 Real-World Example: UPI Payment Flow

Let’s see what actually happens when you send ₹100:

App → Payer Bank → NPCI → Payee Bank → Response

Step-by-step:

App collects amount + UPI PIN (encrypted)
App sends a secure API request to your bank
Your bank validates:
- UPI PIN
- Account balance
- Daily limits
Request is forwarded to NPCI (National Payments Corporation of India)
NPCI routes the request to the payee’s bank
Payee’s bank credits the amount
Success response flows back to both apps

👉 Total time: Usually under 2–3 seconds ⚡

Here’s the high-level UPI transaction flow:

Another clean view of the UPI flow:

And a simplified version showing Payer PSP → NPCI → Payee PSP:

🔔 When Things Are Not Instant (Webhooks)

Sometimes the bank takes longer.

Instead of waiting:

Transaction marked Pending ⏳
Bank/NPCI sends a Webhook callback 🔔 once completed

👉 Think of it as:
“Don’t call us, we’ll call you.”

This makes systems asynchronous and scalable.

⚙️ Sample UPI API Request

POST /v1/payments/upi HTTP/1.1
Host: api.phonepe.com
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "amount": 10000,           // in paise (₹100)
  "payeeVpa": "friend@oksbi",
  "remarks": "Lunch money",
  "txnId": "txn-12345"       // used for idempotency
}

Response:

{
  "status": "SUCCESS",
  "transactionId": "UPI987654321",
  "responseCode": "00"
}

🧩 API Request/Response Lifecycle (End-to-End Flow)

Every API call follows a clear lifecycle. Here’s what happens from the moment the request is sent until the response is received:

🔧 What Happens Inside the Backend

When an API receives a request, it goes through several important layers:

API Gateway – Handles rate limiting & routing
Authentication – JWT, OAuth2, or API keys
Input Validation – Checks request format and data
Business Logic – Balance check, fraud detection, rules
Database Operations – Secure debit/credit (ACID transaction)
External API Calls – To NPCI or other banks
Logging & Monitoring – For debugging and observability
Response – Sent back to the client

👉 To prevent duplicate payments, systems use idempotency keys (txnId).

🏦 Why ACID Matters in Payments

Banking systems rely on ACID properties:

Atomicity: Either full transaction happens or none
Consistency: Total money remains correct
Isolation: Millions can transact simultaneously safely
Durability: Once success is returned, it’s permanent

👉 This ensures no “money lost” scenarios.

🔄 Microservices Architecture

Modern apps like PhonePe are not built as one single block. They are divided into independent microservices:

User Service
Payment Service
Notification Service
Fraud Detection Service

These services talk to each other using internal APIs or message queues.

This makes systems scalable and fault-tolerant

⚡ Scaling APIs for Millions of Transactions

Apps like PhonePe and Google Pay handle crores of transactions every day using:

Load balancing
Horizontal scaling (Kubernetes)
Caching (Redis)
Message queues (Kafka)
Rate limiting
Circuit breakers

🎯 Final Takeaway

APIs are not just a technical concept — they are the invisible engine behind everything:

Sending money 💰
Logging in 🔐
Fetching data 📊

Once you understand APIs,
you start seeing the architecture behind every app you use.

Why "Just Restart It" Stopped Working

Sreekanth Kuruba — Tue, 24 Mar 2026 07:58:32 +0000

Why "Just Restart It" Stopped Working

A eulogy for the universal debugging technique

The Universal Truth

Every engineer has said it.

Every engineer has heard it.

Three words that have debugged more systems than all monitoring tools combined:

"Have you tried restarting it?"

It worked for decades. So well we turned it into a meme. A joke. A badge of honor.

"Did you turn it off and on again?"

We laughed because it was true.

When Restarting Made Sense

Once upon a time, a server was a physical thing.

One machine. One process. One problem.

When something broke:

Service stops responding
→ SSH into the box
→ ps aux | grep myapp
→ PID still there? Process hung?
→ kill -9 PID
→ ./start-myapp.sh
→ Everything works again

Total time: 2 minutes
Total stress: Minimal
Total sleep lost: None

Why did this work?

Because the problem was usually temporary.

A memory leak. A deadlock. A bad connection that timed out wrong.

The code had a bug, sure. But restarting reset the state to before the bug happened.

It wasn't elegant. It wasn't permanent.

But at 3 AM, that's all anyone cared about.

The First Sign of Trouble

Then we got more servers.

One box became ten.

Ten became a hundred.

Restarting stopped being a single command.

It became a deployment.

for server in $(cat servers.txt); do
    ssh $server "systemctl restart myapp"
done

This worked. Mostly.

Until the day it didn't.

The Cascade

I watched this happen once.

02:15 - Pager: "Database connections failing"

The on-call engineer checks the logs.

Database is overwhelmed. Too many connections.

The solution, burned into muscle memory from years of single-server debugging:

"Restart the database."

One command. One mistake.

systemctl restart postgresql

The database came back in 45 seconds.

In those 45 seconds:

All 200 application servers lost their connection pools
All 200 retried simultaneously, using identical retry logic
All 200 failed their health checks
The load balancer marked them all unhealthy
The site went down

The database was fine.

The app servers were fine.

The connections were gone.

The restart fixed nothing and broke everything.

One restart.

47 minutes of downtime.

Why Restarting Broke

Restarting worked when:

State lived in one place
Dependencies were simple
Recovery was faster than finding root cause

Restarting broke when:

State moved to databases, caches, message queues
Services started calling other services
"Just restart it" became "restart everything in the right order with the right delays and pray"

A restart is no longer a local action.

It's a distributed event.

You don't restart one thing.

You restart a graph of dependencies.

What Happens When You Restart Now

You restart Service A
↓
Service A disconnects from database
↓
Database releases locks
↓
Service B loses connection to Service A
↓
Service B retries aggressively
↓
Retries overwhelm Service C
↓
Service C crashes
↓
Everything is on fire

All because you restarted "just one thing."

The Lie We Tell Ourselves

"Restarting is harmless."

It isn't.

Every restart is:

A forced state reset
A connection teardown
A potential cascade trigger
A temporary partial outage (even if small)

We accepted restarts as "free" because the cost was invisible.

Until it wasn't.

What Replaced Restarting

The industry didn't ban restarts.

It made them unnecessary.

Health checks

Detect problems before users do.

# Kubernetes liveness probe example
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

If service unhealthy, don't send traffic
Let it recover or replace it
Users never see the failure

Graceful degradation

Fail partially, not completely.

Cache down? Serve stale data
Database slow? Queue writes, serve reads
Something broke? Everything else keeps running

Automatic replacement

Never restart. Always replace.

Pod dies? New one starts
Node fails? Pods move
Same binary. Clean state. No cascade

Rolling restarts

One at a time, with verification.

Restart server 1 of 10
Wait for health check
Restart server 2 of 10
Never lose capacity

The Systems That Don't Need Restarts

Netflix doesn't restart. It terminates and replaces.

Google doesn't restart. It shifts load and repairs.

Your bank doesn't restart. It fails over to another region.

These aren't magic.

They're design choices.

They assumed from day one that "restart" was not a strategy.

The Honest Confession

I still say "have you tried restarting it?"

Sometimes it's the fastest path to it works now.

But I don't pretend it's a fix anymore.

It's a diagnostic.

A temporary patch.

A way to buy time until the real problem reveals itself.

The difference is:

I know the difference now.

What You Can Do Monday

For your most critical service:

Find the last time it was restarted
Ask: "Why did that restart happen?"
Ask: "Could we have avoided it?"

If yes, build the automation.

If no, document why (so next time you know).

For your next outage:

Resist the restart reflex
Check dependencies first
Check connections second
Check logs third
Restart only when you understand what you're about to break

The Question

When was the last time you restarted something

and didn't know exactly what would happen when it came back?

Be honest.

This is part of a series on operations in the age of distributed systems. Next up: "The Pager Should Not Exist."

From Process Management to State Reconciliation

Sreekanth Kuruba — Tue, 24 Feb 2026 03:09:46 +0000

I used to restart servers at 2AM… Kubernetes made that job disappear

02:15 AM — Pager goes off
“nginx is down on web-01”

You wake up.
Grab your laptop.
SSH into the server.
Run a few commands. Restart the process.

02:22 AM — It’s back.

Try to sleep again.

This used to be normal.

Then Kubernetes changed the rules.

🧱 The old world: Process-driven operations

Before Kubernetes, everything revolved around processes.

A service was:

A Linux process
Running on a specific machine
Identified by a PID
Restarted manually (or via basic supervisors)

The assumptions were simple:

Machines are stable
Failures are rare
Humans fix problems

And when something broke…
👉 you fixed it

Availability depended on:

How fast someone could wake up and respond.

🐳 Containers helped… but didn’t solve the real problem

With tools like Docker, things improved:

Consistent environments
Faster deployments
Fewer “works on my machine” issues

But let’s be honest…

If a container crashed:

Maybe it restarted
Maybe it didn’t

If the node died?

You’re still in trouble

If dependencies failed?

Still your problem

👉 Containers improved portability
👉 They did NOT guarantee reliability

🔄 Kubernetes changed the question

Kubernetes doesn’t ask:

“Is this process running?”

It asks:

“Is the system in the state I declared?”

That’s a massive shift.

Instead of managing processes…
you define desired state.

⚙️ The magic: State reconciliation

You declare:

“I want 3 replicas”
“They should always be running”
“They should be healthy”

Kubernetes continuously checks:

Current state
Desired state

If something breaks…
👉 it fixes it automatically

Not later.
Not after a pager alert.
Continuously.

🔄 Traditional vs Kubernetes minds

🧠 Why Kubernetes doesn’t care about PIDs

In traditional systems:

PID = identity

In Kubernetes:

PID = irrelevant

Because a PID is:

Local to a machine
Temporary
Lost on restart

Kubernetes doesn’t track processes.

It tracks:

Desired outcomes

You don’t ask:

“What’s the PID?”

You ask:

“Do I have 3 healthy pods?”

👉 That’s the difference between instance thinking and system thinking

💥 The real shift: Replace, don’t repair

Old mindset:

Fix the broken process

New mindset:

Replace it

👉 Failure is handled through replacement, not repair.

Kubernetes doesn’t try to “save” things.

It simply ensures:

The system matches your declared state

🧪 Jobs are different too

Before:

Run jobs manually
Monitor externally
Retry manually

Now:

Define a Job
Kubernetes ensures completion
Retries automatically
Tracks success/failure

👉 You define intent.
👉 System enforces outcome.

⚠️ Failure is not an exception anymore

At scale, failure is constant.

Systems like Google’s Borg (Kubernetes’ ancestor) proved this:

Machines fail
Networks break
Processes crash

Not if
But how often

Kubernetes is built for this reality.

It assumes:

Nodes will disappear
Pods will die
Networks will glitch

And it’s okay with that.

🔁 What actually changed?

Before Kubernetes:

You maintained systems
You fixed failures
You reacted

After Kubernetes:

You define intent
The system maintains itself
Recovery is automatic

👉 Your job shifts from:
operator → system designer

🏁 Final thought

Kubernetes doesn’t remove failure.

It removes panic.

The system doesn’t ask:

“Who will fix this?”

It asks:

“What should this look like?”

And then it makes it happen.

💬 Your turn

What’s the last thing you had to fix manually at 2AM?

And could Kubernetes have handled it for you?

How Platform Engineering Changes the Game

Sreekanth Kuruba — Tue, 27 Jan 2026 14:45:50 +0000

DevOps isn't dying.

But the "central DevOps team doing everything" model is hitting limits at scale.

Here's what's replacing it — and why it works.

🧱 What Platform Teams Actually Build

(Not just theory)

1. Internal Developer Platforms (IDPs)

Single control plane for deployments, from dev → prod
Example: Backstage (Spotify), Internal Developer Portal
Result: 60% less time spent on deployment setup (Humanitec data)

2. Golden Paths, Not Guardrails

Pre-approved Terraform modules for AWS/GCP/Azure
Standardized K8s configurations with sane defaults
Security/compliance baked in, not bolted on
Outcome: 83% faster infra provisioning (Gartner)

3. Self-Service, Not Ticket-Based

Developers deploy via UI/API/Git push — no tickets
Automated approval workflows replace manual reviews
Impact: 10x more deployments with same team size

🏢 Real-World Example: Amazon's "You Build It, You Run It"

The famous mandate works because of the invisible platform:

What developers see:

git push → running service
Built-in monitoring, logging, alerting
One-click rollback, canary deployments

What platform provides:

CodePipeline templates (not custom Jenkins)
CDK constructs (not raw CloudFormation)
Internal service catalog
Standardized observability stack

The result:

150M+ deployments/year
Teams deploy thousands of times daily
No central bottleneck

⚙️ The Tooling Shift

OLD DevOps Stack:

Jenkins → Ansible → Custom scripts → Slack alerts → Manual dashboards

NEW Platform Stack:

Backstage (UI) → ArgoCD (GitOps) → Crossplane (Control Plane)

→ OpenTelemetry (Observability) → Internal APIs

Key difference:

Declarative over imperative
Git as source of truth for everything
API-first everything

📊 The Numbers Don't Lie

Companies with mature platforms report:

50% less production incidents (DORA)
75% faster mean time to recovery (MTTR)
40% less time spent on "keeping lights on"
3x more developer satisfaction (SPACE metrics)

🤖 Where AI Actually Helps Today

Not: "AI will write your Terraform"

But: "AI explains why your deployment failed"

Useful patterns right now:

AI-driven failure analysis in CI/CD logs
Cost optimization suggestions for cloud resources
Security misconfiguration detection
Documentation generation from code changes

Still needed:

Platform engineers to design the systems AI operates on
Human judgment for architecture decisions
Cultural change management

🚨 The Hard Parts (Nobody Talks About)

1. Platform adoption isn't automatic

Need developer buy-in
Must be better than the DIY alternative
Requires investment in UX

2. Platform teams get it wrong when:

They build what they think devs need (not what they actually need)
They create another complex tool (instead of simplifying)
They over-standardize and kill innovation

3. Success metrics are tricky

Not: "How many services use our platform?"
But: "How much faster can teams ship?"
And: "How many outages did we prevent?"

🎯 The Real Shift

From:

"Submit a ticket, wait 3 days, get your dev environment"

To:

"Click button, get environment, start coding in 5 minutes"

From:

"Ops owns stability, Dev owns features" (siloed)

To:

"Teams own their services, platform provides safety nets" (aligned)

💡 If You Remember One Thing

Platform engineering isn't about building tools.

It's about reducing cognitive load for developers.

The best platform is the one developers don't even notice —

because it just gets out of their way.

🔍 Are you building or using an internal platform?

What's the ONE thing that made it successful (or painful)?

Companies like Spotify (with Backstage) and Netflix scaled DevOps exactly this way — by building platforms instead of doing everything centrally.

Sreekanth Kuruba — Tue, 06 Jan 2026 12:00:40 +0000

Sreekanth Kuruba

Jan 6

Why Traditional DevOps Stops Scaling

#discuss #devops #platformengineering #career

Comments

2 min read

Why Traditional DevOps Stops Scaling

Sreekanth Kuruba — Tue, 06 Jan 2026 06:06:56 +0000

Traditional DevOps works well…
until the organization grows.

At small scale, a central DevOps team deploying, fixing, and firefighting everything feels efficient.

At large scale, it becomes the bottleneck.

And not because DevOps is bad.
Because humans don’t scale the same way systems do.

🚧 Why Traditional DevOps Stops Scaling

1. People become the bottleneck
As companies grow, everyone needs DevOps help.
Deployments. Pipelines. Terraform. Kubernetes.

Senior DevOps engineers are expensive and hard to hire.
Soon, the DevOps team becomes a ticket queue instead of an enabler.

2. Toolchains turn into spaghetti
CI tools, CD tools, scanners, monitors, secrets managers.

Each one solves a problem.
Together, they create complexity.

Maintaining fragile integrations slows teams down more than it helps them move fast.

3. Manual steps creep back in
Approvals, one-off fixes, environment-specific configs.

Manual work means:

Inconsistency
Errors
Late-night outages

Manual processes don’t scale. They multiply risk.

4. Developers carry too much operational weight
“You build it, you run it” sounds great.

But without the right abstractions, developers become:

Accidental infrastructure experts
Part-time SREs
Slower feature builders

Cognitive load goes up. Velocity goes down.

5. No self-service = no speed
Without self-service platforms, developers must touch:

Kubernetes YAML
Terraform internals
Cloud primitives

Instead of shipping features, they wrestle with infrastructure.

6. Silos quietly return
Even with DevOps intentions, silos reappear:

Ops rewarded for stability
Dev rewarded for speed

Different incentives. Same old friction.

7. Monitoring stays reactive
Traditional monitoring reacts after things break.

At scale, teams need:

Proactive observability
Fast root cause analysis
Context, not just alerts

🧱 The Natural Outcome: Platform Engineering

These challenges didn’t kill DevOps.

They forced it to evolve.

Platform Engineering emerged to:

Codify best practices
Provide golden paths
Abstract complexity
Enable self-service safely

Internal Developer Platforms don’t replace DevOps principles.

They make them work at enterprise scale.

🧠 The Big Idea

DevOps didn’t fail.

It succeeded so well that it needed a new form.

From:

Humans doing DevOps for everyone

To:

Platforms enabling DevOps for everyone

That’s the shift.

And it’s why Platform Engineering exists.

🤔 The Big Question

If DevOps can’t deploy everything forever…

What replaces it?

👉 In Part 2, we’ll look at how leading companies are solving this with Platform Engineering.

Docker Networking: How Packets Actually Move

Sreekanth Kuruba — Tue, 23 Dec 2025 13:36:51 +0000

Containers do not have “networking” in the abstract sense.

They participate in Linux networking through isolation, indirection, and policy.

When a container sends a packet, it does not leave Docker. It leaves a network namespace, traverses a virtual Ethernet pair, crosses a bridge or routing boundary, and is transformed by netfilter rules before it ever reaches a wire.

Understanding this path explains nearly every networking behavior attributed to Docker.

Network Namespaces as the Isolation Boundary

Each container runs inside its own network namespace containing:

Interfaces
Routes
ARP tables
iptables chains
Loopback device

Nothing inside the container is virtualized. The kernel enforces isolation by scoping visibility.

Docker’s responsibility is namespace construction and wiring — not packet delivery.

The Default Bridge Is a Linux Bridge

The default Docker network is backed by a Linux bridge named docker0.

When a container is created:

A veth pair is allocated
One endpoint enters the container namespace as eth0
The peer endpoint attaches to docker0
An IP is assigned from the bridge subnet
NAT rules are installed for outbound traffic

The bridge provides Layer 2 adjacency. Routing and NAT occur outside the container.

This model trades simplicity for control and remains Docker’s default for a reason.

Port Publishing Is Address Translation, Not Exposure

Publishing a port does not modify the container. It installs DNAT rules on the host that rewrite incoming traffic.

Traffic flow:

Host interface receives packet
iptables PREROUTING rewrites destination
Packet forwarded to container IP
Return traffic SNATed back

This explains why:

Containers do not bind host ports
Port collisions are resolved at the host layer
Network performance differs from host mode

Port publishing is policy, not plumbing.

Network Modes Are Policy Choices

Mode	Description	Use Case	Trade-off
Bridge	Isolated namespace, NATed egress, explicit ingress	Default, safest	NAT overhead
Host	No namespace, no translation	Max performance	No isolation
None	Namespace with only loopback	Batch jobs, hardened workloads	No connectivity
Macvlan	Real MAC address, appears as physical device	VM-like networking	Bypasses iptables
Overlay	Encapsulation for multi-host	Swarm, Kubernetes	Encapsulation latency

libnetwork Is Control, Not Data Plane

libnetwork programs the kernel:

Allocates IPs
Selects drivers
Creates endpoints
Configures routing and firewall rules

It does not forward packets. The kernel always does.

Multi-Container Communication Is Name Resolution

User-defined bridge networks include an embedded DNS service.

Containers discover each other by name — Docker resolves names to IPs at runtime.

No static environment variables needed.

Debugging Means Leaving the Container

Most Docker networking failures occur outside the container namespace.

Useful commands:

ip link show type veth — veth pairs
brctl show or ip link show docker0 — bridge membership
ip route (host) vs docker exec <id> ip route — routing
iptables -t nat -L -v -n — NAT chains
nsenter --net=/proc/<pid>/ns/net — enter namespace

Container logs rarely explain network issues. The host almost always does.

Docker is often blamed. The kernel is usually guilty.

Performance and Security Tradeoffs

Bridge: NAT overhead
Host: No isolation
Macvlan: Bypasses iptables
Overlay: Encapsulation latency

Docker networking prioritizes containment over concealment. Security comes from explicit policy.

Summary

Docker networking is a composition of kernel primitives:

Network namespaces for isolation
veth pairs for connectivity
Bridges/routes for topology
netfilter for policy
libnetwork for orchestration

Once internalized, Docker networking becomes predictable.

Dockerfile Internals and the Image Build Pipeline

Sreekanth Kuruba — Thu, 18 Dec 2025 06:32:00 +0000

When engineers say "Docker builds an image," they usually mean a single command.
In reality, docker build triggers a deterministic pipeline that transforms a text file into an OCI-compliant artifact, composed of immutable, content-addressed layers.

Understanding this pipeline explains why cache behaves the way it does, why instruction order matters, and why small Dockerfile changes can dramatically impact build time and image size.

From Dockerfile to Build Graph

The build process starts long before any filesystem changes occur.

Docker first parses the Dockerfile into an internal instruction graph.
This phase validates syntax, resolves build stages, and prepares the build context after applying .dockerignore. No layers are created here. The output is a dependency-aware plan for how the image could be built.

Only after this plan is constructed does execution begin.

Practical Impact: The `.dockerignore` Advantage

# Without .dockerignore:
Sending build context to Docker daemon  1.2GB  # Slow transfer

# With proper .dockerignore:
Sending build context to Docker daemon  12.3kB  # Fast transfer

Key files to exclude:

node_modules/
.git/
*.log
.env
dist/  # For multi-stage builds

Layer Creation Is Content, Not Commands

Each filesystem-changing instruction such as RUN, COPY, or ADD produces a new layer.
These layers are immutable and identified by a cryptographic hash derived from their content and their parent layer.

This is why Docker caching is reliable.
If the inputs are identical, the resulting layer hash is identical. The build system does not care why a command ran, only what it produced.

Cache Key Composition

Layer Hash = SHA256(
  Parent Layer Hash +
  Instruction Content + 
  File Content (for COPY/ADD) +
  Build Arguments at this point
)

Example Cache Behavior:

# Layer 1: Always cached (base image)
FROM node:18-alpine

# Layer 2: Cached unless WORKDIR changes
WORKDIR /app

# Layer 3: Cache breaks if package.json changes
COPY package*.json ./

# Layer 4: Cache breaks if Layer 3 changes
RUN npm ci

# Layer 5: Cache breaks if ANY file changes
COPY . .

# Layer 6: Always cached (metadata)
CMD ["npm", "start"]

This design is what allows Docker to reuse layers across images, hosts, and even registries.

Why BuildKit Changed Everything

The classic Docker builder executed instructions sequentially, treating each step as an isolated operation.
BuildKit replaces this with a graph-based execution model.

With BuildKit, independent steps can execute in parallel, cache keys are more precise, and sensitive data such as credentials can be mounted at build time without ever becoming part of an image layer.

BuildKit vs Classic: A Performance Comparison

# Classic Builder (sequential)
Step 1/8 : FROM alpine:latest
Step 2/8 : RUN apk add --no-cache python3
Step 3/8 : RUN pip install pandas
... # Each step waits for previous

# BuildKit (concurrent possible)
[+] Building 8.2s (15/15) FINISHED
 => CACHED [stage-1 2/6] ...
 => CACHED [stage-1 3/6] ...  # Parallel execution
 => CACHED [stage-1 4/6] ...

Advanced BuildKit Features

1. Build Secrets (Never in Image Layers)

RUN --mount=type=secret,id=npm_token \
    echo "//registry.npmjs.org/:_authToken=$(cat /run/secrets/npm_token)" > .npmrc && \
    npm ci

2. Cache Mounts (Persistent Between Builds)

RUN --mount=type=cache,target=/var/cache/apt \
    apt-get update && apt-get install -y packages

This is not an optimization.
It is a fundamental shift in how image builds are modeled.

Multi-Stage Builds as a Security Boundary

Multi-stage builds are often described as a size optimization.
More importantly, they create a clean separation between build-time and runtime concerns.

Compilers, package managers, and secrets exist only in intermediate stages.
The final image contains exactly what is required to run the application, and nothing else.

Security Impact Analysis

# Single-Stage (Vulnerable)
FROM node:18
COPY . .
RUN npm ci  # 600+ dev dependencies
RUN npm run build
CMD ["node", "dist/app.js"]
# Result: 1.2GB image with dev tools, compilers, secrets

# Multi-Stage (Secure)
FROM node:18 AS builder
COPY . .
RUN npm ci && npm run build  # Dev dependencies here

FROM node:18-alpine
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm ci --only=production  # Only 40 prod dependencies
# Result: 180MB image, no dev tools, no build secrets

This reduces attack surface, simplifies vulnerability scanning, and makes image provenance easier to reason about.

Debugging Builds Means Debugging Inputs

Most Docker build issues are not runtime problems.
They are cache invalidation problems.

Unexpected rebuilds almost always trace back to:

Changing inputs in early layers
Overly broad COPY instructions
Uncontrolled build arguments

Diagnostic Toolkit

1. Layer Inspection

docker history myimage --no-trunc --format "{{.CreatedBy}}"
dive myimage  # Interactive layer explorer

2. Cache Analysis

# See why cache invalidated
docker build --progress=plain .

# Check specific layer
docker inspect myimage --format='{{.RootFS.Layers}}'

3. Context Troubleshooting

# See what's being sent to daemon
docker build --no-cache . 2>&1 | grep "sending build context"

Tools like docker build --progress=plain, docker history, and layer inspection utilities expose these relationships directly, turning "Docker magic" back into observable behavior.

Production Patterns

1. Deterministic Builds

# Pin everything
FROM node:18.20.1-alpine3.19  # Not :latest
RUN npm ci --frozen-lockfile  # Not npm install

2. Build-Time Optimization

# Order matters: Stable → Changing
COPY package*.json ./     # Infrequent changes
RUN npm ci               # Expensive operation
COPY . .                 # Frequent changes

3. Size Optimization

# Clean as you go
RUN apt-get update && \
    apt-get install -y build-essential && \
    # Build something && \
    apt-get remove -y build-essential && \
    apt-get autoremove -y && \
    rm -rf /var/lib/apt/lists/*

The OCI Artifact: What Actually Gets Built

At the end of the pipeline, Docker produces:

Image Manifest - Metadata and layer references
Image Config - Environment, entrypoint, working directory
Layer Tarballs - Compressed filesystem diffs
Index (multi-arch) - Platform-specific manifests

{
  "schemaVersion": 2,
  "layers": [
    {
      "digest": "sha256:abc123...",  // Content hash
      "size": 1234567
    }
  ],
  "config": {
    "digest": "sha256:def456...",
    "Cmd": ["npm", "start"]
  }
}

Summary

The Docker build pipeline transforms human-readable instructions into a secure, efficient, distributable artifact through:

Graph-based planning - Not linear execution
Content-addressable storage - Deterministic layer creation
Stage isolation - Build/runtime separation
Observable behavior - Every layer is inspectable

Understanding these internals moves teams from "Docker builds" to "engineered artifact pipelines."

Docker internals deep dive what really happens when you run docker run (2025 edition)

Sreekanth Kuruba — Tue, 16 Dec 2025 03:10:57 +0000

🧵 You type docker run nginx. In milliseconds, 7 components work together. Here's EXACTLY what happens at each layer (with debugging tips for when it breaks).

Modern container platforms depend on predictable, modular behavior. Docker's architecture is a layered execution pipeline built around standard interfaces: REST, gRPC, OCI Runtime, and Linux kernel primitives. Understanding this flow eliminates ambiguity during debugging, scaling, or integrating with orchestration systems.

1. Core Architecture

CLI → dockerd (API + Orchestration) → containerd (Runtime mgmt)

→ containerd-shim (Process supervisor) → runc (OCI runtime)

→ Linux Kernel (Namespaces, cgroups, fs, net)

Docker CLI

User command interface
Converts flags to JSON
Talks to dockerd through /var/run/docker.sock

dockerd

REST API server
Container lifecycle orchestration
Network/volume management
Delegates image and runtime operations to containerd

containerd

High-level runtime manager
Manages snapshots, images, and content store
Pulls/unpacks layers
Creates OCI runtime specifications
Launches a containerd-shim for each container

Image Storage Detail:

Each layer is content-addressable via SHA256

Identical layers are deduplicated

OverlayFS uses hardlinks so layers are shared across containers

containerd-shim

Parent process for the container's workload
Keeps containers alive if dockerd/containerd restart
Manages IO streams (logs, attach)
Returns exit codes to containerd

runc

Implements the OCI runtime spec
Creates namespaces
Applies cgroup limitations
Mounts root filesystem
Executes the entrypoint
Exits immediately after container creation

Linux Kernel

Enforces process isolation (namespaces)
Resource control (cgroups)
Layered filesystems (OverlayFS)
Networking (veth, bridges, iptables/NAT)

✈️ The Airport Analogy: A Mental Model

Just as you don't need to know air traffic control to board a flight,
you don't need to understand all Docker components to run containers.
But when things go wrong, knowing the layers helps troubleshoot!

Component	Airport Role	Real-World Impact
Docker CLI	Passenger Terminal	You type `docker run`, check status
dockerd	Airport Operations Center	Manages all flights, gates, schedules
containerd	Ground Control	Loads luggage (images), assigns runways
containerd-shim	Gate Agents	Ensures plane stays ready even if Ops Center reboots
runc	Pilot	Actually flies the plane (executes container)
Kernel	Air Traffic Control	Manages airspace (resources), prevents collisions
Container	The Actual Flight	Your app running in isolated airspace

Use this mental model to remember component relationships during troubleshooting.

2. Execution Flow: `docker run -d -p 8080:80 nginx`

Step 1. CLI → dockerd

CLI parses command, constructs a JSON payload, and sends it over the Unix socket.

Step 2. dockerd Validation

Dockerd validates configuration, checks local images, and coordinates container creation.

Step 3. Image Pull (if needed)

containerd handles:

Registry authentication
Manifest resolution
Layer download and verification
Storage in the content store

Step 4. Filesystem Assembly

containerd prepares:

Snapshot
OverlayFS upper/lower directory layout
OCI bundle with metadata and runtime config

Step 5. Networking Setup

Dockerd configures the network namespace:

veth pair creation
Host end added to docker0
Container assigned IP (e.g., 172.17.0.2)
iptables DNAT for port-mapping
MASQUERADE rule for outbound traffic

Step 6. containerd → containerd-shim

containerd:

Spawns shim
Hands off the OCI spec
Delegates lifecycle supervision

Step 7. shim → runc

runc:

Creates namespaces
Mounts rootfs
Applies cgroup limits
Executes container entrypoint
Exits (shim remains as supervisor)

Step 8. Container Running

Container runs as an isolated Linux process:

shim maintains lifecycle
dockerd streams logs and reports state
kernel enforces isolation

3. Component Responsibilities

Component	Role	Delegates
CLI	User interface, request creation	dockerd
dockerd	API, orchestration, networking	containerd
containerd	Image mgmt, snapshots, lifecycle	runc
containerd-shim	Supervises container process	kernel (via runc-created namespaces)
runc	Creates container environment	kernel
Kernel	Isolation + resource control	hardware

Related Architecture:
For Kubernetes, replace:

dockerd  →  kubelet → CRI → containerd

Everything downstream (containerd → shim → runc → kernel) remains unchanged.

4. Key Clarifications

Containers are processes, not virtual machines.
runc does not stay resident; shim manages the lifecycle.
Docker's layered filesystem is copy-on-write for efficient storage.
Kubernetes removed dockerd and uses containerd directly for a simpler CRI pipeline.
Live-restore works because shim decouples containers from dockerd.

5. Debugging Guide (Ops-Ready Edition)

A structured, layered sequence for diagnosing container failures. Designed for SRE, DevOps, and runtime engineering teams.

Container exits immediately

Follow the layers from highest to lowest impact.

1. Application Layer

Severity: Low
Most failures originate here.

docker logs <container>

Looks for: runtime exceptions, crash loops, missing configs, entrypoint failures.

2. Runtime Layer (containerd / OCI)

Severity: Medium
Issues here affect container creation, not app logic.

journalctl -u containerd

Detects:

Invalid OCI specs
Snapshot/unpack errors
Permission issues
Image metadata failures

3. Kernel Layer

Severity: High
Kernel failures affect all containers on the node.

dmesg | tail -20

Reveals:

Namespace creation failures
cgroup enforcement errors
LSM blocks (AppArmor/SELinux)
OverlayFS mount issues

Slow container startup

Pinpoint latency at the registry, storage, or runtime.

1. Image Pull / Unpack Latency

journalctl -u containerd --since "2 minutes ago" | grep -Ei "pull|unpack"

Finds slow remote pulls, layer unpack delays, decompression problems.

2. Host Storage Bottleneck

iostat -dx 1 /var/lib/containerd

Detects:

High I/O wait
OverlayFS backing store saturation
Slow disks or overloaded volumes

3. Registry / Network Slowness

time docker pull alpine:latest

Measures:

Round-trip latency
Download throughput
Registry auth or proxy delays

Network issues

Trace connectivity host → bridge → container.

1. Verify NAT / Port Forward Rules

sudo iptables -t nat -L DOCKER -n -v

2. Bridge & veth Topology

ip addr show docker0
brctl show

3. Container Namespace Networking

docker exec <id> ip addr show

Common Error Patterns

A quick pattern-matching cheat sheet.

Error Message	Likely Cause
`no such file or directory`	Missing entrypoint or wrong working dir
`permission denied`	User namespace restriction, volume permissions
`address already in use`	Host port collision
`exec format error`	Architecture mismatch (amd64 vs arm64)
`layer does not exist`	Corrupted image store, partial pull
`failed to setup network namespace`	Kernel lacking required capabilities

Recovery Actions

Map root cause to corrective steps.

1. Image Pull Failures

Check registry auth tokens
Verify proxy/SSL configuration
Test connectivity to registry endpoints

2. OCI Spec / Runtime Errors

Ensure Docker + containerd + runc versions are compatible
Validate custom seccomp or AppArmor profiles
Recreate corrupted snapshots

3. Kernel Namespace / Cgroup Failures

Check kernel version supports required features
Validate cgroup v1/v2 mode
Inspect sysctl overrides affecting namespaces

6. Summary

A docker run invocation travels through a disciplined, modular execution path. Each component accepts a small, well-defined piece of responsibility and hands off cleanly to the next, forming a predictable control flow:

Dockerd parses intent and translates it into runtime instructions.
Containerd orchestrates container lifecycle through stable gRPC APIs.
Containerd-shim isolates the container’s process management from daemon restarts.
runc materializes the OCI Runtime Spec into Linux primitives.
The kernel provides the final enforcement layer through namespaces, cgroups, and filesystem drivers.

These boundaries are governed by open standards (REST → gRPC → OCI Spec → syscalls), ensuring compatibility, reliability, and deep observability across layers.

Isolation, resource governance, and performance efficiency emerge directly from native Linux constructs—no hidden hypervisor, no extra abstraction. As a result, containers start fast, run lean, and scale predictably.

Operational Note:
Because process ownership is delegated to containerd-shim, both dockerd and containerd can be restarted without disrupting running containers. This design supports safe daemon upgrades, node maintenance, and high-availability workflows that do not interrupt workloads.

Core Architecture
Execution Flow
Component Responsibilities
Key Clarifications
Debugging Guide (Ops-Ready Edition)
└── [DEBUGGING TREE IMAGE]
└── Container exits immediately
└── Slow container startup
└── Network issues
└── Common error patterns
└── Recovery actions
Summary

Drop your thoughts in the comments below! 👇
Follow me for more deep dives into fundamental CS concepts made approachable!

TLS 1.2 vs TLS 1.3 in Production (2025)

Sreekanth Kuruba — Tue, 09 Dec 2025 13:30:11 +0000

How We Reduced p95 Latency by 40% and Eliminated Certificate Incidents

Modern web performance depends on minimizing round trips. In late 2025, we evaluated our global traffic (300M+ requests/day) and found a surprising bottleneck:

Over 80% of our latency overhead came from TLS 1.2 handshakes — not from the application.

We migrated fully to TLS 1.3 across Cloudflare → ALB → Nginx.

Here's the data, the architecture impact, and the configuration used.

Executive Summary
Key Results:

Performance: 40% reduction in p95 latency

Reliability: Certificate incidents dropped to zero

Cost: 28% reduction in ALB CPU usage

Migration: 45 minutes, near-zero risk

Compatibility: 99.3% of traffic unaffected

1. The Simplest Analogy: Airport Security

TLS 1.2 = Old Airport Security

Remove shoes
Remove laptop
Two screening stages
Long waits for everyone

TLS 1.3 = Modern Fast-Track

Single unified check
Faster crypto negoatiation
PreCheck (0-RTT) for returning users

Exactly the same logic applies to round trips.

2. How the Handshake Changed

TLS 1.2 — 2 Round Trips

Client ──ClientHello────────────► Server
Client ◄─ServerHello+Cert──────── Server
Client ─────Finished────────────► Server
Client ◄────Finished───────────── Server
         ↑↑
     2 RTT required

TLS 1.3 — 1 Round Trip

Client ──ClientHello+KeyShare───► Server
Client ◄─ServerHello+Finished──── Server
Client ─────Finished────────────► Server
         ↑
     1 RTT

TLS 1.3 (Resume) — 0-RTT

Client ──Early Data──────────────► Server
Client ◄─Immediate Response─────── Server
         ↑
       0 RTT

This is the core performance difference.

3. Real Production Data (Nov–Dec 2025)

After enabling TLS 1.3 everywhere:

Metric	TLS 1.2	TLS 1.3	Improvement
p95 TTFB (global)	318 ms	194 ms	–40%
Full handshakes	~40%	<6%	–85%
ALB CPU	Baseline	–28%	Savings
Failed handshakes	1.2%	0.4%	Higher compatibility
0-RTT usage	0%	58%	Faster repeat visitors
Certificate pages	3–4/mo	0	Stability win

Largest gains:
India, Brazil, Indonesia, South Africa

broadly APAC, LATAM, Africa (naturally high RTT regions).

4. Why TLS 1.3 Wins (Operational view)

Fewer Round Trips

Connection setup time is the single biggest latency factor for first-time visitors.

High Resumption Success

TLS 1.3 replaces legacy session tickets with Pre-Shared Keys (PSKs), enabling:

94–98% session reuse
Fewer full handshakes
Lower CPU cost

Simplified Cipher Suites

TLS 1.2 had 15–20 negotiable options.
TLS 1.3 has 5 secure defaults.

This removes misconfigurations entirely.

Forward Secrecy by Default

Impossible to accidentally weaken.

Ready for ECH (2025–2026)

Encrypted ClientHello = SNI protection + privacy upgrade

5. Configuration That Works Everywhere (2025)

Cloudflare

SSL/TLS → Edge Certificates → Minimum TLS Version = 1.3

AWS ALB / CloudFront

Use any policy with TLS13:

ELBSecurityPolicy-TLS13-1-2-2021-06 or newer.

Nginx

ssl_protocols TLSv1.3;
ssl_early_data on;              # Enables 0-RTT safely for GET/HEAD
ssl_prefer_server_ciphers off;

ssl_session_cache shared:TLS:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;        # Use PSK instead

Caddy

tls {
    protocols tls1.3
}

6. Monitoring Your TLS Migration

# Live TLS version monitoring
tail -f /var/log/nginx/access.log | \
  awk '{print $NF}' | \
  sort | uniq -c

# CloudWatch metrics (AWS)
aws cloudwatch get-metric-statistics \
  --metric-name ProcessedBytes \
  --namespace AWS/ApplicationELB \
  --statistics Sum \
  --dimensions Name=LoadBalancer,Value=your-alb

# TLS error tracking
grep -E "SSL|TLS" /var/log/nginx/error.log | \
  cut -d' ' -f6- | \
  sort | uniq -c | sort -rn

# Client compatibility check
curl -I https://yoursite.com -v 2>&1 | grep -E "TLS|SSL"

Alert Threshold: >0.1% TLS 1.2 fallback after 7 days

7. When You Should Keep TLS 1.2 (Rare)

Organizations that commonly require fallback:

Banks with legacy proxies
Government/defense systems
Healthcare EMR systems
Windows Server 2008 environments

Recommended fallback:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384";

Check TLS 1.2 traffic usage:

grep -c TLSv1.2 /var/log/nginx/access.log

Most modern consumer traffic = <0.7% TLS 1.2.

8. ROI Calculator

For 100M monthly requests:

TLS 1.2: ~40M full handshakes
TLS 1.3: ~6M full handshakes
Reduction: 34M handshakes

AWS ALB cost impact:
- LCU cost: $0.008/hour
- Monthly savings: ~$2,100
- Annual: $25,200

Performance ROI:

40% faster TTFB = better conversion rates

Improved Core Web Vitals = SEO boost

Reduced CDN egress = lower bandwidth costs

9. Recommended Migration Plan

Phase 1 — Observation (Day 1-7)

Enable TLS 1.3 with fallback. Monitor breakage.

ssl_protocols TLSv1.3 TLSv1.2;

Phase 2 — Prefer TLS 1.3 (Day 8-14)

Prioritize TLS 1.3 in negotiation.
Monitor error rates.

Phase 3 — Enforce (Day 15+)

Disable TLS 1.2 once error rate stays below 0.1%.

ssl_protocols TLSv1.3;

Total migration time for us: 45 minutes end-to-end.

10. CDN Provider Differences (2025)

Provider	TLS 1.3 Default	0-RTT Support	ECH Support
Cloudflare	Yes	Yes	Rolling out
Akamai	Yes (Edge)	Limited	Beta
Fastly	Yes	Yes	Planned
AWS CloudFront	Manual	No	No
GCP Cloud CDN	Yes	No	No

What's your organization's TLS 1.3 status?

Enforced everywhere (100% TLS 1.3)

Enabled but with fallback

Still evaluating/testing

Not on roadmap yet

8. Final Recommendation

TLS 1.3 is not "new technology" anymore.
It is the expected baseline for global applications.

Upgrading gives you:

Faster connections
Better Core Web Vitals
Lower compute cost
Simplified security posture
Zero operational downsides

In 2025, continuing to rely on TLS 1.2 means accepting unnecessary latency on every single request.

Drop your thoughts in the comments below! 👇
Follow me for more deep dives into fundamental CS concepts made approachable!

Forem: Sreekanth Kuruba

DevOps vs Platform Engineering in 2026

Imagine this:

🧩 What DevOps Solved — And Where It Breaks at Global Scale

🏗️ Platform Engineering: The Next Evolution

⚙️ What Platform Engineering Actually Delivers

⚖️ DevOps vs Platform Engineering – Clear Comparison

🌍 Why Global Companies Are Making This Shift in 2026

⚠️ Challenges & Smart Way to Adopt

🧭 What Should You Learn?

🔮 Final Thought

💬 What about you?

Types of APIs Explained: REST, GraphQL, gRPC & SOAP (With Real-World Examples)

🧠 What is an API? (Quick Recap)

🔹 Main Types of APIs by Architecture Style

🔹 Types of APIs by Access Level

🔄 Real-World Architecture Insight

🎯 Final Takeaway

API Explained: From Basics to Real-World Systems (UPI Deep Dive)

Why "Just Restart It" Stopped Working

Why "Just Restart It" Stopped Working

The Universal Truth

When Restarting Made Sense

The First Sign of Trouble

The Cascade

Why Restarting Broke

What Happens When You Restart Now

The Lie We Tell Ourselves

What Replaced Restarting

Health checks

Graceful degradation

Automatic replacement

Rolling restarts

The Systems That Don't Need Restarts

The Honest Confession

What You Can Do Monday

The Question

From Process Management to State Reconciliation

I used to restart servers at 2AM… Kubernetes made that job disappear

🧱 The old world: Process-driven operations

🐳 Containers helped… but didn’t solve the real problem

🔄 Kubernetes changed the question

⚙️ The magic: State reconciliation

🔄 Traditional vs Kubernetes minds

🧠 Why Kubernetes doesn’t care about PIDs

💥 The real shift: Replace, don’t repair

🧪 Jobs are different too

⚠️ Failure is not an exception anymore

🔁 What actually changed?

🏁 Final thought

💬 Your turn

How Platform Engineering Changes the Game

🧱 What Platform Teams Actually Build

🏢 Real-World Example: Amazon's "You Build It, You Run It"

⚙️ The Tooling Shift

📊 The Numbers Don't Lie

🤖 Where AI Actually Helps Today

🚨 The Hard Parts (Nobody Talks About)

🎯 The Real Shift

💡 If You Remember One Thing

Companies like Spotify (with Backstage) and Netflix scaled DevOps exactly this way — by building platforms instead of doing everything centrally.

Why Traditional DevOps Stops Scaling

Why Traditional DevOps Stops Scaling

🚧 Why Traditional DevOps Stops Scaling

🧱 The Natural Outcome: Platform Engineering

🧠 The Big Idea

Docker Networking: How Packets Actually Move

Network Namespaces as the Isolation Boundary

The Default Bridge Is a Linux Bridge

Port Publishing Is Address Translation, Not Exposure

Network Modes Are Policy Choices

libnetwork Is Control, Not Data Plane

Multi-Container Communication Is Name Resolution

Debugging Means Leaving the Container

Performance and Security Tradeoffs

Summary

Dockerfile Internals and the Image Build Pipeline

From Dockerfile to Build Graph

Practical Impact: The .dockerignore Advantage

Layer Creation Is Content, Not Commands

Practical Impact: The `.dockerignore` Advantage

2. Execution Flow: `docker run -d -p 8080:80 nginx`