As an engineer, I’ve always been drawn to systems — things that run cleanly, correct themselves, and gracefully handle change. But nothing has challenged my systems thinking quite like building a sustainable indoor shrimp farm.

Raising aquatic life indoors isn’t just about keeping tanks full — it’s about engineering resilient micro-ecosystems. That means controlling oxygen levels, regulating temperature, and ensuring consistent circulation — all while keeping energy use low and animal health high.

In this post, I’ll share how I used my DevOps mindset to design a robust aquatic environment using titanium heat exchangers, nanobubble oxygenation, and PEX-based closed-loop circulation — and how these elements come together to create a stable, efficient habitat for Pacific white shrimp.

Start with the Core: Thermodynamic Stability

Aquatic animals are incredibly sensitive to temperature. Even a couple degrees off can cause stress, slow growth, or trigger health issues. So the first design challenge was thermodynamic balance — how do I keep water temperature stable with minimal power and maximum consistency?

My answer: a closed-loop heat circulation system powered by a titanium heat exchanger.

Why Titanium?

Titanium isn’t just a cool material — it’s corrosion-resistant, durable, and most importantly, has excellent thermal conductivity in aquatic environments. It doesn’t react with saltwater, holds up in continuous flow conditions, and moves heat efficiently without introducing risk to livestock.

I paired the exchanger with a hydronic circulation loop using PEX tubing. The idea is simple: heat (or cool) the loop water using a small electric boiler or chiller, then use the titanium exchanger to transfer that energy into the tank water without direct contact. No contamination. No overcorrection. Just smooth, continuous temperature control.

Think of it as the Kubernetes of heat management — decoupled, modular, and designed to recover from drift without drama.

Bubbles That Matter: Oxygenation with Precision

Oxygen is life. For shrimp, low dissolved oxygen means stress, disease, and death. Traditional aerators (like air stones or diffusers) do a decent job, but I wanted a system that was not just effective — but efficient.

Enter nanobubble oxygenation.

What Are Nanobubbles?

Nanobubbles are microscopic gas bubbles — smaller than bacteria — that stay suspended in water longer than normal bubbles. Because of their size, they deliver oxygen more efficiently, increase gas transfer surface area, and can even help suppress harmful microbes.

They’re ideal for closed-loop environments where water turnover and gas exchange are limited. I integrated a nanobubble generator into the recirculation loop so that every gallon of water returning to the tank is supercharged with dissolved oxygen.

The result? Healthier shrimp, better feed conversion, and more consistent water chemistry — without the noise, mess, or inefficiency of traditional aerators.

Circulation: The Unsung Hero

No matter how good your heat or oxygen system is, it’s worthless without proper water flow.

Stagnant zones in an aquatic system can lead to:

• Uneven temperature
  
• Oxygen layering
  
• Waste buildup
  
• Biofilter imbalances
  

So I designed the entire system around laminar flow — creating consistent, predictable movement across all tank zones. Using inline pumps, flow meters, and valved branch circuits, I fine-tuned circulation to:

• Ensure even nutrient distribution
  
• Sweep solids toward mechanical filtration
  
• Keep bacteria colonies in the biofilter well-fed
  
• Maintain a stable ecosystem without harsh turbulence
  

This is where DevOps thinking really shines. Just like you’d balance load across services in a cloud platform, I balance flow across tanks, filters, and heat exchangers — using flow as the glue that holds everything together.

Automation + Monitoring = Freedom

As someone who’s worked in infrastructure, I know one thing: manual systems break under pressure.

That’s why I embedded automation from the start:

• Smart controllers for temperature and oxygenation
  
• Timed dosing and feeding systems
  
• Remote access dashboards showing tank conditions in real time
  
• Failover protocols for pumps and critical systems
  

Every critical variable — from temperature to oxygen saturation — is logged, trended, and alarmed. If something drifts out of range, I get a ping. That gives me peace of mind and allows me to focus on optimizing the system, not babysitting it.

This is how we do things in production-grade Kubernetes environments — and it turns out, it’s just as valuable in a shrimp tank.

Sustainability by Design

There’s a reason I built this system the way I did. Indoor aquaculture has incredible potential to produce clean, local protein with a low environmental footprint — but only if it’s designed right.

By combining:

• Energy-efficient heat loops
  
• High-efficiency oxygenation
  
• Optimized water circulation
  
• Minimal water exchange (recirculating)
  
• Automation and self-monitoring
  

…I’ve created a system that can run 24/7, with minimal waste and low energy use, while maintaining high standards for animal health and system stability.

It’s not just good engineering. It’s good stewardship.

A Living System, Built to Last

Building an indoor aquatic habitat isn’t that different from building a cloud-native infrastructure platform. In both cases, you’re designing for:

• Resilience against failure
  
• Balance between competing forces
  
• Visibility into real-time state
  
• Adaptability to changing conditions
  

And just like a platform, your habitat is alive — not in a poetic sense, but in the literal sense. If it’s off, you know it. If it’s right, it runs smoothly. The shrimp thrive. The system hums along.

I didn’t set out to merge tech and aquaculture. But in hindsight, it makes perfect sense. Whether it’s titanium coils or ArgoCD rollouts, the principles are the same.

Design thoughtfully. Monitor everything. And build systems that can take care of themselves.

I’ve been fishing since I was a kid. Long days on lakes and rivers taught me to slow down, watch for movement, and notice the subtle signals that tell you where the fish are — a swirl, a flick, a change in current.

Years later, I realized that observability in cloud systems isn’t so different. In both cases, you’re not reacting to loud alarms. You’re watching for patterns, listening for signals, and using those clues to adjust course.

As a platform and DevOps engineer, I’ve spent a good chunk of my life building observability stacks in production environments. Whether at Target, Icario, or running my own aquaculture business, observability has been the key to everything — from catching bugs before they explode to tuning system performance under heavy load.

This post is a mix of hands-on advice and philosophy. If you’re looking to upgrade your observability game — and maybe see logs the way an angler sees water — this one’s for you.

Observability vs. Monitoring: Know the Difference

Let’s start with a quick reminder: monitoring tells you what’s broken, observability tells you why.

• Monitoring: “CPU spiked above 90%.”
  
• Observability: “That spike was caused by a bad query deployed in version 1.3.8 during the lunch hour.”
  

Monitoring is about setting thresholds. Observability is about correlating signals across your system to form a narrative.

If you’re still only watching dashboards for red and green lights, you’re fishing with a stick and a string. It works — but you’re missing everything happening beneath the surface.

The Three Pillars (and Why They’re Not Enough)

We all know the “three pillars” of observability: logs, metrics, and traces. Here’s the fishing version:

• Metrics = water temperature. High-level signal, good for knowing if fish might be active.
  
• Logs = ripples and splashes. Tells you what just happened.
  
• Traces = underwater camera. Shows you where the fish went and how.
  

But real-world observability goes beyond those. You also need:

• Events: Deployment timestamps, feature toggles, config changes.
  
• Context: Metadata on users, requests, or devices.
  
• Topology: The system map. What talks to what. What fails when X goes down.
  

You want a lake map, sonar, weather radar, and a guide whispering, “Try casting near that fallen log.”

Build Your Stack Like an Ecosystem

Here’s a breakdown of my preferred observability stack in Kubernetes-based environments:

• Metrics: Prometheus (collected at pod/node level), Grafana for dashboards.
  
• Logs: Loki (if you’re all-in on Grafana), or ElasticSearch with Fluent Bit.
  
• Tracing: OpenTelemetry for instrumenting services, Jaeger or Tempo for visualization.
  
• Alerting: Alertmanager + Slack or PagerDuty integrations.
  
• Dashboards: Grafana templated views by service, workload, or region.
  

But don’t stop at setup. Think about how everything ties together — like an ecosystem. Your observability system should flow like a watershed: one source feeds the next, leading to clarity.

Fishing for Anomalies

In both SRE and fishing, anomalies are gold.

Maybe you see a spike in memory usage every Thursday at 3 p.m. Or a drop in traffic from one region after a new deploy. The untrained eye might ignore it — but if you’ve spent time watching the system, you know that something’s off.

The trick is to set up your observability to surface these anomalies before they become incidents:

• Use anomaly detection in your metrics platform (Prometheus + PromQL or tools like Grafana Machine Learning).
  
• Enrich logs with contextual data — request IDs, user IDs, build versions.
  
• Correlate deploy events with error rates or latency changes.
  
• Use tracing to surface why a request suddenly takes 400ms instead of 100ms.
  

I once caught a bug in an ML inference pipeline by noticing a tiny increase in response times for edge requests. It turned out to be a memory leak triggered only by a specific data structure. Without trace-level data, we’d still be scratching our heads.

Don’t Just Observe — Respond

Fishing teaches you to respond gradually. You don’t jerk the line at every nibble. You watch, feel, and adjust.

Observability should work the same way. The best systems don’t just tell you what’s happening — they help you decide what to do.

• Integrate automated rollback triggers on high error rates (e.g., with Argo Rollouts).
  
• Tie alerts to runbooks or ChatOps tools for fast action.
  
• Use SLOs and error budgets to guide decision-making, not panic.
  

Good observability isn’t just about clarity. It’s about confident response. When an incident hits, your signals should whisper: “Here’s where the problem is. Here’s what changed. Here’s what to do next.”

Tuning for Signal, Not Noise

Overalerting is like casting a line into a school of baitfish hoping for a bass. You get hits — but they don’t matter.

• Tune your alert rules. Aim for low noise, high confidence.
  
• Use severity tiers — not every 500 needs to page someone.
  
• Add for: clauses in Prometheus rules to avoid flapping.
  

Observability should make your team smarter, not more anxious. Every alert should teach something. Every dashboard should answer a question.

Fish Smarter, Not Harder

Building observability isn’t just a checklist — it’s a craft. It’s how we connect with our systems and understand what they’re really telling us.

Whether I’m debugging a degraded API or watching the ripples on a still lake, the question is the same:

What is this system trying to tell me — and how fast can I act on it?

You don’t need to be an expert fisherman to catch fish. But if you learn to read the water — just like learning to read your infrastructure — you’ll catch more, waste less time, and respond with calm confidence when something bites.

And honestly? That’s what engineering is all about.

I grew up fishing the lakes and rivers of Minnesota. As a kid, I didn’t think of it as anything special — it was just something we did. But over the years, as my career in tech evolved — from platform engineering at Target and Icario to launching my own shrimp farming startup — I realized something:

Fishing taught me about systems long before I wrote a line of code.

Whether you’re fishing a stream or deploying a model into production, the core idea is the same: observe, adapt, and react to feedback. Nature is one big loop of cause and effect, input and output, signal and response. And if you learn to pay attention to those loops, you become a better builder — in the woods and in the data center.

Nature Is One Giant Feedback Loop

Think about how an ecosystem works. Every element is in conversation with the others. Fish populations rise or fall based on oxygen levels, temperature, predators, and food supply. You don’t have to control the entire system — you just have to listen and make adjustments.

That’s the foundation of feedback-driven design in tech.

In platform engineering, we design systems to respond to metrics, logs, and events. When CPU spikes, we autoscale. When a model degrades, we retrain. When latency creeps up, we investigate. Every smart move we make comes from the feedback loop — not gut instinct alone.

The best engineers are the ones who listen like fishermen. They don’t panic at every ripple. They observe patterns. They wait for the right signal.

Fishing Teaches Patience with Systems

There’s something deeply humbling about fishing. You cast your line and… wait. You might not get a bite for minutes, hours — or at all. But when you do get a bite, you pay attention. What lure were you using? How deep were you fishing? What time of day was it?

Those questions are no different from debugging production systems.

• “What version was deployed when the bug started?”
  
• “What user flow triggered the latency?”
  
• “What changed in the environment before the crash?”
  

Fishing teaches you not to flail or guess. It teaches you to respect the system and learn from its behavior. That’s exactly how we should treat complex infrastructure or ML models — not with brute force, but with curiosity.

The Shrimp Tank as a DevOps Lab

When I built Homeland Shrimp, my indoor aquaculture system, I realized just how deeply nature and tech were intertwined. The tanks became a living experiment in system stability, automation, and — you guessed it — feedback.

• When oxygen levels drop, shrimp get sluggish. That’s a signal.
  
• When water temps rise too fast, biofilters react poorly. Another signal.
  
• If you feed too much too fast, ammonia spikes and throws off the balance. Immediate feedback.
  

You don’t get second chances in a live tank. And just like in production systems, the only way to stay ahead of problems is to build observability into the design.

I used the same principles I did at Target: metrics collection, threshold alerts, redundancy, graceful failure modes. Nature didn’t fight that structure — it thrived within it.

Machine Learning and the Art of Adaptive Systems

Machine learning is perhaps the most literal example of feedback in tech. You train a model, test its predictions, and fine-tune based on loss or accuracy. It’s trial and error, just like fishing — only faster and more precise.

But the danger in ML is thinking that feedback ends once the model is deployed. It doesn’t. Real-world data shifts. User behavior evolves. And if you’re not listening, your model becomes obsolete.

The best ML ops setups are inspired by biological systems — always adapting, always retraining, always filtering signal from noise. There’s a reason we call it a “learning” model. It’s not a one-time thing. It’s a conversation between data and action.

Just like a lake, a river, or a tank of shrimp.

Building with Feedback in Mind

If I’ve learned anything from nature, it’s this: don’t build static systems in a dynamic world.

Feedback loops should be part of the blueprint from day one. Whether you’re writing infrastructure as code, training a model, or farming shrimp, you need to know:

1. What are the signals that matter?
   
2. How will you observe them?
   
3. What’s your threshold for action?
   
4. How will the system adapt without burning down?
   

It’s not about making perfect systems. It’s about making systems that listen well and recover gracefully.

Why Engineers Should Spend More Time Outdoors

This might sound like a stretch, but I genuinely believe more engineers should fish — or hike, or garden, or observe wildlife. Not just for the stress relief (though that helps), but because nature is the best teacher of systems design.

Out in the wild, you learn to look for signals. You learn not to overcorrect. You learn that sometimes, doing nothing is the smartest move — and other times, a small tweak makes all the difference.

Those are the instincts that make great engineers. And they’re not found in a console log — they’re earned from years of watching the world work without your input.

Listening Is the Most Underrated Skill in Tech

In the end, fishing and engineering are about the same thing: learning to listen.

Not just to data, but to behavior. Not just to failures, but to subtle shifts. Not just to customers, but to the system itself.

Nature taught me that the best builders aren’t the ones with the most control — they’re the ones who design systems that respond well to change.

That’s what I try to do in everything I build — platforms, ML pipelines, shrimp farms, or life itself.

And it all started with a line in the water, waiting for the loop to complete.

I’ve spent over a decade building digital systems—Kubernetes clusters, CI/CD pipelines, cloud infrastructure, ML deployment frameworks. But some of the most meaningful work I’ve done recently didn’t happen in a datacenter or a terminal window. It happened in the yard of a senior citizen’s home, raking leaves and clearing gutters.

I volunteer with the Senior Community Services HOME program here in Minnesota. It’s a local initiative that helps older adults stay in their homes safely and independently—by supporting them with everyday tasks they can no longer do on their own, like yard cleanup or minor repairs.

It might not sound high-tech, but if you’re an engineer, builder, or problem-solver of any kind, I want to tell you why programs like this need people like us. And why helping someone stay in their home is just as valuable—maybe more so—than scaling any system in the cloud.

What the HOME Program Is All About

The HOME program (Household & Outside Maintenance for Elderly) works with seniors who want to age in place. That means living in their own homes, staying in their communities, and keeping their independence as long as possible. But sometimes, that independence hinges on small things: who’s going to clean out the gutters, fix the broken step, or rake up the leaves before winter?

That’s where volunteers like me come in.

It’s simple, really. In the spring and fall, I show up with a rake, a tarp, maybe a ladder. I clear leaves, sweep walkways, and check for little issues that could become big ones. A clogged gutter can lead to water damage. A buried sidewalk could mean a dangerous fall. And a lonely senior might just need someone to talk to for 15 minutes.

Why This Matters—Personally and Socially

Let me be clear—I’m not special. I just saw a need and knew I could help. I grew up in Minnesota. I’ve watched my own family members age. I know how important it is for people to feel safe and dignified in their own homes.

But here’s what surprised me: how much of my engineering mindset carried over into volunteering.

I assess the environment like I would a server room. What’s the load (wet leaves)? What’s the failure risk (blocked drains)? What’s the fastest and safest cleanup strategy? Even something as basic as laying out tools or sequencing tasks reminds me of troubleshooting systems: identify, prioritize, execute, verify.

The difference? When I finish, I see the homeowner’s smile. I see peace of mind. It’s instant feedback—and it feels good.

The Human Side of Systems Thinking

If you’re a technical person, you probably already think in terms of efficiency, systems, and dependencies. That’s a gift. And it doesn’t only belong in codebases or DevOps pipelines.

One woman I helped last fall hadn’t been outside in weeks because her front walk was covered in wet leaves and she was afraid of slipping. Clearing that path didn’t just tidy her yard—it gave her access to her world again.

Engineers solve problems for a living. But too often we forget that some of the most urgent problems aren’t inside a product—they’re in our communities.

Why Engineers Should Get Involved

Here’s the thing: engineers are uniquely equipped to support aging-in-place programs. We have:

• Analytical skills to assess problems and come up with practical solutions.
  
• Project thinking that helps us break big goals into manageable steps.
  
• Technical skills that can translate to light carpentry, home tech support, or safety audits.
  
• A tendency toward efficiency, which helps these programs scale their limited resources.
  

But more than any skill, we have the ability to show up—physically, locally, and with intention.

If you’ve ever been the “fix-it” person in your team or family, imagine doing that for someone who truly can’t do it on their own. That’s the kind of impact that sticks with you.

No Experience Needed—Just Willing Hands

One of the biggest misconceptions people have is that you need to be an expert to volunteer. You don’t. If you can rake, sweep, climb a few steps, or just carry conversation, you’re already qualified.

In fact, sometimes the presence matters more than the task. A lot of seniors live alone. Your visit might be their only real social interaction that week. A short conversation about weather, sports, or gardening can lift spirits more than you realize.

And if you’re in tech, you might even help fix a slow computer or reset a Wi-Fi router while you’re there. (Yes, I’ve done both.)

How to Get Started

If you’re in Minnesota, check out Senior Community Services and their HOME program. They’re always looking for seasonal volunteers and will pair you with residents in need.

If you’re elsewhere, look for similar programs through local councils on aging, nonprofit organizations, or community centers. Just search “aging in place volunteer” and your zip code—you’ll find opportunities.

You can start small. One house. One visit. One impact.

Building Stronger Systems, One Home at a Time

The same way we build fault-tolerant systems in tech, we can help build safer, more resilient communities in real life. Aging in place isn’t just about staying home—it’s about staying connected, empowered, and valued.

If you’re an engineer, a builder, or just someone who likes solving problems, your skill set is more useful than you think. And trust me—no amount of Kubernetes knowledge will feel as grounding as hearing someone say, “Thank you, I couldn’t have done this without you.”

So take an afternoon. Grab a rake. Go make a difference.

You’ll be glad you did.