SYSTEMS FIRST.
ABSTRACTIONS SECOND.
A career built around infrastructure, operating systems, networks, automation, cloud platforms and the systems that run on top of them.
An infrastructure engineer who grew with the stack.
More than two decades in infrastructure engineering creates a particular perspective.
Technology changes constantly. The underlying engineering problems do not.
Systems still need to be reliable. Networks still need to move packets. Operating systems still manage processes and memory. Storage still fails. Applications still depend on infrastructure. And production still has a way of finding assumptions that were never tested.
ROOT // SYSTEMS is a record of that engineering journey.
From systems to platforms.
UNIX / LINUX
Operating systems, processes, filesystems, permissions, shells, services, storage, performance and troubleshooting.
NETWORKING
TCP/IP, routing, DNS, firewalls, load balancing, network services and the behaviour of distributed systems.
REPEATABILITY
Shell, configuration management, provisioning and operational automation.
IaC / CLOUD
Infrastructure defined as code, cloud architecture, networking, identity and reproducible environments.
KUBERNETES
Container orchestration, cluster architecture, workload scheduling, networking, storage and GitOps.
PLATFORM ENGINEERING
Turning infrastructure into reliable, self-service capabilities for engineering teams.
Where the engineering lives.
Operating Systems
UNIX · Linux · FreeBSD
Processes, memory, filesystems, boot systems, services, permissions, storage and performance.
Cloud Infrastructure
GCP · AWS · Hybrid Infrastructure
Compute, networking, IAM, storage, availability, scaling and infrastructure architecture.
Kubernetes
Kubernetes · GKE · Containers
Cluster architecture, workloads, networking, storage, scheduling and operational reliability.
Infrastructure as Code
Terraform · OpenTofu · Ansible
Declarative infrastructure, configuration, modules, provisioning and repeatability.
GitOps / CI/CD
Git · Pipelines · Continuous Delivery
Version-controlled desired state and automated delivery into production environments.
Reliability
Observability · Troubleshooting · Performance
Understanding system behaviour and finding the actual failure rather than treating symptoms.
Design the system before choosing the technology.
Architecture starts with requirements, constraints and failure domains.
Technology selection comes afterwards.
A good architecture should answer questions such as:
- What happens when a component fails?
- Where is state stored?
- What is the failure domain?
- How does the system scale?
- How is it observed?
- How is it secured?
- How is it recovered?
- How is it changed safely?
↓
CONSTRAINTS
↓
FAILURE DOMAINS
↓
DEPENDENCIES
↓
DATA FLOW
↓
SECURITY
↓
OBSERVABILITY
↓
AUTOMATION
↓
OPERATIONS
Production experience changes how you design systems.
A system that works in a lab is not necessarily a system that works in production.
Production introduces scale, concurrency, dependencies, human behaviour, change, failure and time.
Everything eventually fails.
The question is not whether it will fail.
The question is what happens when it does.
Keep it running.
Remove single points of failure and understand the consequences of degraded components.
Know what is happening.
Metrics, logs, traces and useful operational signals.
Know how to recover.
Backups, restoration, rollback, disaster recovery and tested operational procedures.
Change safely.
Automation, version control, staged rollout and the ability to reverse a bad change.
Follow the evidence.
Troubleshooting is not guessing.
Start with the symptom. Establish what changed. Gather evidence. Reduce the problem. Test a hypothesis. Verify the result.
The objective is not to make the error disappear. The objective is to understand why it happened.
↓
OBSERVE
↓
HYPOTHESIS
↓
TEST
↓
EVIDENCE
↓
ROOT CAUSE
↓
FIX
↓
VERIFY
The first error is not necessarily the root cause.
In distributed systems, the visible failure is often several layers away from the actual failure.
Make the correct operation the easiest operation.
Automation is more than saving time.
It reduces variation.
A documented manual procedure still depends on someone performing every step correctly.
An automated procedure can execute the same logic consistently every time.
↓
DOCUMENT
↓
AUTOMATE
↓
VERSION
↓
TEST
↓
OBSERVE
Cloud is infrastructure delivered differently.
Moving infrastructure into the cloud does not remove the fundamentals of infrastructure engineering.
Compute is still compute. Networking is still networking. Storage still has failure modes. Identity still matters. Capacity still matters.
- GCP
- AWS
- Compute
- Networking
- IAM
- Storage
- Scaling
- Cost control
- Availability
- Infrastructure automation
Cloud abstraction changes the implementation. It does not eliminate the engineering problem.
Kubernetes is powerful because it turns infrastructure into a control problem.
Kubernetes represents desired state and continuously works to make actual state converge toward it.
That model changes the way infrastructure can be operated.
manifest
↓
controller
↓
reconciliation
↓
actual state
Control Plane
API server, scheduler, controllers and cluster state.
Containers
Deployments, StatefulSets, DaemonSets, Jobs and Pods.
Connectivity
Services, ingress, DNS, routing and network policy.
State
Persistent volumes, storage classes and stateful workloads.
The next layer is not another tool. It is an engineering model.
Platform engineering brings infrastructure, automation, security, observability and developer experience together.
The objective is to provide engineering teams with a reliable path from source code to production.
↓
SOURCE
↓
CI/CD
↓
CONTAINER
↓
KUBERNETES
↓
OBSERVABILITY
↓
PRODUCTION
The rules that survive technology changes.
Understand before abstracting.
You cannot reliably operate what you do not understand.
Automate what repeats.
Manual repetition is an invitation for drift and error.
Observe everything important.
If a system matters, its behaviour should be measurable.
Assume failure.
Design systems around failure instead of treating it as an unexpected event.
Keep things reproducible.
Infrastructure should be rebuildable without relying on institutional memory.
Question assumptions.
"The network is fine" is not evidence.
The incidents are part of the education.
Some of the most valuable engineering knowledge comes from systems that did something they were never supposed to do.
A production incident forces theory to meet reality.
- The Server That Wouldn't Die
- When DNS Wasn't DNS
- The Friday Kernel Upgrade
- rm -rf: A Career Development Program
- The RAID Array That Lied
- That One Broken Symlink
- Production Was Full of Logs
- Why We Don't Edit Production Servers
Where infrastructure engineering is heading.
Internal Developer Platforms
Self-service infrastructure, golden paths, developer experience and platform products.
Autonomous Operations
Systems that can observe, reason about and respond to operational conditions within defined boundaries.
AI-Assisted Infrastructure
LLM-powered tooling, operational assistants, agentic workflows and intelligent infrastructure automation.
Engineering at Scale
Making large infrastructure environments predictable, observable and operationally sustainable.
The toolbox.
UNIX · LINUX · FREEBSD
CLOUD
GCP · AWS
CONTAINERS
DOCKER · CONTAINER RUNTIMES
ORCHESTRATION
KUBERNETES · GKE
INFRASTRUCTURE AS CODE
TERRAFORM · OPENTOFU
CONFIGURATION
ANSIBLE
DELIVERY
CI/CD · GITOPS
NETWORKING
TCP/IP · DNS · ROUTING · FIREWALLS
OBSERVABILITY
METRICS · LOGGING · TRACING
PLATFORM
INTERNAL DEVELOPER PLATFORMS · DEVELOPER EXPERIENCE
Technology is the tool. Engineering is the discipline.
The objective is never to use the newest technology simply because it exists.
The objective is to solve the problem with the appropriate level of complexity while producing a system that can be operated, understood, secured and recovered.
BUILD IT.
AUTOMATE IT.
OBSERVE IT.
BREAK IT.
FIX IT.
LEARN FROM IT.
Why this archive exists.
ROOT // SYSTEMS exists to document the knowledge that sits underneath modern infrastructure.
The commands. The architecture. The failure modes. The decisions. The lessons.
Learn the fundamentals.
Understand the abstraction.
Know what happens underneath it.
Then build something better.