diff --git a/about.html b/about.html new file mode 100644 index 0000000..0148a53 --- /dev/null +++ b/about.html @@ -0,0 +1,351 @@ + + + + + + About — Ausb + + + + + + + + + + + + +
+ + ← Home + +
+

Austin Edmonson

+

Platform engineer · DevOps · software builder

+ +
+ +
+

I know most cover letters today are written with generative AI in some form, and honestly, I think that says something important about where engineering is going. I deeply value AI tooling, not because it replaces engineering, but because it sharpens it. It has changed how I learn, how I build, and how quickly I can move from idea to implementation while still staying thoughtful about reliability, security, and maintainability.

+

I use different tools intentionally depending on the problem space. I lean on Claude Code heavily for development workflows and rapid iteration, ChatGPT for documentation, architecture exploration, and learning, Copilot within VS Code for workflow acceleration, and DeepSeek for deep technical explanations and software engineering fundamentals. These tools have made me dramatically more productive, but more importantly, they have helped reinforce strong engineering habits, better design decisions, and faster feedback loops.

+

I bring 6+ years of experience across DevOps, platform engineering, systems administration, and software engineering, with a strong focus on security, secrets management, CI/CD, Kubernetes, observability, and operational reliability. Much of my background has been shaped by learning directly in production environments and building systems alongside the people who depend on them every day. Being self-taught taught me how to understand systems from the ground up—how infrastructure, applications, networking, automation, and developer workflows all connect together.

+

Over the course of my career, I've worked across multiple engineering teams and environments, each with different operational needs and engineering cultures. That exposure taught me not only how to build systems, but how to build systems that teams can realistically operate and maintain.

+

Recently, much of my work has centered around Kubernetes delivery systems and developer enablement at The Home Depot. I own CI/CD workflows responsible for building, scanning, testing, and deploying services into Kubernetes infrastructure. I also led efforts to simplify overly complex Terraform-driven operational workflows by shifting our delivery model toward a more maintainable managed Kubernetes platform and standardized CI-driven deployments. A major part of that work involved designing reusable repository templates, parameterized Kubernetes deployment patterns, and automation pipelines that made service onboarding and deployment dramatically simpler for engineers.

+

I also spend a significant amount of time focused on observability and operational insight using Grafana. I've built dashboards that helped teams struggling with connectivity and visibility issues gain real operational awareness into their services, Kubernetes health, logs, traffic patterns, and platform behavior. I enjoy taking noisy systems and turning them into something engineers can actually reason about.

+

What excites me most about the future of engineering is that we are entering a period where strong engineers will not just write code—they will orchestrate systems, workflows, automation, and intelligence together. I learned DevOps and software engineering before the rise of generative AI, but I've also embraced how these tools can accelerate learning and execution without losing craftsmanship or depth. I believe that balance matters.

+

At the end of the day, I care deeply about building systems that are reliable, understandable, secure, and genuinely useful to the people who rely on them. I enjoy thoughtful engineering, elegant automation, and solving problems in ways that reduce friction for teams. That combination of curiosity, adaptability, and systems thinking is what I would bring to your organization.

+
+ + + +
+ + diff --git a/assets/pics/getty-museum.jpg b/assets/pics/getty-museum.jpg new file mode 100644 index 0000000..748a348 Binary files /dev/null and b/assets/pics/getty-museum.jpg differ diff --git a/index.html b/index.html index 84d51ba..cbccb36 100644 --- a/index.html +++ b/index.html @@ -135,6 +135,22 @@ animation: fadeUp 0.45s ease both 0.05s; } + .hero-box { + display: inline-block; + padding: 1.5rem 2rem 1.75rem; + position: relative; + } + + .hero-box::before { + content: ''; + position: absolute; + inset: 0; + border: 3px solid var(--ink); + border-radius: 24px; + filter: url(#wobbly); + pointer-events: none; + } + .hero-name { font-family: 'DM Sans', sans-serif; font-size: clamp(4.5rem, 12vw, 9rem); @@ -153,7 +169,6 @@ line-height: 1.3; color: #5A5A5A; max-width: 28ch; - filter: url(#wobbly); } /* ─── SECTION ─── */ @@ -249,6 +264,7 @@ .tag-design { background: #EDE9FE; color: #5B21B6; border-color: #DDD6FE; } .tag-engineering { background: #D1FAE5; color: #065F46; border-color: #A7F3D0; } .tag-ux { background: #FCE7F3; color: #9D174D; border-color: #FBCFE8; } + .tag-infra { background: #E8EEF8; color: #2D4470; border-color: #B8C8E8; } /* ─── CARD GRID ─── */ .card-grid { @@ -378,6 +394,8 @@ border-radius: 3px; white-space: nowrap; align-self: flex-start; + justify-self: start; + width: fit-content; } .badge-active { background: #D6E8FF; color: var(--blue-dk); } @@ -386,10 +404,10 @@ /* ─── ABOUT STRIP ─── */ .about-strip { - background: var(--white); - border: 2.5px solid var(--ink); + background: var(--ink); border-radius: 20px; overflow: hidden; + box-shadow: 0 1px 4px rgba(0,0,0,0.06); margin-bottom: 3rem; animation: fadeUp 0.45s ease both 0.08s; } @@ -397,7 +415,7 @@ .about-bio { font-size: 1rem; line-height: 1.65; - color: #4A4A4A; + color: rgba(255,255,255,0.8); letter-spacing: -0.01em; margin-bottom: 0.65rem; max-width: 58ch; @@ -487,6 +505,29 @@ padding: 0.45rem 0.75rem; background: #FFB347; border-bottom: 1px solid #E08030; + gap: 0.5rem; + } + + .music-squiggle-wrap { + flex: 1; + overflow: hidden; + height: 22px; + min-width: 0; + } + + .music-squiggle { + display: block; + width: 200%; + height: 100%; + animation: sq-flow 2.2s linear infinite; + animation-play-state: paused; + } + + .music-squiggle.playing { animation-play-state: running; } + + @keyframes sq-flow { + from { transform: translateX(0); } + to { transform: translateX(-50%); } } .music-label-tag { @@ -683,6 +724,26 @@ opacity: 0.75; } + /* ─── FOOTER ─── */ + .site-footer { + border-top: 1px solid var(--border); + padding-top: 2rem; + margin-top: 1rem; + display: flex; + align-items: center; + justify-content: space-between; + color: var(--muted); + font-size: 0.78rem; + } + + .site-footer a { + color: var(--muted); + text-decoration: none; + transition: color 0.15s; + } + + .site-footer a:hover { color: var(--ink); } + /* ─── ANIMATIONS ─── */ @keyframes fadeUp { from { opacity: 0; transform: translateY(10px); } @@ -744,11 +805,13 @@ .nav-burger { display: flex; } .about-bio-wrap { padding: 1.25rem; } .about-inner { flex-direction: column; } - .about-links { border-left: none; border-top: 2px solid #C8D880; flex-direction: row; flex-wrap: wrap; gap: 0.5rem 1.25rem; padding: 0.85rem 1.25rem; min-width: unset; } - .music-widget { right: 0.75rem; bottom: 0.75rem; width: calc(100vw - 1.5rem); max-width: 320px; } + .about-links { border-left: none; border-top: 2px solid #C8D880; border-bottom: 2px solid #C8D880; flex-direction: row; flex-wrap: wrap; gap: 0.5rem 1.25rem; padding: 0.85rem 1.25rem; min-width: unset; } + .music-widget { right: 0.75rem; bottom: 0.75rem; width: calc(100vw - 1.5rem); max-width: 320px; filter: none; } .music-widget.mini { width: 210px; max-width: 210px; } .post-editorial-row { grid-template-columns: 56px 1fr; gap: 0.75rem; padding: 0.9rem 1rem; } .post-editorial-tag { display: none; } + .hero-name { font-size: clamp(5.5rem, 22vw, 9rem); } + .about-bio { font-size: 0.875rem; line-height: 1.6; } } @@ -761,7 +824,8 @@ @@ -781,7 +845,8 @@ @@ -805,22 +870,9 @@
-

Ausb.

-

Software engineer focused on infrastructure, automation, and software that reduces complexity for real people.

-
- - -
-
-
-

I build things that are hard to get right and matter when you do. Right now I’m building Partida — immigration case management for families moving to Portugal — while leading platform engineering work focused on CI/CD, deployment systems, security scanning, observability, and internal automation.

-
- +
+

Ausb.

+

Software engineer focused on infrastructure, automation, and software that reduces complexity for real people.

@@ -868,7 +920,7 @@

Ausb.

- +
@@ -896,17 +948,23 @@

Ausb.

+ + May 2026 + We Were Overengineering Ourselves Into Operational Exhaustion + Infrastructure + + Apr 2026 Why we built Partida: the gap no one was filling in immigration tech Product - + Feb 2026 @@ -914,22 +972,48 @@

Ausb.

Engineering
- +
+ +
+ +
+ + +
Now Playing
-
+
+ + + +
+
@@ -1006,6 +1090,7 @@

Ausb.

function setPlaying(playing) { bars.forEach(b => b.classList.toggle('paused', !playing)); + document.getElementById('musicSquiggle').classList.toggle('playing', playing); playPause.textContent = playing ? '⏸' : '▶'; } diff --git a/photo.html b/photo.html new file mode 100644 index 0000000..9698db5 --- /dev/null +++ b/photo.html @@ -0,0 +1,418 @@ + + + + + + Photos — Ausb. + + + + + + + + + + + +
+ + + +
+ + Getty Museum interior +

Light through curved glass. Everyone moving, no one in a hurry.

+
+ +
+ +
+ + Birds flying over a subway in Vienna +

Birds over the U-Bahn.

+
+ +
+ +
+ + Young woman at a museum in Porto +

Looking out a window in Porto. Shot on film.

+
+ +
+ +
+ + Young woman on the phone at sunset +

On a cell phone at sunset.

+
+ +
+ +
+ + Susto sound check +

Susto sound check.

+
+ +
+ +
+ + Guitar solo on stage +

Shredding.

+
+ +
+ +
+ + Young man on a road bike in Prague +

Somewhere near the old town.

+
+ +
+ +
+ + Night fishing, black and white +

Night fishing is a thing.

+
+ + + +
+ + + + + diff --git a/photojournal.html b/photojournal.html index 3d4595b..a197aed 100644 --- a/photojournal.html +++ b/photojournal.html @@ -1,132 +1,2 @@ - - - - -My Photo Journal - - - - - -
- -

- foto jrnl. -

-
Enjoy my photography (っˆڡˆς)


- -
- Birds flying over a subway in Vienna. The photo is in black and white. -

September 2025:Birds flying around in Vienna.

-
- -
- Young women talking on the phone in jeans and white t-shirt talking on the phone. -

August 2025: On a cell phone at sunset in GA.

-
- -
- The band Susto working on sound check in their concert. Nashville TN -

August 2025:Susto sound check.

-
- -
- Young women at a museum in Porto. -

August 2025: Young woman in a museum looking out a window in Porto, PT. on film 🌊

-
- -
- Young man sitting on an Author road bike in Nike trainers high white socks grey sweat pants and a black puffer jacket. Looking slightly at the camera. Shot in Prague, Czech Republic -

December 2024: Young man in Prague, CZ 🌊

-
- -
- Z ripping a guitar solo on stage in Nashville, TN -

July 2024: Shredding in Nashville, TN

-
- -
- Young man holding a bass fish at night in a black shirt with a flash. The picture is in black and white. BLURR -

June 2024: Night fishing is a thing..?

-
- - ◀ Back to Home -
- - + + diff --git a/terraform.html b/terraform.html new file mode 100644 index 0000000..851c0de --- /dev/null +++ b/terraform.html @@ -0,0 +1,176 @@ +Sometimes the Best Infrastructure Decision Is Removing Infrastructure + +There’s a certain phase every engineering team goes through where everything starts becoming “enterprise grade.” + +Terraform modules get layered on top of Terraform modules. CI pipelines call other pipelines that trigger workflows that eventually update YAML that updates another system that finally deploys the thing you originally wanted to change three hours ago. + +At some point, your infrastructure starts feeling less like engineering and more like participating in an ancient ceremonial process where nobody wants to touch the sacred state file. + +I say this with love because I genuinely like Terraform. It solves real problems. But I also think small and mid-sized teams sometimes inherit infrastructure patterns designed for organizations with entire platform departments dedicated to maintaining them. + +And sometimes the most senior engineering decision you can make is admitting: + +“We are overengineering this.” + +That realization hit our team slowly. + +We had Kubernetes workloads running on GKE, Terraform Enterprise managing pieces of infrastructure, secrets moving through multiple systems, and operational workflows that looked great in architecture diagrams but were exhausting in practice. + +Simple tasks somehow became: + +Open Terraform +Update module +Run plan +Hope state is healthy +Wait for approvals +Re-run because drift happened +Inject secrets somewhere else +Finally deploy application + +Meanwhile, developers just wanted to ship software without feeling like they were diffusing a bomb. + +The deeper issue wasn’t Terraform itself. The issue was that our operational complexity had outgrown the actual needs and staffing of the team. We didn’t have a dedicated army of infrastructure specialists managing module lifecycle strategy and provider drift full time. We had engineers trying to support services, ship features, maintain uptime, and survive meetings. + +So we stepped back and asked a much simpler question: + +What are we actually trying to optimize for? + +The answer wasn’t “maximum infrastructure flexibility.” + +It was: + +reliable deployments +simpler operations +easier onboarding +faster delivery +fewer moving parts +less fear around making changes + +That changed everything. + +We moved toward a managed Kubernetes platform and simplified our ownership boundaries significantly. Instead of continuously managing infrastructure orchestration layers, we focused on application delivery and operational consistency. + +At the same time, we moved secrets management into a native secret management platform rather than threading sensitive configuration through multiple CI/CD layers like a very stressful game of telephone. + +The result was honestly kind of refreshing. + +Our CI/CD pipelines became dramatically simpler: + +build +test +scan +deploy + +That was it. + +No giant infrastructure orchestration dance every time someone needed to update something small. + +We also standardized deployments through reusable repository templates and parameterized Kubernetes manifests so engineers didn’t need to become accidental platform experts just to launch a service. + +And interestingly, removing complexity improved reliability more than adding additional “safety” layers ever did. + +That’s the part I think engineering culture sometimes misses: +complexity itself is a production risk. + +Every abstraction layer has an operational cost. Every clever system creates future debugging sessions. Every additional tool requires ownership, context, maintenance, and emotional energy from the people running it. + +Small teams especially need to protect themselves from infrastructure ambition creep. + +Because eventually you wake up and realize: +you didn’t build a platform for developers — +you built a full-time job maintaining the platform itself. + +I still believe deeply in infrastructure-as-code, automation, and platform engineering. But I also believe maturity as an engineer is learning when not to build the more complicated thing. + +Sometimes the best architecture decision is the one that lets your team breathe again. + + + +======= + + +There’s a very specific kind of fear that enters a small engineering team when someone says: + +“Don’t worry, Terraform manages it.” + +At first, it feels comforting. Infrastructure as code. Reusable modules. Enterprise-grade workflows. Clean architecture diagrams. Everything versioned. Everything declarative. Everything “scalable.” + +Then six months later, someone needs to rotate a secret and suddenly three engineers are staring at a failed Terraform plan like archaeologists trying to decode an ancient warning tablet. + +I don’t say that to knock Terraform. Terraform is powerful. In the right environment, with the right staffing and operational maturity, it solves real problems elegantly. + +But small teams have a dangerous habit of inheriting infrastructure patterns designed for organizations with: + +platform divisions +dedicated infra specialists +module governance +architecture committees +and at least one engineer whose entire personality is Terraform state management + +We did not have that team. + +What we had was a fast-moving engineering group trying to support internal services, deployments, automation, Kubernetes workloads, CI/CD, and operational reliability all at once. + +And over time I realized something uncomfortable: + +We were spending more time managing the infrastructure abstraction layer than the infrastructure itself. + +Simple things became emotionally expensive. + +Updating cluster-related configuration became: + +Open Terraform repo +Update variables +Wait for plan +Hope state is healthy +Debug permissions +Re-run pipeline +Reconcile environment drift +Finally deploy the actual change you wanted in the first place + +At some point I had to ask: +Why are we treating every operational change like we’re provisioning AWS for a Fortune 50 company? + +The deeper issue wasn’t tooling. It was complexity ownership. + +Infrastructure had become “correct” in theory but painful in practice. The system optimized for flexibility and abstraction instead of operability. We built something architecturally impressive that quietly exhausted the people maintaining it. + +So we changed direction. + +We moved our workloads onto a managed Kubernetes platform and simplified the ownership model dramatically. Instead of treating every piece of infrastructure as something we needed to orchestrate through Terraform, we focused on standardizing application delivery and reducing operational surface area. + +CI/CD became the center of the workflow: + +build +test +scan +deploy +repeat + +We also centralized secrets into a native secrets management solution instead of threading sensitive configuration through multiple Terraform layers and deployment abstractions. That one change alone removed a shocking amount of operational friction. + +Suddenly: + +developers could reason about deployments again +onboarding became simpler +secrets management became cleaner +pipelines became easier to troubleshoot +and fewer people were afraid to touch production systems + +One of my favorite engineering lessons from this experience is that overengineering rarely feels like overengineering while you’re building it. It usually feels responsible. Mature. Future-proof. + +Until your team becomes the unpaid emotional support group for your architecture. + +That experience changed how I think about platform engineering entirely. + +Now I care much more about: + +operational clarity +cognitive load +onboarding friction +maintainability +and whether a team can sustainably operate the thing they built six months from now + +Sometimes the best infrastructure decision is not adding another abstraction layer. + +Sometimes it’s removing three of them. \ No newline at end of file diff --git a/writing/designing-50-plus.html b/writing/designing-50-plus.html index f5c10b8..9d22229 100644 --- a/writing/designing-50-plus.html +++ b/writing/designing-50-plus.html @@ -275,7 +275,8 @@ diff --git a/writing/navigation-discoverability.html b/writing/navigation-discoverability.html index 214c361..807c798 100644 --- a/writing/navigation-discoverability.html +++ b/writing/navigation-discoverability.html @@ -274,7 +274,8 @@