Issue 56 — Crossplane Wants to Replace Terraform. The Community Has Notes.
Issue 56 — August 2026
Crossplane Wants to Replace Terraform. The Community Has Notes.
🌟 Editor's Note
Every few years, a tool arrives that claims to unify the way we think about infrastructure. It speaks the right language, solves a real problem, and earns a serious following. Then, once enough people try to run it in anger, the receipts start coming in.
This week Crossplane is in the hot seat. The community argument isn't whether it's clever. It is. The Kubernetes API as the common interface between dev and ops is a genuine insight. The argument is whether that insight survives contact with a production environment where someone just needs to change a variable without writing a Go function and holding their breath.
What's underneath the debate is something I keep coming back to: the best platform tool isn't always the most architecturally elegant one. It's the one your team can operate, reason about, and fix at 2am. "No concept of state or a diff, it's all YOLO" is not a theoretical complaint. That's someone describing what happens when something breaks in production and they have no plan output to fall back on.
That pattern shows up everywhere in this week's recon. AI SRE tools that generate fast-but-wrong root cause analyses. GitHub Actions queuing for 20 minutes with no signal. AWS billing caps that reset without warning. The tooling is getting more sophisticated. The failure modes are getting harder to read.
The job market is still grinding. Kubernetes production experience is the filter everyone's stuck behind, and homelabs are the workaround more engineers are taking seriously. That's worth paying attention to if you're on either side of a hiring decision.
Let's get into it.
🚀 Job Market & Career Outlook
The market hasn't opened back up. If anything, the bar has gotten more specific. Kubernetes production experience has gone from "nice to have" to the thing that determines whether your resume gets past the screen. Not cluster exposure. Not lab work. Production. EKS, GKE, AKS, something with real stakes attached.
That creates an obvious problem: you can't get the experience without the role, and you can't get the role without the experience. The most consistent advice in the community right now is to stop waiting and build the record yourself.
- Run kubeadm or k3s or Talos in a homelab. Add Prometheus, Grafana, Longhorn. Then break things deliberately and fix them.
- Build one real end-to-end app, containerize it, wire up ingress, TLS, secrets, monitoring, and backups. Own the whole lifecycle, not just the deploy step.
- Certifications still matter at junior and mid-levels as keyword filters. They don't replace delivery evidence at senior level, but they get you past the bot.
Salaries have softened. The interview gauntlet has gotten longer. Senior SRE and platform roles are increasingly going to candidates who can show enterprise infrastructure delivery alongside recent hands-on technical work. If you've been in management or legacy ops and haven't touched IaC or a modern observability stack lately, that gap is showing.
🤖 AI Agents & Practical Automation
The AI SRE category is having a rough week. Not because the tools are new, but because enough teams have run them long enough to have real feedback. The short version: fast is not the same as right.
"So I'm getting a faster RCA, just a wrong one" is the line that's circulating. It's not a niche complaint. It's the failure mode that surfaces when you optimize for response speed over accuracy, and when the model doesn't have enough context to distinguish a real signal from a correlated symptom.
The more grounded take that kept appearing: agents belong where the branching factor is genuinely unknowable ahead of time. If you can draw the logic as a flowchart, write the script. Deterministic workflows are cheaper, faster, and much easier to audit when something goes sideways.
There's also a drift problem that's worth naming. One team ran a guardrailed AI tool for three months with no issues. By month four, the model had gotten better at being helpful, which meant it had gotten worse at saying no. The instruction hadn't changed. The model had. Behavioral testing at launch is not a substitute for ongoing testing in production. That's a different kind of maintenance than most teams plan for.
💻 Coding Corner
A few practical projects worth knowing about from this week:
- SnowOpsLabs is an open-source Kubernetes platform scenario simulator built for hands-on failure testing. If you're building out a homelab practice environment, this gives you a structured set of failure injection scenarios to work through rather than inventing your own.
- TokenTimer Core is an open-source lifecycle management tool for certificates, credentials, and secrets inventory with alerting. Secrets rotation is still one of the most manual, error-prone parts of most infra stacks. This is a starting point for closing that gap.
- OpsKnight is a self-hosted open-source incident and on-call platform. The interest in self-hosted incident tooling has been building steadily. The reasons are consistent: ownership, auditability, and not paying $30k/year to PagerDuty for something you could run yourself.
On the practices side: the tip that keeps surfacing is to save decision rationale in the code itself, not just in pull requests or documentation. PR descriptions get buried. ADRs get forgotten. A comment that says "we chose this approach because X and not Y because Y breaks on upgrade" is still readable two years later when someone is trying to understand why a choice was made.
🧯 Infrastructure Pain Points
GitHub Actions continues to be a recurring frustration. Queued jobs sitting for 20 minutes, database failures mid-run, no clear signal on when things will recover. The community reaction at this point is past annoyance and into resignation: "Better to report when it works." Large shops are increasingly splitting to self-hosted runners, not for cost reasons, but because the reliability difference is no longer theoretical.
Kubernetes 1.37 is generating real upgrade anxiety. Twenty-five feature gates removed, thirteen locked to fixed values. The practical concern is that a removed gate makes the affected component reject its config at startup and exit, with no graceful fallback. The upgrade advice from practitioners who've done it: test thoroughly in non-prod, document what changed and why, and set region and mode settings explicitly rather than relying on defaults that may shift across versions.
The orphaned AWS resource problem came up repeatedly, with one engineer finding over a thousand dollars a month in resources that had been running untouched for a year. The part worth highlighting: roughly half of those orphaned resources were created by their own automation. Agents that provision infrastructure need to track what they create. If they don't, you're paying for their forgetfulness.
🔦 Tool Spotlight — Crossplane
Crossplane has been gaining real traction in platform engineering circles, and this week the community gave it a thorough going-over. The core pitch is compelling: treat the Kubernetes API as the common interface between dev and ops, let platform teams build internal APIs on top of it, and take the ops team out of the loop for routine infra provisioning. For a mature platform team with Go expertise and a long-term investment in that model, it can work well.
The criticism comes from everyone else. To run Crossplane in production, you need a Kubernetes cluster, which most people are standing up with Terraform. So you're already running the tool it's supposed to replace, just to host it. Adding a new variable requires defining a custom resource, which involves writing YAML that describes a Go type. When you need real logic, you're writing a Go function or provider. The inner loop slows down considerably.
The sharpest critique is around operational safety: there's no plan or diff output. When you need to change something, you apply it and see what happens. One engineer's summary was that it's "all YOLO." That's a real tradeoff when you're managing shared infrastructure and need to communicate what a change will do before it does it.
Terraform isn't without its own frustrations. But the three-way diff, the declarative state model, and the broad multi-cloud provider coverage give it an operational baseline that most teams can work with. Crossplane makes a different architectural bet, and that bet pays off in specific contexts. If you're building an internal developer platform where ops wants to disappear from the provisioning loop entirely, it's worth evaluating seriously. If you're a smaller team that needs to move fast and can't staff Go expertise, the overhead probably isn't worth it yet.
📈 Emerging Trends & Updates Generating Buzz
- Kubernetes 1.37 is generating more pre-upgrade conversation than most releases. The combination of removed feature gates, rootless mode, DRA changes, and static pod behavior shifts means this is not a routine bump. If you're on a managed cluster, check what your provider is doing before you're surprised by a deprecation.
- DuckDB joining AWS landed with mixed reactions. The optimistic read is managed service integrations and broader adoption. The skeptical read is that the pace of OSS innovation slows when a hyperscaler gets involved. Both are probably partially right.
- AWS Aurora DSQL foreign keys got more attention than you'd expect for a database feature. For teams that needed foreign key support to move workloads to DSQL, this closes a real gap, though there are already questions about performance under write-heavy loads.
- AWS Cognito TOTP API reset is getting called out as something that should have shipped in 2018. It's here now. If you've been managing TOTP workarounds for compliance reasons, this is worth revisiting.
- OIDC and workload identity federation continue to come up as the practical path to eliminating most static secrets. The advice is consistent: federate what you can, then build strict rotation and inventory around whatever API keys you can't eliminate.
💬 Quote of the Week
"If you can draw it as a flowchart, stick to a deterministic workflow. Agents only belong when the branching factor is unknowable ahead of time."
— Platform engineer, r/devops
This is the clearest framing I've seen for the agent-versus-script question. Not "agents are overhyped" and not "agents everywhere." Just a practical rule for where the complexity is actually justified. The branching factor test is something you can apply before you build, not after you've already shipped something that's harder to debug than the script it replaced.
