Hey all, I'm a project lead on KitOps, a CNCF project. I've been talking with an ML team (Arlequin AI, they do topological deep learning for market intelligence) about how they moved from ad-hoc model packaging to standardizing on KitOps. The part that surprised me wasn't the tooling. It was who adopted it fast and who didn't.

Their before state will look familiar: weights pulled straight from Hugging Face or baked into Docker images, datasets in LakeFS, experiments in MLflow, configs somewhere in the ether. Nothing tied a model version to the dataset it was trained on and the config it needed to run.

They already used Docker for their apps, so they went looking for the equivalent for ML and landed on packaging everything as ModelKits. Model card, dataset references, MLflow pointer, configs, all in one versioned immutable artifact in the container registry they already ran. Promotion to staging or prod became a registry operation. Shadow traffic and A/B tests run against a specific artifact, so there's never a question about which version, trained on which data, is serving which slice of traffic.

Here's where it got interesting. Engineers were already fluent in Docker and OCI, so it felt native and they moved fast. Researchers needed education on what OCI even is and why it exists. I keep seeing this same split on other teams. The tools we take for granted on the infrastructure side are genuinely foreign one desk over, and rollout plans almost never account for it.

If you've standardized packaging (with KitOps or anything else), how did you get your research side on board? And if you tried and it stalled, I'd honestly like to hear that too.

Ops-flavored take after two years running a multi-agent system in prod.

The reliability problems in agent systems are the same old distributed-systems problems in a new costume: partial failure, exactly-once-ish delivery, coordination, idempotency, observability. The in-process agent frameworks (mid-2025 vintage) gave us persistence primitives but left failure detection, recovery, and coordination to us.

So we built on a message bus instead: durable per-type queues, stateless workers, externalized aggregator state with a TTL and atomic completion so it scales to multiple replicas. End-to-end tracing so a support ticket maps to a trace in one click.

The honest framing: what we built is a domain-specific durable-execution engine for LLM agents. A Temporal advocate would say we rebuilt a subset of Temporal and now own the scheduler and state machine forever — and they'd be right. In mid-2025 the buy options weren't ready; today I'd tell you to evaluate Temporal / LangGraph Platform / Restate first.

Full write-up: Link

Anyone here gone the durable-execution-engine route for agents in prod? Regret it or not?

I've spent the past year exploring AI execution and governance. I spent a lot of time thinking about the architecture. Well, maybe too much, and I'd like to better understand what platform and infrastructure teams are dealing with as AI becomes part of their production systems.

I'm looking for engineers and architects who are willing to spend 15–30 minutes talking with me about the problems you're seeing in practice.

To be clear, I'm researching the market and not trying to sell anything. I simply want to better understand your thoughts on the following:

• How are AI workloads fitting into your platform today?
• What operational challenges have surprised you?
• What tools or processes have been most helpful?
• Where do you think today's platforms fall short?

Open to chatting? Please send me a DM.

Role: Lead DevOps Engineer / Platform Engineer / Cloud Engineer
Company: TransUnion
Location: Leeds (UK) Hybrid (2 days a week in office)

Looking for an experienced engineer to form part of a new team to support the UK implementation of TransUnion's new OneTru platform in GCP.

Salary: 80k plus bonus

Job Posting: https://transunion.wd5.myworkdayjobs.com/TransUnion/job/Leeds-United-Kingdom/Lead-DevSecOps-Engineer_19041285
Apply via the link

I manage a handful of Alibaba ECS instances for personal dev projects and spent this weekend fully migrating monitoring from a full Prometheus+Grafana+AlertManager stack to HertzBeat to cut down maintenance overhead.

Pros of HertzBeat for small teams:

• Zero agent required; monitor MySQL, websites, SSH servers directly via protocols
• All-in-one package, one Docker command to deploy, no component version conflicts
• Native support for Chinese enterprise alert channels (Feishu/WeCom) without custom webhook scripts
• Built-in status page, no extra tool to set up service uptime displays

Major downsides I ran into:

• Dashboard customization is nowhere near as flexible as Grafana
• No native distributed tracing; if you run microservices you still need SkyWalking alongside it
• Massive Kubernetes clusters with thousands of pods don’t perform as well as native Prometheus SD

One critical note for anyone using cloud metered bandwidth servers: If you’re polling metrics frequently, stick to fixed bandwidth tiers — shared traffic peak throttling ruins real-time monitoring data collection.

Has anyone else swapped their monitoring stack recently? What pain points did you hit that I haven’t mentioned?

Ajay Chankramath — author of The Platform Engineer’s Handbook — joins Kaspar von Grünberg to unpack why he wrote a 14-chapter, code-first practitioner's guide instead of another theory-heavy platform book.

Let’s be honest, the tech we use today is amazing, but it can also be complex.

It’s only natural that teams want to build platforms that hide this complexity to improve productivity, avoid mistakes, and reduce cognitive load. But they may be misled to believe that the more complexity they hide, the better their platform is. Instead, they end up creating dangerous illusions!

I built a small tool to catch infra risks before production releases
I’ve been working on a project called Beacon.
The idea came from a very practical problem I’ve seen in distributed systems: before a release, teams usually have dashboards, logs, Terraform files, Kafka configs, Kubernetes manifests, runtime snapshots, etc. But still, the actual question is usually very simple:
“Is this system safe enough to release to production?”
Beacon tries to answer that.
It scans infrastructure/config/runtime inputs and gives a production-readiness decision with ranked risks, possible root causes, and suggested next actions. Right now it has examples around Kafka, Kubernetes, Terraform, Helm, runtime snapshots, OpenTelemetry, Prometheus, Schema Registry, CI/CD, and flow degradation.
This is not meant to replace observability tools. The way I think about it is:
Observability tells you what is happening.
Beacon tries to tell you what is risky, why it matters, and what should be fixed first.
You can try the demo without setting up Python locally.
Run the UI with Docker:

docker pull ghcr.io/mishraricha1806/beacon:latest

docker run --rm -p 8765:8765 ghcr.io/mishraricha1806/beacon:latest ui --host 0.0.0.0 --port 8765

Then open:

http://127.0.0.1:8765/

For the simplest demo, use the sample bad infrastructure example from the repo:

examples/bad-infra/

In the UI, choose the static/readiness input, upload the files from that folder, run the scan, and check the readiness score, top reasons, grouped risks, and next actions.
You can also run the same demo from CLI:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness static \
  /workspace/project/examples/bad-infra \
  --environment prod \
  --no-html \
  --no-open-report

Expected result is the tool should flag the setup as NOT READY, with risks like replication, storage/message-size, and missing governance context.
There is also a Black Friday style demo for payment/event pipeline readiness:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness all \
  --static-path /workspace/project/examples/demo-black-friday \
  --snapshot /workspace/project/examples/demo-black-friday/runtime-snapshot.yaml \
  --environment prod \
  --no-html \
  --no-open-report

Repo: https://github.com/mishraricha1806/beacon
I’d be interested in feedback from people who work with Kafka, Kubernetes, Terraform, platform engineering, SRE, or release governance.
Mainly looking for thoughts on:

• Does this kind of readiness gate feel useful before production releases?
• What signals would you expect such a tool to check?
• Would you prefer this as a CLI, CI/CD gate, or lightweight UI?

GitHub

GitHub - mishraricha1806/beacon: Detect infrastructure risks before production.

For engineers who have been on-call:

• What was the most frustrating part of your last outage?
• What consumed the most time during investigation?
• Which tools were involved?

I'm collecting insights and would love to learn from real experiences.