DEV Community: Roger Oliveira

Connection refused" has three different root causes here's how to tell them apart with evidence

Roger Oliveira — Tue, 25 Aug 2026 15:04:11 +0000

Connection refused" and a silent timeout look like the same failure to whoever's paging you at 2am. They're not. They come from different layers of the stack, and conflating them is why people restart services without ever fixing the actual cause.

The mental model:

Name (DNS) → Route to IP → Port open on target → Filter in the path → App responds

Reproduce it yourself (Docker required):

bash
docker network create rede-lab
docker run -d --name servidor --network rede-lab nginx:alpine
docker run -it --name cliente --network rede-lab busybox sh

Then break each layer independently:

DNS broken — overwrite /etc/resolv.conf inside the client container. Symptom: name doesn't resolve, but the same request by raw IP succeeds. That's your evidence it's DNS, not the network.
Port closed — stop nginx but keep the container alive. Symptom: immediate Connection refused. Evidence: ss -tlnp on the server shows nothing listening on port 80.
Firewall dropping — add an iptables -A INPUT -p tcp --dport 80 -j DROP rule. Symptom: silent timeout, no error. Evidence: tcpdump shows the SYN going out with no SYN-ACK coming back.

Reference table:

Symptom Likely cause Confirming evidence
Name doesn't resolve DNS Direct IP access works
Immediate refusal Port closed ss -tlnp shows nothing listening
Silent timeout Firewall DROP tcpdump shows unanswered SYN
Timeout with RST Firewall REJECT / closed port at OS level RST visible in tcpdump

The same three failure modes show up, renamed, in Kubernetes: DNS → misconfigured CoreDNS, closed port → empty Service Endpoints, firewall → a NetworkPolicy silently dropping traffic. Same method, different label.

Full write-up with the "why it matters for platform/SRE work" framing and the GitHub reference chapter (with an exercise checklist) are linked above.

Curious how people here debug this in practice: do you reach for tcpdump early, or only after ss/dig/nc rule out the obvious layers? And has anyone had a case where the symptom actively lied — e.g., a REJECT rule dressed up to look like a closed port? Drop it in the comments, I'm collecting real-world edge cases for the next chapter on containers.

Platform Engineering starts before Kubernetes

Roger Oliveira — Fri, 21 Aug 2026 19:42:38 +0000

Why the right question isn't "where do I start with Kubernetes", but "what problem am I actually solving".

The claim that tends to bother people

Every time someone asks me "where do I start to become a Platform Engineer", the answer they expect is "Kubernetes". The answer I give is: no. Kubernetes is the tool you use once you already know what you're trying to solve. Platform Engineering is about the problem, not about the orchestrator.

What actually separates someone who "knows Kubernetes" from someone doing Platform Engineering

After years running and evolving Kubernetes platforms in production — with hundreds of workloads and thousands of pods running in a regulated corporate environment — the difference I see in practice isn't in kubectl. It's in three questions most tutorials never make you ask:

Who is your platform's customer? It's not the cluster. It's the development team that needs to ship without pinging you every time. If you can't name who uses what you're building, you're operating infrastructure, not building a platform.
What happens when something breaks at 3am? A tested rollback, a defined RTO, a clear incident owner — that's a design decision made long before any YAML manifest exists. A platform that wasn't designed to fail well, fails badly.
How do you measure whether the platform is helping or getting in the way? If the answer is "I don't know", you have a cluster, not a platform. Capacity planning, adoption metrics, reduced cross-team rework — that's what turns operations into an internal product.

Where Linux comes in

This is the connection the "Linux from Zero" series has been building since the first post: every abstraction Kubernetes gives you — pods, namespaces, resource limits, network policies — is an elegant repackaging of concepts that already exist in plain Linux: processes, kernel namespaces, cgroups, iptables/nftables. Once you understand the process before the pod, the kernel namespace before the Kubernetes namespace, you stop treating the cluster as a magic black box and start debugging like someone who understands the engine, not just the dashboard.

It's not a coincidence that the worst production incidents I've had to solve had their root cause one layer below Kubernetes — disk I/O, DNS, kernel limits — not in the orchestrator itself. Someone who only knows how to operate Kubernetes is blind exactly where the problem lives.

The path I advocate for (and the one this series follows)

Linux → processes → networking → containers → Docker → containerd → Kubernetes → observability → SRE → Platform Engineering → architecture.

That order isn't arbitrary. It's the order that gives you solid ground before it gives you altitude. Each layer explains the one above it. Jumping straight to "Kubernetes from zero" is like learning to fly a plane without understanding what makes it fly — you can memorize the controls, but you can't diagnose it when something goes off-script.

Where this takes you in practice

If you're trying to move from operations into Platform Engineering — or from Platform Engineer to Staff/Principal — the real test isn't "how many YAML manifests have you written". It's: can you explain, in one sentence, to a non-technical executive, why the platform you're building reduces risk and speeds up delivery? If yes, you're already thinking like a Platform Engineer. Kubernetes is just the tool you chose to execute that vision today — tomorrow it might be something else.

Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr

Agree or disagree? Curious to hear whether, in your experience too, the worst incidents also started "one layer below" Kubernetes.

Linux from Zero #2 Processes: what's actually running under your terminal

Roger Oliveira — Fri, 21 Aug 2026 19:40:58 +0000

Part 2 of the "Linux from Zero" series. If you haven't read #1 yet, it's on Medium and DEV.to — start there to understand the approach: investigate through evidence, not by memorizing commands.

The problem nobody explains properly

Have you ever run ps aux and watched a huge list of lines scroll by, without really knowing what to do with it? Most tutorials teach you the command, but not how to think about what it returns. This post is about exactly that: turning a list of numbers into reasoning about what your machine is actually doing.

The experiment

Open two terminals side by side. In the first one, run:

sleep 300 &

This creates a process that just "sleeps" for 300 seconds — doing nothing useful, on purpose, so it can be our test subject.

In the second terminal, run:

ps -eo pid,ppid,stat,etime,cmd | grep sleep

You'll see a line similar to this:

  PID   PPID STAT     ELAPSED CMD
12345   9876 S           0:03 sleep 300

Now the question that actually matters: what is each of these columns telling you about this process's life?

PID — the unique identity of this process for as long as it exists.
PPID — who created this process (the parent process). In your case, probably the shell in your first terminal.
STAT — the current state. S means "sleeping" (interruptible). You'll see R (running), Z (zombie), and D (uninterruptible I/O wait) in other contexts — each one tells a different story about what is or isn't blocking the system.
ETIME — how long it's been alive.

Why this actually matters

In production, nobody runs sleep on purpose — but every performance incident I've ever investigated started with exactly this question: "which processes are running, who's the parent of what, and what state are they stuck in?". A process stuck in D state (uninterruptible sleep) for a long time, for example, is almost always a symptom of a disk or storage problem — not an application bug.

Now try killing the process through its parent, not the sleep itself:

kill -TERM <your_shell_PPID>

Don't actually run this in your main terminal — it's just so you can mentally picture what would happen: killing the parent process usually kills the sleep child too (or it gets "adopted" by init/systemd, depending on the system). This reparenting behavior is the same logic behind why, when a container dies unexpectedly, the processes it was hosting disappear along with it.

The bridge to where this series is going

This parent/child relationship between processes is exactly what Linux uses as the foundation for isolating processes into namespaces — the mechanism that, later in this series, becomes containers, and that Kubernetes orchestrates at scale. Understanding processes today, without rushing, is what makes the "aha" moment happen when you get to cgroups and namespaces a couple of posts from now.

Try it yourself

Before the next post, try answering these on your own machine (no need to reply here, this one's for you):

Run ps -eo pid,ppid,stat,etime,cmd --forest and visually identify which process is the parent of which.
Find (or fail to find) a process in Z (zombie) state — if you don't find one, that's already useful information: your system is healthy on that front right now.
Compare ps aux with top (or htop) running at the same time — what changes between a static snapshot and a continuous view?

Next in the series: namespaces, and what actually isolates one process from another — the foundation of everything we now call a "container".

Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr

Have you ever run into a process stuck in D state during a real incident? What caused it? I'm collecting real-world examples for the next posts in this series — drop them in the comments.

Linux from Zero #1: What Is Linux and Which Distribution Should You Choose?

Roger Oliveira — Mon, 17 Aug 2026 23:31:30 +0000

Linux from Zero #1: What Is Linux and Which Distribution Should You Choose?

When people start studying DevOps, SRE, or Kubernetes, they usually find a long list of tools. But there is a layer underneath all of them: the operating system.

If you do not understand processes, permissions, services, networking, and logs, every container or cluster error can feel mysterious.

Which distribution should you choose?

Ubuntu LTS

My recommendation for a first lab. It has a large community, extensive learning material, and is widely used in cloud environments.

Debian Stable

A strong choice for learning a stable server foundation and the Debian ecosystem. Use it after your first contact with Linux.

Kubernetes from Scratch What It Is, How to Avoid Crashing Your PC, and Creating Your First Pod

Roger Oliveira — Tue, 11 Aug 2026 12:34:35 +0000

How to understand the world's most famous orchestrator using the cargo ship analogy — and run your first lab 100% in your browser.

If you are starting out in IT, migrating to DevOps, or looking to advance toward technical leadership roles (such as Staff/Principal Engineer), the word Kubernetes crosses your path every single day.

However, the first barrier is almost always the same: "Where do I start without drowning in heavy theory and without freezing my computer?"

In this first article of the Kubernetes from Scratch series, we will demystify core concepts using real-world analogies, understand the basic architecture, and launch your first live application in less than 5 minutes — completely free and directly inside your browser.

1. The Core Analogy: The Automated Port 🚢

To understand Kubernetes, you don't need complex jargon. Think of global maritime logistics:

The Application (Your Code): This is the goods needing delivery (e.g., an e-commerce store or a banking system).
The Container (Docker): This is the standardized metal cargo box. It doesn't matter if there are shoes, electronics, or food inside: from the outside, the dimensions and locking mechanisms are universal. It runs the exact same way on your laptop as it does in the cloud.
The Pod: This is the exact space (the rack or ship deck area) where one or more containers sit and work together. In Kubernetes, the Pod is the smallest unit you manage.
Kubernetes (The Port Captain): This is the robotic conductor. If a cargo box falls into the sea (an application error), the Captain instantly creates a brand-new box in its place within seconds. If traffic surges during Black Friday, the Captain automatically requests more ships.

2. The Golden Rule: Forget Local Clusters at First 💡

One of the biggest mistakes beginners make is trying to install tools like Minikube or Kind on resource-constrained laptops. The computer freezes, the cooling fans go wild, and learning turns into frustration.

Pro Tip: In the official CNCF exam (the CKA - Certified Kubernetes Administrator) and in real-world production environments, work is done via a Linux terminal and a web browser.

That is why we use Killercoda (killercoda.com): a free platform that provides a real Kubernetes cluster running directly in the cloud through your browser.

3. Hands-On: Your First Pod in the Browser 🛠️

Go to killercoda.com/playgrounds and select the Kubernetes Playground environment.

Once the terminal screen loads, follow these 3 quick steps:

Step 1: Terminal Survival Kit

Whenever you start a new lab environment, set up an alias to save keystrokes and adjust the .yaml file formatting for the vim editor:

# 1. Shortcut for kubectl
alias k=kubectl

# 2. Configure Vim to respect 2-space YAML indentation
echo "set tabstop=2 shiftwidth=2 expandtab" >> ~/.vimrc

Step 2: Spin Up an Application Imperatively

Instead of writing dozens of lines of YAML manually from scratch, use imperative commands to generate resources quickly:

# Create a Pod running an NGINX web server
k run my-web --image=nginx:alpine

Step 3: Inspect Your Resource

Check if your Pod is up and running:

k get pods

If the status shows Running, congratulations! You have just placed your first container under Kubernetes orchestration.

4. What To Do When Things Go Wrong? 🔍

The most valuable skill in daily operations is Troubleshooting. If your Pod fails to start, follow this investigation sequence in your terminal:

# 1. Check the general status of the Pod
k get pods

# 2. Inspect cluster events (WHAT happened?)
k describe pod my-web

# 3. Analyze container logs (WHY did the application fail?)
k logs my-web

📚 Next Steps & Official Sources

This article is just the gateway. To deepen your learning in a structured way:

GitHub Open-Source Repository: All code, guides, and practical exercises from this series are hosted on GitHub: https://github.com/roger-oliveira86/kubernetes-do-zero-ptbr.
Official Documentation (CNCF): Get comfortable searching kubernetes.io/docs — it is your best friend in production and the only allowed reference material during certification exams.
Practice Platform: Work through guided scenarios covering RBAC, Storage, and Troubleshooting at Killercoda.

💬 What About You?

What was the biggest challenge you faced when you first tried to learn Kubernetes? Leave a comment below and share this article with anyone starting their Cloud Native journey!

Kubernetes #DevOps #CloudNative #Docker #TechCommunity #CKA

What 9 articles in 15 months taught me about writing with consistency

Roger Oliveira — Mon, 03 Aug 2026 22:57:56 +0000

I have a strange publishing pattern. Five articles in four months. Then seven months of complete silence. Three articles in five weeks. Then almost three months of silence again. One article. And here I am, trying to understand what this pattern actually means before I simply promise "I'm going to post every week" and repeat the cycle.

Between April and July 2025, I wrote about the fundamentals: a platform engineering study plan, the signs that an infrastructure needs modernization, the strategic role of someone who operates beyond technical execution, and the bridge between engineering and business. In the middle of all that, I also wrote about workplace burnout—not because I planned a "different" kind of article, but because it was what I had to say at that moment. That article, by the way, is still the one that represents me most from this first phase: it shows that consistency in producing technical content isn't incompatible with admitting that sometimes you just lack the energy to produce anything at all.

Then, silence. Seven months.

It wasn't for lack of topics. It was the kind of period where operations consume all the energy that would otherwise be left to reflect on them—and reflecting in writing requires a different kind of energy than resolving an incident.

When I came back in March 2026, the tone had shifted. "Software Architecture is Actually Decision Management" is no longer about tools or warning signs—it's about how technical decisions carry consequences that survive far beyond those who made them. Two weeks later, "Systems Scale the Same Way Organizations Do" continues that line of thought: architecture isn't just code, it's decision structure. And three weeks after that, "You Don't Scale Systems While You Remain Their Central Point" hits the most uncomfortable point of the three—that sometimes, the bottleneck is me.

Three dense articles in five weeks. And silence again—this time almost three months, until "Rollback Isn't a Backup Plan. It's a Culture." in July, written in English and targeting a broader audience than the previous ones.

This isn't a pattern of laziness. It's a spike pattern: I write when a thought has matured enough to become a piece of writing, not at the artificial pace of an editorial calendar. The problem is that spikes are unpredictable—and unpredictability, for someone trying to build a consistent technical presence, is the opposite of what works.

So the change I'm testing now isn't "writing more." It's reducing the step size: instead of waiting for a full article to mature, recording a single paragraph, an unformed idea, or an unanswered question—every week, not just when the spike hits. If it yields an article, great. If it doesn't, at least there's a trace showing that the thinking didn't stop during the silent months; it just wasn't ready for publication.

If you also write in spikes, or have tried a cadence that didn't hold up—leave a comment below with what worked (or didn't) for you.