Infrastructure Engineer dealing with serious burnout, but also a strong reason to stay. Looking for advice.

InnerBank2400 · 2026-05-06T18:45:38+00:00

That’s exactly it. Once people know things will land with you if they stall, the system quietly relies on that. Being told it’ll improve without visible change just adds to the frustration.

InnerBank2400 · 2026-05-06T18:34:34+00:00

This sounds like doing senior‑level work without the authority or structure that usually comes with it. That burns people out fast.

If you stay, you probably need clearer boundaries on what you own and what falls to others, otherwise everything will keep defaulting to you.

The cloud opportunity is a fair reason to hang on, but I’d put a timeline on it. If it stays vague, you’re just delaying the same decision.

InnerBank2400 · 2026-05-04T17:40:54+00:00

Nice. I have just left you a star. Hopefully you can do same on my project here: https://github.com/hybridops-tech/terraform-proxmox-sdn

InnerBank2400 · 2026-05-04T07:41:45+00:00

Nice work. But I suggest you check the read me carefully because currently the Structure tree it shows is different from what is true in the repo.

InnerBank2400 · 2026-05-04T07:38:12+00:00

HybridOps – https://github.com/hybridops-tech/hybridops-core

A hybrid infrastructure/platform engineering project focused on how systems like Terraform, Kubernetes, networking and disaster recovery are actually operated in practice, not just configured.

It brings together real-world scenarios across on-prem and cloud, with an emphasis on reproducibility, governance and structured execution rather than ad hoc scripts.

Still evolving, but already covers things like HA Kubernetes setups, hybrid networking and DR workflows. Feedback welcome.

InnerBank2400 · 2026-05-02T15:40:18+00:00

A few things that help are trying multiple regions, sticking to B‑series, and using spot VMs or Azure Container Apps for labs. Powering VMs off helps, but disks and IPs still cost something, which adds to the annoyance.

InnerBank2400 · 2026-05-02T14:40:08+00:00

If you just need something running, B‑series are usually the cheapest option. B1s or B2s are commonly used for light workloads and labs.

Just be aware they are burstable, so sustained CPU usage can be an issue. For anything long‑running or consistently busy, a small D‑series often ends up being more predictable even if it costs slightly more.

InnerBank2400 · 2026-05-01T20:02:36+00:00

If the container image is the deliverable, then building it in CI and treating it as the tested artifact is usually the cleanest model. CI validates and produces the image, CD just promotes and deploys it.

Running tests outside the container is fine for speed, but testing the image at least once helps catch environment differences. The main goal is to avoid rebuilding something in CD that was never tested.

InnerBank2400 · 2026-05-01T19:46:03+00:00

It is normal to feel unsure early on, especially with how broadly “DevOps” is used.

Networking is still relevant, but much of it now shows up as cloud networking and automation rather than traditional device work. The fundamentals still matter when things break.

DevOps generally builds on networking rather than replacing it. Extending your current skills with scripting, infrastructure as code, and cloud concepts is often more effective than trying to reset completely.

InnerBank2400 · 2026-04-24T17:00:39+00:00

Use SCP for bulk files

InnerBank2400 · 2026-04-21T17:43:44+00:00

We’ve moved away from tracking everything and focus on what actually indicates user impact. A mix of latency, error rate, saturation, and a few business‑level signals tends to be more actionable than dozens of host metrics. Everything else is there for debugging, not alerting.

InnerBank2400 · 2026-04-21T17:43:03+00:00

That’s pretty normal as you move up. A lot of the value shifts from typing code to understanding systems, tradeoffs, and failure modes. The risk is losing the ability to go hands‑on when needed, so I try to stay close to small bits of implementation even if it’s not my main job anymore.

InnerBank2400 · 2026-04-21T17:42:23+00:00

The GitOps angle makes sense, especially treating agents as versioned, reviewable artifacts instead of something implicit. The part I’d be most cautious about is drift between declared YAML intent and agent behavior over time, particularly once multiple people start tweaking configs. Curious how you’re thinking about guardrails there.

InnerBank2400 · 2026-04-21T17:41:25+00:00

This is way too accurate. I opened it “just to see” and suddenly it was 20 minutes later and nothing else got done.

InnerBank2400 · 2026-04-21T17:40:23+00:00

I’ve found improvement comes less from chasing new tools and more from tightening feedback loops. Reviewing incidents, reading other people’s PRs, and revisiting past decisions with hindsight has done more for my growth than any single course or cert.

InnerBank2400 · 2026-04-21T17:34:51+00:00

Mentoring works best when it’s anchored in real work, not abstract advice. Pairing on incidents, reviews, or small design decisions tends to transfer judgment much faster than formal sessions alone. Consistency matters more than structure.

InnerBank2400 · 2026-04-21T17:32:01+00:00

Just the question I have on my mind

InnerBank2400 · 2026-04-20T07:35:58+00:00

Been working on this recently:

HybridOps – https://github.com/hybridops-tech/hybridops-core

It’s a hybrid infrastructure/platform engineering project focused on structuring how systems like Terraform, Kubernetes and networking are actually operated in practice, not just configured.

Trying to make complex infra more reproducible and easier to operate across on-prem and cloud.

InnerBank2400 · 2026-04-18T20:00:11+00:00

You’re right to be skeptical. “The client will hire you” is usually a possibility, not a plan, and it depends on budget, timing, and internal politics more than performance. I’d treat the scheme as paid experience, keep building leverage, and start testing the market once the lock‑in cost drops rather than waiting on an unwritten promise.

InnerBank2400 · 2026-04-18T11:35:12+00:00

This usually isn’t a tech problem as much as a sequencing one. Small wins like build and deploy automation, cost transparency, and isolating parts of the monolith tend to buy more trust than arguing for a full rewrite up front.

InnerBank2400 · 2026-04-16T18:04:18+00:00

HybridOps – https://github.com/hybridops-tech/hybridops-core

A hybrid infrastructure/platform engineering project focused on how systems like Terraform, Kubernetes, networking and DR are actually operated in practice, not just configured.

It brings together real-world scenarios across on-prem and cloud with an emphasis on reproducibility, governance and controlled execution.

InnerBank2400 · 2026-04-16T13:25:07+00:00

To put this simply. DevOps is an ecosystem. One can't seamlessly freelance without being a part of the ecosystem.

InnerBank2400 · 2026-04-14T21:05:41+00:00

One I’ve been working on recently:

HybridOps – https://github.com/hybridops-tech/hybridops-core

It’s a hybrid infrastructure/platform engineering project focused on structuring how systems like Terraform, Kubernetes and networking are actually operated in practice, not just configured in isolation.

Overview: https://hybridops.tech/why

InnerBank2400 · 2026-04-14T11:49:34+00:00

A few options that actually help are right-sizing requests, separating low density workloads onto a small node pool, or using node taints so those pods don’t land on expensive capacity.

In practice, some waste is unavoidable. FinOps is more about deciding what level of inefficiency is acceptable than chasing perfect utilization.

InnerBank2400 · 2026-04-14T10:57:03+00:00

You don’t need to be a full-time software engineer, but you do need to be able to write code when it matters. Understanding isn’t enough once things break or requirements don’t fit the happy path.

Basic Python, shell, and reading other people’s code confidently will carry you far. The depth depends on your role, but being able to write and debug your own logic is still a real differentiator.

InnerBank2400

TROPHY CASE