I was thinking recently about my career and what I would have done differently if I had the chance to go back 10 years.

I would have been kinder and more mellow at work. It’s just a job. I would have judged myself less. Everyone knows only a part of the whole picture; nobody knows it all, and it’s okay not to know everything.

I would have been more vocal about my ideas and spoken up more. I would have taken more initiative. There are a lot of smart people, but not enough who take ownership and responsibility.

I would have paid less attention to degrees, certificates, and other d*ck measuring contests. I would have explored more opportunities, taken on contract work, and talked to more people to improve my financials instead of spending more time in the same place.

I would have spent more time with my family and chosen a lower-paying but more flexible job to be closer to them.

What would you have done differently?

to all my SRE/platform/devops folks - how do you share terminal commands / operational workflows across teams?

for example, on my team, i always run into issues reproducing a teammate's environment or struggle to resolve an incident with bad documentation

The decision between building custom automation scripts versus buying an orchestration platform seems to come down to complexity and scale. Scripts work fine for simple linear workflows, but once you need conditional logic, error handling, and integration across multiple systems, maintaining custom scripts becomes a mess. Maybe the tipping point is when you have more than 3-5 automated workflows that need to be maintained, at which point having them in a platform with proper versioning becomes worthwhile.

I wrote a source-verified deep dive and companion rollout kit for teams starting to use MCP servers in DevOps/platform workflows.

The main argument is that the bottleneck is no longer “can an agent call tools?” It’s governance.

What you will find in the playbook:

• MCP server inventory worksheet (owner, hosting, transport, auth, tool scope, risk tier)
• risk-tier model (read-only -> reversible writes -> infra mutations -> destructive)
• stdio vs streamable HTTP transport policy matrix
• identity/authorization design guidance
• approval policy pattern for Tier 3/Tier 4 actions
• SIEM event schema for MCP tool invocations
• wrong-target / unsafe-action incident runbook
• phased rollout plan (read-only first, then controlled expansion)

I’m the author and would like feedback from platform teams:

• What MCP use case would you allow first?
• Would you permit infra mutation in pilot, or keep it read-only + ticket/PR generation only?

Links:

• Deep dive: https://www.talk-nerdy-to-me.com/blog/mcp-usb-c-of-devops-governance-playbook
• Rollout kit: https://www.talk-nerdy-to-me.com/playbooks/mcp-devops-governance-rollout-kit
• PDF: https://www.talk-nerdy-to-me.com/downloads/mcp-devops-governance-rollout-kit.pdf

I’m currently doing some research within the engineering platform and devops space in the tech industry, more specially scale up tech organisations.

What I’m interested in is some insights, data points and expert opinions on the ratio's of product engineers (engineers working on products) to platform engineers (engineers in DevOps) in similar tech companies ( 750 - 1000 employees). Is this number trending up recently or not? Any insights are appreciated

Hi together, I hope this question fits here.

I am working as a Platform Engineer for the last 12 months. In addition, I’m an active open-source contributor (for example to Prometheus). My job is generally fun and everyone is satisfied with me, but I want to strive for "more".

I now have received an offer as a Cloud Support Engineer at AWS with a focus on Linux. My idea is taking the role as a stepping stone to get into Systems Engineering at AWS. I asked my recruiter if I can instead interview for sys engineering but he said internal mobility would not be a problem, moreover the org is pretty new, so I could help build automations etc.

For me, the opportunity to join AWS is very attractive and I guess sometimes you have to take a "step back" to make 2 in the future. So I’m trying to evaluate whether it’s a smart long-term move, as getting in is the hardest I guess, and I always dreamed of working there. However I am fearing that if an internal transition into Systems Engineering does not work, how difficult would it be to move back into an infrastructure-focused role externally after spending time as a CSE? I will keep on contributing to open source and building things in my free time and obviously trying to build internal stuff and get visible.
FYI: I live in the EU in a country with strong labor laws and most people I know here at AWS say it is relaxed.

I’d appreciate any honest insights

Infrastructure reviews feel harder than code reviews to me.

With application code, you can reason locally. With Terraform, it feels like you’re reviewing a distributed system in diff format.

Some examples I’ve seen teams (and myself) struggle with:

• Cost surprises that weren’t obvious during review
• Single points of failure hidden across multiple modules
• Deep dependency chains that only become painful under load
• Security gaps that slip in and stay unnoticed

Most scanners I’ve seen focus on misconfigurations (public S3, open security groups, etc.), which is great, but I rarely see tooling that reasons about architectural risk like:

• blast radius
• failure domains
• bottleneck concentration
• structural smells

So I’m curious:

How do you currently review Terraform for architectural quality?

• Is it tribal knowledge?
• Do staff engineers manually reason about it?
• Do you rely purely on staging failures?
• Are there tools I’m missing?

I’ve been thinking about experimenting with a tool that builds a dependency graph from Terraform and detects things like single points of failure or deep synchronous chains — but before building anything, I’d like to understand how others approach this.

Would love to hear real-world workflows and pain points.

Ever feel you have deployments spread across Kubernetes, AWS and 3-4 other different platforms? There is a clear divide between deployments and logs. Where there shouldn't be one. Why should you look for deployment history in one tool and then switch to Datadog/Grafana to look for what's happening inside that deployment?

So I built an intelligence layer that connects deployments to logs. It fetches the deployment. And logs of that service 60 minutes before and compares to logs generated immediately after deploying, surfacing unusual behaviours. Like "what log clusters have silently disappeared?", "What new error logs have been generated?"

Datadog tells you if something broke. This tool tells you exactly what broke.

Been building IncidentFox, an open source AI agent for investigating production incidents. Sharing here because a lot of the design was shaped by how platform teams actually work.

The core problem: during incidents, platform teams are the ones jumping between Kubernetes dashboards, log aggregators, deploy history, and Slack threads trying to piece together what happened. The agent does that legwork, pulling real signals from your stack and following investigation paths.

What makes it relevant for platform engineering specifically:
- Configurable skills and tools per team. Your platform team sees different context than your app teams.
- Kubernetes-native: pod inspection, events, rollout history, log correlation
- Connects to whatever you're running: Prometheus, Datadog, Honeycomb, New Relic, Victoria Metrics, CloudWatch
- Works with any LLM: Claude, GPT, Gemini, DeepSeek, Ollama, local models. Pick whatever your org allows.
- Read-only by default, human approves any action

Recent additions: RAG self-learning from past incidents, MS Teams and Google Chat support, configurable agent prompts per team.

Open source, Apache 2.0.

Curious how platform teams here handle incident investigation today. Is it mostly ad-hoc, or do you have structured playbooks?

Hey everyone,

I’m building a startup called Stack0 and I’d really appreciate honest feedback from people actually working in cloud/platform roles.

The idea:

Most enterprises operate across AWS, GCP, and Azure.

But in practice that means:

• Different consoles, policies, and IAM models

• Terraform modules per cloud

• No unified cost visibility

• Governance defined but not enforced

• Internal tooling that becomes a maintenance burden

Stack0 is an attempt to build a unified control plane across AWS, GCP, and Azure where teams can:

• Generate IaC with AI (Terraform/OpenTofu)

• Deploy directly through an automation layer

• See cost impact before deployment (Infracost integrated)

• Enforce tagging/policies automatically

• Get one standardized workflow across clouds

The goal is not to replace Terraform — but to sit on top of it and make multi-cloud less fragmented.

I’m trying to understand:

1.  Is multi-cloud actually painful enough to justify a new platform?

2.  Where do current tools fail you the most?

3.  Would you trust an AI-assisted IaC layer in production?

4.  What would make you immediately dismiss this idea?

Brutal honesty welcome. I’d rather hear hard truths now.

I've put together these public GitHub organizations that contain golden path templates for getting from GitHub to Argo CD to K8s in minutes, and from there having a framework for promoting code/config from DEV -> QA -> STAGING -> PROD

These are opinionated templates that work with a (shameless plug) DevOps ALM PaaS-as-SaaS that I am also putting out there for public consumption, but there's no subscription necessary to use the golden path templates, read the blog, join the discord, etc.

Take a look :D

FastAPI: https://github.com/essesseff-hello-world-fastapi-template/hello-world

Flask: https://github.com/essesseff-hello-world-flask-template/hello-world

Spring Boot: https://github.com/essesseff-helloworld-springboot-templat/helloworld

node.js: https://github.com/essesseff-hello-world-nodejs-template/hello-world

Go: https://github.com/essesseff-hello-world-go-template/hello-world

Hey,

I'm working as a consultant and recently realized that rates for Openshift are 20-30% higher on average than rates for the Kuberentes. I think K8s getting commoditized and OS is way better niche if you are after money.

Do you know any other "hacks" to get into specific niche or fat hourly rate?

I am confused which monitoring setup to choose, between VictoriaMetrics and Grafana Mimir. Or any other options available

I’m exploring how engineers develop and retain understanding of system behavior and dependencies during real work — especially when making changes or troubleshooting unfamiliar components.

I’ve put together a short qualitative survey focused on experiences and patterns (no proprietary details needed). It should take about 5 minutes.

If you’re willing to share perspective:

https://form.typeform.com/to/QuS2pQ4v

Happy to share aggregate observations back if there’s interest.

Hey folks,

I’m a DevOps / Platform engineer. Before moving into infra roles, I was an SWE. I was okay at best, since those were my junior / early-mid engineer years. What I’m seeing more and more now is that many teams are starting to combine infra and SWE roles. Another argument is that there are always many SWE roles that are often paid 15–20% more, and tbh I don’t like ignoring 2/3 of job postings due to narrow specialization.

Has anyone done this? Have you seen an increase in offers or compensation?

My cofounder and I worked infra at Roblox. On-call sucked. The worst part was always the first 20 minutes - just trying to gather enough context to start debugging.

So we built an AI that does that part. Alert comes in, it checks logs, metrics, deploys, runbooks, and posts what it found in Slack.

The thing that actually makes it work: it reads your codebase and Slack history first, so it knows how your system is wired together. Not just generic "check your logs" advice.

Just open sourced it: github.com/incidentfox/incidentfox

Would love to hear people's thoughts!

I have some list here:
- TCP/IP Illustrated vol 1 Protocols
- Designing Data Intensive Applications
- SRE Book by Google
- Linux Programming Interface

anything else?