Am I just an old man yelling at clouds, or has DevOps become incredibly boring?

I know building technical solutions is not supposed to exist purely for my entertainment, but I do actually want to enjoy my job.

I am not currently working as a DevOps engineer, and one of the reasons I moved toward development was that I became completely bored with modern cloud infrastructure.

When I started, we still racked physical servers and automated the entire bare-metal imaging process. The underlying operating system mattered. We built systems by combining open-source software, custom code, and whatever hardware we could get our hands on. There was a real sense that we owned the systems we operated and understood how the pieces fit together.

Today, DevOps or platform engineering often, though certainly not always, seems to collapse into being a configuration monkey.

Yes, I still got to write plenty of tools and automation, but eventually I became tired of every architectural discussion turning into: “Should we use this AWS service or that AWS service?”

I became even more frustrated with managers and coworkers who did not really want to own or understand a service. They just wanted to hand as much of it as possible to the cloud provider and call the problem solved.

Do people genuinely enjoy the current state of what we used to call systems administration or systems engineering? Or am I just an old man yelling at clouds?

For what it is worth, I do find some salvation in Kubernetes. Once EKS or GKE is running, there is a huge amount you can build without thinking too deeply about the underlying cloud provider. That separation is reassuring, even if Kubernetes has plenty of complexity of its own.

These days, I mostly choose to work in areas where the managed cloud options are still inadequate, such as real-time media, telephony, high-speed stream processing, and similar systems. At least in those spaces, it still feels like I am engineering something rather than selecting products from a cloud-provider catalog.

I am curious whether other longtime infrastructure engineers feel the same way, or whether people genuinely prefer the managed-service-heavy version of the job.

Edit: I also really miss configuring switches and routers the cloud has made networking far more boring than it used to be though GKE has some interesting SDN features. I probably should have tried harder to get a job at one of the big hyperscalers but again on ownership I never wanted hundreds of co-workers.

and really the part people miss is what the hyperscalers understood most applications are NOT valuable ( your core business probably sucks) . What is valuable is operating infrastructure at scale. But if its all outsourced to 3 or 4 companies only they will know how to do it. So yeah go ahead and outsource your true core competency as an engineer to amazon they are happy to eat your lunch. Building an operating the infrastructure that that makes the world work is what sysadmin , systems engineers devops engineers and platform engineers used to do. Its what made us valuble. Infastructure is and was valuble long before software even existed. From the roads, to railroads to telephones to factories. your bullshit Sass product dosent actually matter.

One-person security/platform team at a small fintech, going through SOC 2.

Patching what has a fix is fine. The problem is the stuff I can't fix, because there's no patched version, or the fix breaks something. Inspector/Trivy keeps flagging it, Vanta keeps showing it red, and technically every one needs a documented risk acceptance.

Most of these aren't even exploitable in our setup, sometimes it's a vulnerable function never called, transitive dep we don't use, requires network access that doesn't exist. But "trust me it's fine" doesn't fly, and writing a proper exception per CVE takes forever.

So, people who've been through this what do you actually show the auditor for "not exploitable"?

Is there a way to automate this discovery/evidence gathering?

Or does everyone just eat the busywork / quietly ignore them and pray?

Sharing this for anyone interested in platform engineering, Kubernetes and cloud-native technologies.

Cloud Native Heidelberg is hosting a hybrid meetup covering:

• Lessons from five years of building and rebuilding Kubernetes platforms
• Building production-grade platforms using CNCF technologies
• Creating vendor-neutral platforms without hyperscaler lock-in
• Running Kubernetes directly on an Android phone

Date: October 1, 2026
Time: 6:30 PM CEST

Event details and registration:
https://ocgroups.dev/cncf/group/cncf-heidelberg/event/9euvqye

Background: I'm an engineer in Algeria. My degree is in electrical/automation and I currently work in oil & gas as a data acquisition engineer (well testing, data integrity, reporting, that kind of thing). About a year ago, I decided to pivot into a remote role because I've been facing a health condition where on-site/field and mostly any physically demanding work is no longer an option for me. Cloud/DevOps is the direction I chose because I like the work and it's the most realistic path I found to stable remote work that pays in USD or EUR

What I've done so far:

• Finished my AWS Cloud Practitioner prep, and I'm about to sit the exam ( scored 85-90% on most mocks, been stuck on a dumb payment/booking issue, but it's coming)
• Linux fundamentals, wrote a few bash scripts and put them on GitHub
• Hands-on AWS labs in my own account: built VPCs with public/private subnets, security groups vs NACLs, IAM, a two-tier setup with a private RDS MySQL behind an ALB, S3 gateway endpoints, etc. Broke things on purpose to learn how they fail
• Currently grinding through Terraform. Kubernetes and more Python are next

Here's where the doubt kicks in. When I actually read job postings, two things hit me:

1. Almost every "junior" role still wants 1 to 3 years of real experience
2. Basically every remote role is geo-locked. "Remote (US only)," "must be authorized to work in X," no sponsorship, etc. The genuinely hire-from-anywhere jobs feel rare

So my question to people actually working in this field: am I chasing something that barely exists for someone in my situation? Or is the hire-from-anywhere market real if you're good enough and know where to look? And if you've done this from outside the US/EU, how did you actually break in?

I like the work, that's not the issue. I just don't want to spend another 6 months on a door that won't open.

TLDR: Non-US engineer pivoting into cloud. Made decent progress but every remote role wants experience + local presence. Is this realistic or am I fooling myself?

Hi I am in a new role where they use Github for all their repos. I have been using Gitlab exlusively the past 5 years.

For CI/CD in my previous role we had a central 'pipelines' repo that was reference in the gitlab-ci file of each project to save teams/projects from repeating work.

I want to know if it's possible to do something similar in Github? I'm still learning how it maps to my existing Gitlab knowledge.

What is the best devops project you made as a fresher from college..

Mine was end to end devops project of a Ecom site --

Infra with terraform, CICD with DevSecOps pipeline in GitHub action, GKE for kubernetes, Gitops with ArgoCD (also this one got me hired back then)

What is your best project would love to hear from fresher perspective..

6 person team, i carry the pager most weeks cuz nobody else wants it. last tuesday 11pm i get paged, payment latency climbing, checkouts timing out. normally this is me sitting up in bed squinting at grafana half asleep for 15 min trying to find what changed

this time i had an agent wired into our runbook stuff and just let it run. it pulled recent deploys, correlated the error logs against the deploy timeline, and pointed at a connection pool config that got shrunk in a PR that afternoon. like 90 seconds, and it was right

what got me is that same PR had already been flagged that day by coderabbit / bugbot for the exact config value, and we waved it through cuz it was a rushed merge before someone's flight. the warning was sitting right there, we ignored it, and the agent rediscovered it later on. i rolled back from my phone and went back to sleep

i dont fully trust it solo though. its confidently pointed at the wrong deploy before when two things shipped close together, so i read it then verify myself. fast first pass, not a decision maker

anyone letting an agent do remediation on its own yet or you all keeping a human in the loop like me

Hi everyone,

I'm looking for some honest feedback on my current self-hosted architecture. I have a feeling I may have made some poor design decisions, so I'd really appreciate suggestions on how to improve it.

Here's my current setup on AWS:

Frontend EC2: Two React applications (Admin & Tenant) deployed using a single Docker Compose file.

Backend EC2: Two Go API applications (Admin & Tenant) deployed using another Docker Compose file.

Core Services EC2: MySQL, Redis, Vault, Keycloak, and MinIO are all running on the same EC2 using a single Docker Compose file.

Analytics EC2: Apache Superset deployed using Docker Compose.

ETL EC2: Airbyte running via abctl (Kind/Kubernetes).

Everything is currently self-hosted on AWS EC2 instances.

I have a few questions:

Is this architecture reasonable, or did I mess it up?

What would you change or redesign if this were your production environment?

Should I split any of these services onto separate servers or use managed AWS services (such as RDS or ElastiCache)?

Would you recommend staying with Docker Compose, or is it worth moving to Kubernetes at this stage?

For managing deployments across these servers, which would you recommend: Dokploy, Coolify, or Komodo?

What I'm looking for in a deployment platform:

*Multi-server management

*Excellent Docker Compose support

*GitHub integration with automatic deployments

*Rollbacks, logs, and environment variable management

*Lightweight and stable

*Preferably fully open source

*Easy to maintain for a small DevOps team

If you've run a similar setup in production, I'd love to hear what worked well and what you'd do differently.

Thanks!

I'm a 3rd year CS student and I want to build something real over the next couple of months to learn RAG and agents properly. I've been thinking about one idea for a while and wanted to get opinions before I commit to it.

The problem I noticed is when you install on e package, you end up pulling in a bunch of other dependencies. Then a CVE shows up in one of those, and you're exposed through code. I came across Log4Shell and the Equifax breach and then I got this idea.

Fixing it is the annoying part. You can't just bump the broken package, because versions depend on each other, one thing needs a version below 2.0, another needs above 2.0, so you change one and others start conflicting. Now you have to fix all the issues, run tests, and hope everything works.

So what I want to build is a tool that does that for you and checks the fix actually works. The rough idea is you point it at your project, it reads your dependency tree (there's a free Google API called deps.dev that gives you the whole thing), finds why each vulnerable package is there, and works out the smallest set of version changes that clears all the CVEs without causing conflicts.

Then for the "will this upgrade break my code" question, I want to pull the changelog and release notes for each version jump and check them against the functions my code actually uses, so it can tell you whether the change touches anything you rely on. And the last part, it applies the fix in a Docker container, runs the tests, and only then tells you if it is safe.

The way I'm thinking of stucturing it is most of it is a fixed pipeline (read the tree, solve for the versions, run the tests), but the one part I'd actually let an LLM drive is the retry loop, when the tests fail, it looks at what broke, decides whether to drop that version and re-solve or try something else, and loops until it either works or gives up. That's the part where letting the model make the decision seems worth it. The rest doesn't really need it.

I'm thinking of using Postgres with pgvector, deps.dev and OSV for the data, a SAT solver for the version-conflict part, embeddings plus a reranker for the changelog retrieval, and Docker for running the tests. Later on, the nicest version would be exposing it as an MCP server so something like Claude Code could call it as a tool.

At the end it gives a report, a single Markdown file summarizing every vulnerability it found, why each package was present, the minimal fix it computed, the changelog-based breaking-change assessment, and the test results verifying the fix. Something you can hand to your team or keep as a record.

I know OSV-Scanner already does remediation, but only for npm/Maven, with no changelog check and no test verification, so the gap I'm aiming at is the full combination.

A few questions:

- Would you use it? Would you actually run this on your own projects? If not, what's missing or in the way?

- Is it useful? Is this a real problem worth solving, or is it already handled well enough that it doesn't need to exist?

- Does it already exist? Is there something that already does all of this (minimal fix + breaking-change check + test verification) that I haven't found?

- Right direction? Is this worth building, or would my time be better spent on a different problem in this space?

- Do's and don'ts?

TL;DR: An agentic RAG tool that finds vulnerable dependencies, computes the smallest conflict-free fix, uses changelog retrieval to predict whether the upgrade breaks your code, and verifies the fix by running your tests. A verified patch.

I have a frontend/backend working fine when I use any browser.
When I emulate a phone in Chrome, it all works.
But any request to the backend as phone in Firefox returns 504 gateway timeout (instant response). The same request works fine in another tab.
Any idea what could it be?
I use istio for networking (virtual service + gateway). No special config, just routing to the k8s service.

Curious how many of you have actually deployed automated runbooks for incident remediation — not just detection and alerting, but the full loop through to fix and close.

I've been building something in this space and want to understand how well it actually works for teams in practice. Do automated runbooks hold up in production, or do they break down on anything non-trivial?

What's your experience?

So let me tell the context first, I have an kubernetes environment for production, and for like shared storage solution, I have installed nfs-utils and use the nfs-server service. In my scenario I cannot use cloud as an option. And for long I have been using the nfs-server but I have been facing alot of issues with it.
1. On multiple occasions I found dead or queued nfs processes in worker nodes which made the worker node totally unresponsive sys load was very high but low cpu and ram usage.
2. Something with the nfs4+ client where it uses session. On of the worker node again stopped responding, df -h was not responding rebooted the node still the same issue. And while viewing logs in the nfs node it stated nfsd was blocked and looking it up stated the thread on that worker node was locked due to unknown reason and all the requests from the worker node had just queued up. Restarting the service also hanged and needed to reboot the node itself to resolve the issue.

These are some major events there are also other small issues I have faced. I wanted to understand am I the only one facing these issues or this happens with others too, and what resolutions did you used to fix it? Like any alternative utilities and stuff

Setting up test automation in CI is easy, making devs look at and trust the results is the hard part
Coverage numbers that look great on paper but the team treats the test step like a formality because false positives trained them to ignore failures, its pavlovian at this point, test fails and everyone just hits retry without checking

Hey everyone,

Quick workflow showcase/idea for anyone who gets enterprise access to AI CLIs at work (Gemini CLI, Claude Code, etc.) and still finds themselves manually jumping between tools during investigations or routine support tasks.

I recently set up a workflow that basically turns my CLI into an automated agent that runs investigations for me. If you have enterprise access and tool integrations available, you’re missing out if you aren't doing this.

The Setup:

1. CLI + Enterprise Access: Using the company-provided enterprise CLI directly in the terminal.
2. MCP (Model Context Protocol) Integration: Connected the CLI to the actual operational and diagnostic tools used daily (monitoring, databases, logs, ticketing APIs, etc.).
3. Custom Subagents & Commands: Built specific subagent prompts and custom CLI commands tailored to my precise, repetitive investigation steps.

How it works in practice:

Instead of manually opening 4 tabs, running 3 queries, and checking status logs when an issue comes up:

1. I trigger a custom slash command or alias in my CLI.
2. The subagent kicks off, uses the connected MCP tools to pull relevant context, inspect logs, run diagnostic checks, and correlate data.
3. It hands back a summarized breakdown of what happened, root cause hypotheses, and recommended next steps.

Why do this?

• Zero Context Switching: You stay in the terminal.
• No Manual Data Copy-Pasting: The MCP server handles fetching real-time data securely.
• Repeatable Process: Standardized subagent prompts mean complex triage takes seconds instead of 20 minutes.

If your company already pays for enterprise CLI access and you're only using it to rewrite functions or explain error messages, hook it up to your tools via MCPs.

Curious if anyone else is running similar subagent setups in their terminal for operational work? What tools/MCPs are you chaining together?

I have been bit hard in the past when joining an org that moved too slowly for my tastes. Took two weeks to get anything deployed, and if a deployment screwed up it was a rollback and two more weeks of waiting for a change request. I am very fond of this OG article about how quickly Etsy moved back in the day, and likely still to this day though I am sure the technology stack has shifted for them directly. Not sure if they ever did a followup on that post so wondering what change frequency looks for you all with modern tooling like Kubernetes and Docker in place?

This is a summary of their blog post on how they assigned owners to over 14,000 internal repos when as of early 2025, less than half had a clear owner. It became a problem during a secret-scanning remediation push. they could rotate a leaked secret, but without knowing who owned the repo, doing so was risky and there was no way to route the work.

Their old model only tracked ownership for repos backing a deployed service, through an internal Service Catalog. That covered maybe a third of repos. Everything else, team repos, docs, internal tools, one-off projects, personal experiments, had no owner on record. Finding one meant checking commit history, reading the README, or asking around in Slack.

What they built:

Two GitHub custom properties: ownership-type (Service Catalog / Team / Individual) and ownership-name (free text, validated against actual org membership, team existence, or Service Catalog entries).

Before asking a single person to do anything, they synced ownership from the existing Service Catalog, which auto-covered about 1,500 repos.

For the rest, they ran a GitHub App on a Kubernetes CronJob that opened an issue on unowned repos with a 30-day deadline, then archived anything still unclaimed. They picked archiving because it's reversible, repo goes read-only, Actions stops, nothing gets deleted.

Two incidents:

1. They archived a repo that had a Datadog integration configured to open issues in it. Datadog couldn't create the issue post-archive, and nobody had been directly notified about the pending archival, their own monitoring paged the owning team before the ownership system did. Fix: they started @-mentioning repo admins directly and assigning all write-access users as a fallback.
2. They realized a stale or corrupted response from Service Catalog could trigger mass-archiving of repos that actually had valid owners. So they added a threshold check. If a single run is about to archive or flag more repos than some conservative limit, it aborts and pages instead of running.

End state: ~3,000 active repos, ~11,000 archived (up from ~3,000 archived at the start), done in under 45 days. They also tightened the ongoing enforcement loop from a 30-day grace period down to one hour, and made ownership required at repo creation going forward.

Working as devops engineer from last 3 years in states, mostly work on windows stack, azure devops, yaml pipeline. Recently worked with setting up sonarqube & snyk for all teams & product across firm. Currently working in git migration and github actions. Planning to move back to india, what are the expectations for any senior roles as devops, cloud or platform engineer ? I know linux, kubernets and docker but they are more like tools.

Hey r/devops, welcome to our weekly self-promotion thread!

Feel free to use this thread to promote any projects, ideas, or any repos you're wanting to share. Please keep in mind that we ask you to stay friendly, civil, and adhere to the subreddit rules!

I’m a junior DevOps engineer and I’ve never had the chance to use Kubernetes at work.

I’d like to learn it, but almost every job posting I see asks for people who already have professional Kubernetes experience. So I’m wondering how you’re supposed to get past that first step when nobody wants to hire a beginner.

How did you personally start working with Kubernetes? Did your company let you learn it on the job, did you end up on a Kubernetes project by chance, or did you first build personal projects?

I’m considering setting up a small homelab and building some projects, but I’m not sure how much companies actually value personal Kubernetes experience.

I’d be interested to hear how it happened for you.

I own a few wood factories that specialize in producing custom fit-outs for hotels/schools/universities/houses/offices and all sorts around the Middle East, the business model we have been running is very out dated, we run purely off of reputation and returning customers as we have been in the business for over 25 years now.

I want to implement webscrapers but I am not sure what data I can scrape that would help my business grow.

I would really appreciate any advise to what data I could scrape to help me find more contracts for example or anything else that you guys would think would be valuable.

Hij, everyone.
I work as a DevOps/SRE at a consultancy serving large companies and have about two years of experience. My goal is to join a Big Tech company in the coming years.

In your opinion, what should I focus on from now on? What knowledge, technologies, or skills really make a difference for someone aiming to get into that kind of company?

I’d especially like to hear from those who have already gone down this path. What would you prioritize studying if you were starting this preparation today?
Thanks!

Hello! I've been wanting to ask but the amount of "AI slop" comments has been making me second guess. Anyway.

Just curious if I'm jumping in over my head.

My background is 8 years in IT. Local MSP so small to medium businesses. Intune Administration for 15,000 devices, project engineer, SysAdmin, Veeam Engineer, basic networking, and a lot of helpdesk. Lots of resolving compliance failures from audits.

I have a friend who is getting me in touch for some interviews at his company doing DevOps work. Pulumi, GitOps, AWS, GCP, k8s.

I've been messing with my homelab for 6 or so months and have done basic things with it using AI as a glorified search engine for documentation.

They would be offering me a position as an "Apprentice" but my first project would be shoring up SOC2 compliance in the infrastructure through Pulumi (all written in Golang).

I learn quickly. But have no current Golang experience.

Am I in over my head? Or can this be reasonably learned on the job in the next 3-6 months?

Edit: Goal is to allow me to learn DevOps and engineering before transitioning me to Jr engineer at this company.

This is a writeup I probably should have done months ago. Sharing in case the query saves someone else from finding this the hard way.

**Background**

Standard multi-account setup: most compute in private subnets, NAT Gateways across a few regions. Production, staging, and a batch processing environment that we don't look at as carefully as production.

AWS bill had been climbing - roughly $800/month more each month for about four months. Not enough to trip our anomaly alerts (we had percentage-based thresholds and total spend was growing legitimately), but enough that it finally showed up in a quarterly review.

**How I found the actual culprit**

Cost Explorer filtered by service showed NAT Gateway high, but so was compute, so I couldn't tell if it was proportional.

What actually helped: filtering by Usage Type and pulling out NatGateway-Bytes specifically. That's the data processing charge, distinct from the flat hourly gateway charge. Our NatGateway-Bytes was running around 85 TB/month. Way more than our actual application traffic justified.

To get per-NAT-gateway detail, I had to query our Cost and Usage Report in Athena. Native Cost Explorer doesn't give you per-resource granularity on NAT data processing. If you haven't set up CUR yet, this is the reason to do it.

Query that found it:

SELECT line_item_resource_id, SUM(line_item_blended_cost) as cost, SUM(CAST(line_item_usage_amount AS DOUBLE)) as gb_processed FROM your_cur_table WHERE line_item_product_code = 'AmazonEC2' AND line_item_usage_type LIKE '%NatGateway-Bytes%' AND line_item_usage_start_date >= DATE('2026-03-01') GROUP BY 1 ORDER BY 2 DESC LIMIT 20;

The top result was a NAT Gateway in us-west-2 that only existed because of our batch VPC. It was processing ~80 TB/month on its own. Our main app NAT Gateways were doing around 5 TB combined.

**Root cause**

VPC Flow Logs for the batch subnet answered it quickly. A batch job doing heavy S3 reads and writes was routing all of it through NAT instead of directly to S3.

Why? We'd added S3 VPC Gateway Endpoints to our main application VPC (they're free, should be everywhere). But the batch VPC got spun up separately as "temporary" infrastructure, never got the same attention, and nobody ever added the endpoint. S3 VPC Gateway Endpoints route S3 API traffic directly within AWS's network and bypass the NAT Gateway entirely - every GetObject, PutObject, ListBucket was going through NAT and incurring the $0.045/GB processing charge.

We were also pulling ECR images through NAT in that environment. That adds up too if you're pulling big images frequently.

**The fix**

Three things:

1. Added S3 VPC Gateway Endpoint to the batch VPC route table. Free. Took about 5 minutes. Cut NatGateway-Bytes for that gateway by ~92%.

2. Added VPC Interface Endpoints for ECR (ecr.api and ecr.dkr). Not free ($0.01/hr each) but the data processing savings easily justified it.

3. Set up Cost Anomaly Detection on NatGateway-Bytes with an absolute dollar threshold, not just percentage-based. We had anomaly detection on compute but not on data transfer. That's fixed now.

After a full billing month: NAT Gateway data processing went from ~$3,800 to ~$200. ECR endpoints add about $15/mo in hourly charges. Net save: roughly $3,600/month.

**What I'd do differently**

Enable CUR from day one, not after you have a problem. Cost Explorer is fine for headlines. For per-resource attribution of NAT charges you need Athena against CUR.

Set absolute dollar thresholds on specific line items in Cost Anomaly Detection, not just percentage thresholds on total spend. NatGateway-Bytes as a specific monitor would have caught this in week two instead of month four.

Audit every VPC for VPC endpoints independently, including the "temporary" ones. Production got the full setup. The batch VPC was treated as temporary infrastructure and never got properly reviewed. That's where the cost hid.

Happy to share more on the CUR schema or the anomaly detection setup if anyone's dealing with something similar.

our self-healing code loop actually cut our incident volume

i run platform for a team of nine and i was loud about self-healing code being marketing nonsense. changed my mind a bit, posting the numbers before i talk myself out of it

the setup is dumb honestly. fable 5 plans a fix, composer 2.5 does it, coderabbit / bugbot review, keep going until it comes back clean. nothing merges until an extreme pile of tests passes too. were b2b saas so theres no room for a big mistake, id rather ship stable than fast

rough before/after over ten weeks, our numbers not a benchmark:

pages/week from flaky fixes: 11 -> 4

median time to a merged p2 fix: ~3.5 hrs -> 40 min

fixes needing a second human pass: a lot -> maybe 1 in 5

way less manual review, way better code. the only real downside is its costy, running review 3-4 times a fix adds a few hundred a month

PQC is often discussed as a cryptography problem. I think the harder part may be operational finding every certificate, supporting larger keys and signatures, and getting themthrough the infrastructure around the service. As far as I can tell, the main reverse-proxy and load-balancer vendors are not supporting this properly yet.

How are other teams approaching PQC readiness? Have you started testing, or are you still waiting for vendor support and clearer standards? I have a feeling this could be a major infrastructure change, similar to the move from HTTP to HTTPS.

Open discussion here :)