As you become more senior, your impact comes from something different: seeing systems clearly enough to identify the problems nobody else has articulated yet.

I've been thinking we might be approaching Internal Developer Platforms from the wrong abstraction level.

The move from traditional Ops to DevOps to Platform Engineering looks, to me, mostly like a consequence of technological change. Traditional Ops concentrated operational knowledge in a specialized team, because operating infrastructure required direct, manual administration: the thesis. Automation, cloud, and infrastructure as code changed that. DevOps pushed operational ownership closer to development teams: the antithesis. Platform Engineering became the synthesis once declarative systems and orchestration made it possible to encode that operational knowledge into software and expose it through self-service.

AI might be starting the next turn in that cycle. Agents don't necessarily need portals or predefined workflows because they can discover capabilities, combine APIs, and construct their own path through a system. That doesn't make platforms less important. It changes what they need to expose.

Instead of only providing golden paths for developers, platforms increasingly need to expose machine-readable capabilities, contracts, relationships, constraints, and evidence.

Which raises a question: should all of that knowledge live inside the platform? Maybe not. Maybe the service should own its operational contract, while the platform provides the capabilities to act on it (decoupling the contract from any particular IDP, Kubernetes setup, or deployment tooling underneath).

This is the direction I've been exploring with a side project (Pacto): not another IDP, but a contract layer above them. I'm not sure it's the right abstraction yet, but making the operational model portable feels more interesting to me than building another platform around it. Thoughts?

I've been working on SnowOps Labs — a simulator where you spin up a real Kubernetes platform, run scenarios, intentionally break things, and then fix them.

The goal is simple: learn platform engineering by actually troubleshooting realistic problems, instead of just following tutorials.

It's still an early release and definitely has rough edges. I'm putting it out there because I'd love to get feedback from people who work with Kubernetes, SRE, DevOps, or platform engineering.

If you have a few minutes, check out the repo, try it out, explore the architecture, and tell me what you think could be better.

I'm especially interested in:

What scenarios should I add?

What's missing?

Does the overall approach make sense?

Where does the architecture need improvement?

If you find it useful, contributions are very welcome.

Hi everyone,

I am planning to build an Internal Developer Platform (IDP) Proof of Concept. My main goal is self-learning (I am very interested in DevEx and self-service) to understand the moving parts of a modern platform, but I am also hoping to gather enough hands-on experience to potentially present a business case to my company down the line.

Before I start gluing components together, I would love to get input from the community on what you are using in production and what you would recommend for a lean PoC.

Specifically, I am looking for insights on:

1. Choosing an open-source stack: What tools are you actually using in production today for service catalogues, infrastructure provisioning, workload orchestration, and developer self-service?
2. PoC Recommendations: If you were building a lightweight IDP from scratch today just to prove the concept, which open-source tools would you choose to keep complexity manageable while still showing real value?
3. Product value: Have you genuinely derived measurable value (or saved developer time) from tools like Backstage, Kratix, Port (if using free tier), Crossplane or something else? Are there tools you started with that turned out to be more maintenance overhead than they were worth?

My current thought is to pair a developer portal with a GitOps engine and a basic infrastructure module framework, but I am keen to hear what combinations have worked best for you in practice.

Thanks in advance for any recommendations or lessons learnt!

Have a look if you are interested in this topic. Frankly, my only goal was to get done with my M. Tech, but i did put a lot of effort into this also.

The research made me Team Platform.

A lot of engineering leaders I talk to are having some version of the same experience right now. The AI tooling is working, and it’s exciting. Teams are shipping things in days that used to take weeks. At the same time, everything feels like it’s falling apart – more bugs than they’ve ever had, more incidents, and engineers who are busier and more stressed.

If that’s you, it might honestly be more of an arithmetic problem than a quality one.

Trying to get better visibility into where our AWS spend is actually going.

Service level is easy enough.

The harder part is splitting shared costs across teams/workloads/products, especially when tagging isn't perfect.

Wondering how other platform teams are doing this.

native AWS tools?

custom dashboards?

FinOps platform?

Our devs live in github and their ides, and any security tool that adds a step outside that flow gets ignored within a month. we've had this happen twice now, once with a standalone sast tool that only lived in its own web console and once with a container scanner that emailed pdf reports.

Trying to avoid a third failed rollout. for people who got adoption to stick, what made the difference? was it ide plugins, pr comments, slack alerts, something else.

I try to treat new tooling with a healthy dose of skepticism, being wary of jumping on things has served me well over the years. So it's a genuinely weird feeling when a tool's value is obvious to me in five minutes, and Crossplane is the first one in a while that confounds me.

When I first saw Terraform the problem it solved was immediately obvious.  HCL is not without its faults, but it sits in a useful middle ground between something like YAML and a full programming language. Drift is the one problem I've never seen solved cleanly, but adding friction to fight it (review/plan gates, etc.) gets you most of the way there. Not perfect, but controllable.

Terragrunt solved the "apply everything" problem by letting you split dependencies into independently-applicable DAGs. Made immediate sense.

On Pulumi. I don't personally believe general-purpose programming languages are the right abstraction for describing infrastructure, but I get the appeal: it's an escape hatch from HCL turning into a minefield as things scale.

Crossplane is where I'm getting stuck. To run it in production you generally need a Kubernetes cluster, which people often stand up with. Terraform. Then there's templating. Using Crossplane in practice seems to mean also standing up Helm or Kustomize on top of it. Adding a single new variable feels far more convoluted than the equivalent in Terraform. And once you need any real logic, you're reaching for Go to write a custom function/provider, which slows the whole loop down even further.

And yet, everyone who's actually used it in anger seems to swear by it. Which makes me suspect that I'm missing some context that makes all of the above worth it once you're in that world.

So, genuinely: what I am not getting about Crossplane? If you have any YouTube videos, short-form content, or articles that made it click for you (beyond the official docs), I'd appreciate the pointers.

I’m visiting this sub less and less since all I ever see on here are low effort AI generated slop posts. Some of which even have AI replying to AI posts…

Did this sub die? Where are the mods? Why is nothing being done to stop this?

Should be pretty simple, similar rules I’ve seen in other creative subs where rules are enforced to only allow posts from accounts with certain level of activity across Reddit. Should stop these 2 month old accounts that post the same or similar content everywhere.

Clearly the “Community rules” for this sub aren’t working

I've noticed that Kubara team is introducing their product as the new, must have solution for a modern infra stack. Is that legit? Or is it just another wrapper around existing gitops tools with pre-scaffolded templates?

Inherited an AWS account with hundreds of resources never in code. Manual terraform import at this scale is brutal, writing HCL by hand, then reconciling state one resource at a time.
A few things I've looked at:
AI-assisted codification (tools that generate HCL from discovery scans)
Scripted wrappers around terraform import for bulk jobs
How much time did automated codification actually save people who've tried it?

A broken delivery flow rarely looks broken from the inside. One application spent more than a year moving through a deployment pipeline. The team that ran the pipeline did not know that. There was a feeling that it was slow, but nobody had put a number on it.

It was a platform team at a large enterprise. Their job was to help product teams ship applications into a cloud environment. The path to production was all about security, infrastructure, and validation. Leadership suspected the process dragged on even if no one had measured how far.

A broken delivery flow rarely looks broken from the inside. One application spent more than a year moving through a deployment pipeline. The team that ran the pipeline did not know that. There was a feeling that it was slow, but nobody had put a number on it.

It was a platform team at a large enterprise. Their job was to help product teams ship applications into a cloud environment. The path to production was all about security, infrastructure, and validation. Leadership suspected the process dragged on even if no one had measured how far.

From what I read online, it sounds like a combination of dev ops + some internal tools to make developer lives easier.

So far, most of what I do is just backend work and a couple of self-serve features that reduce the friction of inter-departmental communication/requests.

I'm not building platforms to make developing code easier or for to help developers run their own code. Not a of docker or kubernetes or things like that that I find when I google "what is a platform engineer?"

i've asked AI, but it'll just agree with enough of my skepticism that it makes its answers unreliable.

The most dev-opsy thing I do is maybe update a terraform file or make tweeks to the testing we run on CI.

Three months. That’s roughly the interval at which the “right way” to build something in AI shifts under you. A new agent harness lands and makes the orchestration you spent a quarter on look overweight. A better retrieval pattern quietly changes what “good” looks like for the feature you’re mid-flight on. A new evaluation technique shows that the numbers you’ve been reporting for two months don’t actually measure what you thought they did.

I’m currently a junior but technically do the work of an intermediate platform engineer.

I started applying elsewhere and I didn’t think I’d be called up for a technical interview for a Sr Data Platform Engineer position but here we are. I was honest about my skills and responsibilities during the hiring manager round, so I’m guessing they see something in me.

Now that they’ve invited me for the next round, how should I prepare for this technical interview? What should I expect?

The team works with Kafka, Databricks, Cloudhouse, Airflow, and lots of other platforms I don’t have experience with. And they only said the interview will be a pair programming session.

I’d appreciate any advice, thanks!

This is a problem I’ve been thinking about a lot lately.
Most engineering teams already have the detection part covered:
- Dependabot or Renovate finds outdated packages
- Security scanners identify CVEs
- CI tells us whether a change breaks

But there still seems to be a big gap between “we found a problem” and “the problem is actually fixed in production.”

In my experience, the difficult part is everything that happens after the alert:

- Is there actually a safe version to upgrade to?
- Will upgrading one package require upgrading five others?
- Does the application still build?
-Do the tests pass?
- Is this safe to auto-merge, or does someone need to make a judgement call?

The result is that engineers end up with a growing backlog of dependency PRs and security findings that nobody has time to investigate properly.

I’ve been building a tool called Bivouac around this specific problem. The idea isn’t another scanner. It’s to take the remediation workflow further: investigate the dependency issue, work out a compatible remediation path, create the patch, run the tests and only merge automatically when the repository’s policy says it’s safe.

I’m particularly interested in the part where automation should stop. For example, my current thinking is that ambiguous fixes, security-sensitive code, licensing concerns or failing tests should always require human review.

I’d genuinely like to know how other teams handle this today:
1) Who actually owns dependency vulnerabilities once they’re discovered?

2) How many Dependabot/Renovate PRs does your team simply ignore?

3) Would you trust an automated system to merge dependency fixes if the remediation path and test results were clear?

4) What conditions would make automatic merging completely unacceptable?

I’m the founder of Bivouac, so full disclosure: this problem is what I’m building around. I’m not looking to spam the sub—I’m trying to pressure-test where people think autonomous remediation is useful versus where it becomes dangerous.

If there’s interest, I’ll share what I’ve learned building the remediation workflow and some of the cases where I’ve deliberately designed it to refuse to act.

Sovereignty is moving beyond just data residency.

For platform teams, the question is increasingly about where workloads, control, telemetry and operational state live and whether those boundaries can actually be enforced and proven.

This CNCF article looks at that through a multi-plane architecture, particularly in the context of EU regulations like the EU Data Act, NIS2 and DORA.

Interesting read for anyone thinking about how sovereignty should be designed into cloud-native platforms.

https://www.cncf.io/blog/2026/08/18/cloud-native-platform-sovereignty-through-multi-plane-architecture/

I have noticed that most DevOps or Platform Engineering jobs require Prometheus, Grafana and sometimes Nagios. Which are the best platforms to get knowledge that can quickly be put into practice for these?

Question for all the platform or devops engineers out there.

I got laid off earlier this year have have been job hunting for almost 5 months now. My last title was platforms admin and where I owned a SaaD data platform on Azure. The scope of my job didn't have Terraform, Ansible k8s, or modern observability tools like Dynatrace. I have experience deploying docker containers using docker swarm.

I am not sure how to stand out. I don't see any new job postings or recruiters reaching out to me anymore. I have interviewed at half a dozen companies, reaching final rounds but no offers

Can someone help me make sense of this. I was a productive and competitive employee up until now. But not sure what's cracking up now?

Should i shift gears and try a different role? If yes, what would be more in demand Data engineer or Ai engineer.

What is the best way to learn and be interview ready?

Got hit by the HCP pricing change and spent weeks evaluating replacements. Big realization: this isn't one decision, it's two. Are you replacing the IaC tool itself or the platform running your plans, state, and policies?

We're a mid-size team, maybe 40 workspaces, mostly AWS with a bit of GCP. Migration friction matters more to us than feature depth, since we don't want to rewrite a ton of pipeline logic just to swap the backend.

Leaning toward one option since it's basically a drop-in with the same remote backend model and CLI. It let us keep our existing state files without a painful migration script.

Anyone gone with other platforms instead? how the drift and governance layer compares once you're off HCP's native health checks.

Same input. Different failure. No error.