About Me

#

I’m a Lead DevOps / Platform / Infrastructure Engineer working at Rough Country, where I design and operate the systems that power a high-traffic e-commerce platform.

My work sits at the intersection of cloud infrastructure, software engineering, and operational reliability—primarily across AWS, Kubernetes-adjacent patterns, containerized deployments, and large-scale e-commerce architecture.

But I don’t think of myself as just an infrastructure engineer.

I think in systems.

How I Think About Engineering

#

Most infrastructure problems aren’t actually technical problems—they’re complexity management problems.

My default approach is:

• Reduce moving parts
• Eliminate unnecessary state
• Automate anything that is repeated more than once
• Prefer predictable failure modes over “clever” systems
• Optimize for operability at 2 AM, not theoretical elegance

If a system is hard to reason about under pressure, it’s not done yet.

That mindset influences everything I build.

What I Work On

#

At Rough Country, my responsibilities span across:

• AWS infrastructure design and operations
• E-commerce platform reliability (Magento + modern frontend systems)
• CI/CD pipelines and deployment automation
• Docker-based scaling architectures
• Cloudflare edge configuration and traffic management
• Cross-region and high-availability planning
• Developer experience and internal tooling
• Code review, architecture guidance, and technical leadership

A large part of my role is not just building systems—but making sure they remain operable, debuggable, and resilient as they scale.

Architecture Philosophy

#

I don’t believe in over-engineered systems.

I believe in right-sized systems that evolve intentionally.

That usually means:

• Start simple
• Add complexity only when there is measurable pressure forcing it
• Prefer single sources of truth over distributed ambiguity
• Use managed services where it reduces operational burden
• Push logic to the edge (CDNs, frontend layers) where possible
• Avoid premature multi-region or distributed database complexity unless absolutely required

In practice, that’s led to architectures like:

• Hybrid Magento + Next.js storefronts
• ECS/Fargate-based frontend scaling layers
• EC2-based application tiers where control matters
• RDS with controlled replication strategies instead of full active-active complexity
• Cloudflare-first routing and caching strategies

Beyond Infrastructure

#

Outside of work, I apply the same systems thinking to how I operate day-to-day.

I maintain a highly structured workflow built around:

Knowledge Systems

#

I use Obsidian as a personal knowledge system, combined with AI-assisted refinement to continuously improve and restructure technical understanding—especially while studying AWS certifications.

Raw notes are treated as input data, not final output. They are refined into structured knowledge, then reinforced through active recall systems.

Physical Training System

#

I follow a structured 5 AM training schedule with a PPLUL split.

The goal isn’t optimization—it’s consistency under real-world constraints.

I treat fitness the same way I treat infrastructure:

If it depends on perfect conditions, it will eventually fail.

Linux + Desktop Environment

#

My primary development environment runs Arch Linux with Hyprland.

I manage my entire configuration using a fully declarative dotfile system (chezmoi), treating my desktop like infrastructure-as-code rather than a manually configured environment.

That includes:

• Templated configurations
• Machine-aware settings
• Automated reconciliation
• Encrypted secret injection
• Fully reproducible system bootstrap

Writing & Learning

#

I write about systems, infrastructure, and workflows as a way of refining how I think.

Most of what I publish comes from real implementation—not theory.

Topics I focus on include:

• AWS architecture decisions and tradeoffs
• E-commerce scaling patterns
• Developer infrastructure and CI/CD design
• Linux desktop automation and reproducibility
• Knowledge management systems
• Personal productivity systems built like engineering problems

Current Focus

#

Right now, my primary focus is continued professional development through AWS certification at the Professional level.

I’m actively working toward completing both AWS Professional certifications, with a focus on deepening practical understanding of large-scale cloud architecture, distributed systems design, and operational excellence in production environments.

This isn’t just exam preparation—it’s structured reinforcement of the systems I work with daily.

My study approach is intentionally hands-on and implementation-driven:

• Building and validating real AWS architecture patterns in labs
• Reproducing production-like failure scenarios to understand behavior under stress
• Using Obsidian as a structured knowledge system to refine and retain concepts over time
• Leveraging active recall and spaced repetition rather than passive reading
• Connecting certification material directly to real e-commerce infrastructure challenges

The goal is not simply to pass exams, but to strengthen architectural intuition in areas like:

• Multi-region system design and tradeoffs
• High availability and disaster recovery strategies
• Network architecture and edge routing (Cloudflare + AWS)
• Cost-aware scaling patterns in real production systems
• Operational resilience under incident conditions

This continues to feed directly into my work on e-commerce infrastructure at scale, where these patterns are not theoretical—they are applied daily in production systems that need to stay reliable under real traffic and real constraints.

Closing Thought

#

Good systems don’t require constant attention.

They absorb complexity, handle failure gracefully, and stay understandable under stress.

That’s what I try to build at work—and what I try to replicate in everything else I do.