DEV Community: Sreekanth Kuruba

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!

HTTP/1.1 vs HTTP/2 vs HTTP/3 – Which One Are You Still Using in 2025?

Sreekanth Kuruba — Tue, 02 Dec 2025 13:33:40 +0000

Most teams think they’ve already moved to HTTP/2 or HTTP/3.

But when we checked real production traffic in 2025, the truth was surprising:

We pulled protocol stats from our CDN + load balancer logs...

63% of all requests were still hitting us over HTTP/1.1 — mostly from corporate proxies, middleboxes, and legacy devices.

That means 2 out of every 3 requests were paying an unnecessary 150–300ms latency tax just because outdated protocols were still in the path.

The Web’s 2025 Protocol Reality Check

All three versions move data between browser and backend.
But how they do it — TCP vs multiplexing vs QUIC — creates massive differences in:

Page load speed
API latency
Core Web Vitals
CDN routing efficiency
Mobile reliability

Here’s the 2025 snapshot:

📊 HTTP/1.1 vs HTTP/2 vs HTTP/3 (2025 Edition)

Feature	HTTP/1.1 (1997)	HTTP/2 (2015)	HTTP/3 (2022+, QUIC)
Transport	TCP	TCP	UDP (QUIC)
Multiplexing	No	Yes	Yes (independent streams)
HOL Blocking	Yes	Yes (TCP)	None
Header Compression	None	HPACK	QPACK
Connection Setup	1–3 RTT	1–3 RTT	0–1 RTT
Mobile Performance	Poor	Decent	Best
Real Adoption (2025)	15–20%	60–65%	25–30% and rising
Browser Support	100%	~98%	~95–97%

🦕 HTTP/1.1 – The Dinosaur That Refuses to Die

Why it still dominates:

Corporate proxies downgrade connections
Old load balancers downgrade traffic back to HTTP/1.1
Cheap hosting providers
Legacy browsers & IoT devices
Internal APIs nobody migrated

Problems:

No multiplexing
HOL blocking
Browser opens 6 parallel connections
Massive header repetition

If you still rely on HTTP/1.1 in 2025, you are paying a latency tax every single day.

⚡ HTTP/2 – The Multiplexing Hero (With One Big Problem)

HTTP/2 solved a lot:

Binary framing
Multiplexing
Header compression
Single connection

But it still suffers from TCP Head-of-Line Blocking:

One lost packet → all streams wait.

On flaky networks (mobile, 3–5% packet loss), H2 often performs worse than people expect.

Still excellent for: CDNs, production APIs, stable networks.

HTTP/3 – QUIC Is the Real Upgrade

HTTP/3 ditches TCP entirely and uses QUIC over UDP.

Big wins:

0-RTT resume
No HOL blocking
Faster handshakes
Better encryption (TLS 1.3 built-in)
Superior mobile performance
Stable under packet loss

This is the first protocol designed for modern, mobile, global internet traffic.

📈 Real 2025 Performance Results

Scenario	HTTP/1.1	HTTP/2	HTTP/3
100 small assets	4–6s	~1.2s	~0.9s
3% packet loss	Terrible	Bad	Good
Flaky mobile	Painful	Okay	Best
First load	Slow	Slow	Fastest
Repeat visits	~Same	~Same	Instant (0-RTT)

The Problem Nobody Mentions

Even if your CDN + app support HTTP/3:

Many users still fall back to 1.1 or 2.0 due to network intermediaries.

Common blockers:

Corporate firewalls
Middleboxes that strip UDP
Legacy devices
Some enterprise proxies
Outdated routers
Misconfigured hosting

This is why simply enabling HTTP/3 is not enough – everything in the path must support it.

So What Should You Use in 2025?

HTTP/1.1 → Only for legacy systems

Or internal APIs that never changed.
HTTP/2 → Still excellent and widely reliable

Stable, cheap, widely supported.
HTTP/3 → Enable it everywhere you can

(Cloudflare, CloudFront, Fastly, Akamai, Bunny — all support it now)
Quick Checklist to Move to HTTP/3 (2025)

CDN

Cloudflare → Enable QUIC + HTTP/3
CloudFront → Supported on new distributions
Fastly/Akamai/Bunny → Native support

Self-Hosted

Nginx 1.25+ QUIC
Caddy 2.6+ (auto HTTP/3)
Traefik v3
LiteSpeed / OpenLiteSpeed

Backend

Node.js 21+ with QUIC
Go, Rust, Java (Netty) → great QUIC libraries
Python → aioquic or reverse proxy

Final Verdict (2025)

HTTP/1.1 → Legacy tech

HTTP/2 → Today’s safe default

HTTP/3 → Today’s performance baseline

HTTP/3 isn’t “future tech” anymore - it’s the baseline for fast global apps in 2025.

The question isn’t if you should upgrade…

It’s how much faster your users will be when you do.

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

HTTP vs HTTPS vs TCP vs UDP - The Visual Guide You Wish You Had Earlier

Sreekanth Kuruba — Tue, 25 Nov 2025 02:59:05 +0000

HTTP vs HTTPS vs TCP vs UDP: Finally Understand The Difference! 🏗️

If you've ever felt confused about these four acronyms that rule the internet, you're not alone. Most explanations get stuck in technical jargon, but today I'll give you a mental model that will make everything click forever.

🏗️ Think of Networking Like Building a House

Here's the analogy that changes everything:

1️⃣ TCP/UDP → The Foundation & Roads

This is the TRANSPORT LAYER - it decides HOW data moves between systems.

The Vehicle Choice:

TCP = Moving Truck (reliable, ordered, confirms delivery)

UDP = Bike Messenger (fast, no guarantees, fire-and-forget)

Why it comes first: Everything else gets built on top of this foundation.

2️⃣ HTTP/HTTPS → The Rooms & Interior

This is the APPLICATION LAYER - it defines WHAT the data means and how applications talk.

The House Design:

HTTP = Open Floor Plan (everything visible, no security)

HTTPS = Fortified Rooms (encrypted, secure, authenticated)

Why it comes second: You need a foundation before you can build rooms.

3️⃣ Apps/Browsers/APIs → The Furniture & People

This is where YOU live - the actual applications that use everything below.

The Residents:

Your browser using HTTPS

Your API making HTTP calls

Your game using UDP for real-time action

Why it comes last: People move into a finished house, not a construction site.

The Super Simple Workflow

Transport (TCP/UDP) → Protocol (HTTP/HTTPS) → Application (Your App)

Memory Trick That Sticks

ROADS (TCP/UDP) → VEHICLES (HTTP/HTTPS) → PASSENGERS (Your Apps)

Roads first → Vehicles next → Passengers last.

Now that you have the big picture, let's dive into the technical details!

🔍 Deep Dive: The Complete Visual Guide

Crucial Insight: HTTP depends on TCP. HTTPS is just HTTP with a security layer (TLS/SSL).

⚡ TCP vs UDP: The Technical Breakdown

TCP - The Reliable Perfectionist ✅

Technical Features:

3-Way Handshake (SYN → SYN-ACK → ACK) - establishes connection first
Acknowledgements - receiver confirms every packet
Retransmission - resends lost packets automatically
Sequencing - orders packets correctly
Flow Control - prevents network congestion

Use Cases: Web browsing, email, file transfers, SSH - anywhere you need all data delivered correctly.

UDP - The Speedy Maverick 🚀

Technical Features:

Connectionless - no handshake, no setup
No guarantees - packets can be lost, duplicated, or arrive out of order
Low overhead - smaller headers, faster transmission
Low latency - minimal processing delay

Use Cases: Video streaming, VoIP, online gaming, DNS - where speed beats perfection.

🔒 HTTP vs HTTPS: Security Matters

HTTP - The Plain Text Problem 📝

HTTP defines how browsers and servers communicate, but it has a massive problem:

GET /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Content-Type: application/x-www-form-urlencoded

username=john&password=supersecret123

See the issue? Everything is sent in clear text - URLs, headers, even passwords! Anyone on the network can read it.

HTTPS - The Encrypted Solution 🛡️

✅ All communication encrypted and authenticated!

🎯 When to Use What? A Practical Guide

🌐 Real-World Example: Loading a Secure Website

Let's trace what happens when you visit https://www.dev.to:

DNS Lookup (UDP): "What's the IP for dev.to?" - UDP for speed
TCP Handshake: Establish reliable connection to the server
TLS Handshake: Set up encryption and verify certificate
HTTP Request: Your encrypted request for the homepage
HTTP Response: Server sends back encrypted HTML/CSS/JS
Render: Browser decrypts and displays the page

💡 Key Takeaways for Developers

For Frontend Developers:

You work with HTTP/S daily (APIs, cookies, CORS). Understanding that it runs on reliable TCP explains why you rarely worry about data corruption.

For Backend Engineers:

You configure web servers (Nginx, Apache), tune TCP settings, and manage TLS certificates. This knowledge is essential.

For Game/Real-time Developers:

Use UDP for player positions (speed critical), but TCP for purchases/state saves (reliability critical).

💡 Developer Cheat Sheet

SCENARIO           PROTOCOL          WHY
-----------------  ---------------  --------------------
Website/Web App    HTTPS over TCP   Security + Reliability
Video Streaming    UDP              Speed > Perfect Frames  
File Transfer      TCP              Need All Data Correctly
Online Gaming      UDP + TCP        Speed + Reliability
API Calls          HTTPS over TCP   Security + Reliability
Voice/VoIP         UDP              Low Latency Critical
DNS Lookups        UDP              Fast, Small Requests
Email              TCP with TLS     Reliability + Security
SSH/Remote Access  TCP              Reliability + Security

🚀 Next Steps

Check your sites: Use SSL Labs SSL Test to audit your HTTPS setup
Experiment: Use Wireshark to see these protocols in action
Learn more: Dive into WebRTC (uses both TCP and UDP strategically)

💬 Let's Discuss!

What clicked for you in this explanation?

Have you ever had to choose between TCP/UDP in a project?

What other networking concepts should I break down?

Any "aha!" moments with the house-building analogy?

Drop your thoughts in the comments below! 👇

Follow me for more deep dives into fundamental CS concepts made approachable!

Tech Doesn’t Wait for Degrees — It Rewards Adaptability

Sreekanth Kuruba — Tue, 04 Nov 2025 06:06:14 +0000

The tech world moves faster than any curriculum can keep up.
By the time a student graduates, much of the specific technology they learned can feel outdated.

We often hear that a degree opens doors. But in 2025 and beyond, it’s adaptability that keeps them open.

🎓 The Shift from Degrees to Skills

For decades, a degree was the ticket to opportunity — it symbolized credibility and knowledge.
But in today’s IT industry, real value lies in what you can build, not just what you can recite.

The reality is simple:

Tools change every year.
Frameworks evolve.
Business priorities shift overnight.

What remains constant? The ability to learn, unlearn, and adapt.

Companies today focus more on hands-on experience — real projects, open-source contributions, and skill-based certifications.
A degree might get you an interview, but adaptability gets you the job.

🔁 Adaptability: The Skill That Never Expires

Hard skills fade with time — adaptability doesn’t.
Think about how fast our tech landscape evolves:

Yesterday it was on-prem servers, today it’s Kubernetes clusters.
Yesterday it was manual builds, now it’s automated CI/CD pipelines.
Yesterday we wrote shell scripts, today it’s infrastructure as code.

The professionals who stay relevant are those who treat every change as an opportunity to grow — not a threat to their comfort zone.

Adaptability means you don’t just survive change; you use it to advance.

That mindset separates good engineers from great ones.

Here's the difference visualized:

# Hard skills: Age like milk
$ knowledge_base --version
# 1.0.0 (Deprecated)

# Adaptability: The non-expiring skill
$ skill_set --update --force
# Success: Learning cycle initiated

💡 Mindset Over Milestones

When it comes to growth, your degree defines your start — not your ceiling.
The ability to learn continuously, stay curious, and bounce back from failure is what defines long-term success.

Some of the most talented tech professionals I've met come from non-traditional backgrounds. What they share is a knack for being quick learners who aren’t afraid to explore something new.

Every major transformation — from adopting DevOps practices to embracing AI tools — started with people who were willing to experiment.

Adaptability isn’t about knowing everything; it’s about being comfortable with what you don’t know yet.

🧠 If You’re Hiring, Rethink What You Measure

If you’re hiring, don’t just look for a degree.
Look for curiosity, resilience, and a growth mindset.

Curiosity drives innovation.
Resilience keeps teams steady during change.
A growth mindset ensures learning never stops.

A résumé lists credentials — but a project discussion reveals how someone thinks and adapts.
That’s the kind of talent that grows with your organization.

🚀 The Future of Learning: Degrees and Skills Together

The goal isn’t to discard degrees — it’s to redefine their purpose.
Degrees build a foundation. Skills build momentum.

The future belongs to professionals who combine both:
🎯 a structured academic base
⚙️ continuous upskilling
💬 and real-world application

Tech doesn’t wait for degrees — it rewards adaptability.
Keep learning. Keep experimenting. Keep evolving.

Because in the world of constant change, adaptability is your real degree.

💡 Your Personal Challenge

Don't let your knowledge base become a museum. Your real career moat isn't your degree; it's your Time-to-Competency (TTC) for the next big tool.

Ask yourself today: What is the most uncomfortable, but necessary, tool you will master this month? That answer is your career roadmap.

Keep learning. Keep experimenting. Keep evolving.

✍️ Author: Sreekanth Kuruba

Engineer passionate about automation, continuous improvement, and learning what’s next in tech.

DEV Community: Sreekanth Kuruba

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

Cache Key Composition

Why BuildKit Changed Everything

BuildKit vs Classic: A Performance Comparison

Advanced BuildKit Features

Multi-Stage Builds as a Security Boundary

Security Impact Analysis

Debugging Builds Means Debugging Inputs

Diagnostic Toolkit

Production Patterns

1. Deterministic Builds

2. Build-Time Optimization

3. Size Optimization

The OCI Artifact: What Actually Gets Built

Summary

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

1. Core Architecture

Docker CLI

dockerd

Practical Impact: The `.dockerignore` Advantage

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