Skip to content
Notifications
Clear all

Unpopular opinion: The whole agent runtime category is solving a problem we created.

2 Posts
2 Users
0 Reactions
2 Views
(@amelia2)
Estimable Member
Joined: 1 week ago
Posts: 67
Topic starter   [#12649]

We're adding layers to solve problems that shouldn't exist. We had monoliths, then broke them into microservices. That created sprawl. Instead of fixing the sprawl, we invented agent runtimes (e.g., for feature flags, config, secrets) to manage the chaos. Now we have a distributed monolith of agents.

What actually happens:
* You deploy a service. It needs 3 different agent sidecars plus a daemonset.
* Each has its own networking, auth, and update cycle.
* Debugging means tracing calls through your app *and* through multiple agent layers.
* Vendor claims: "Seamless integration, zero overhead."
* Reality: You've traded complexity in your app for complexity in your ops layer, but now it's a black box.

Example: A simple secret fetch.
Without agent:
```yaml
# app code directly calls vault API with retry logic.
```
With agent:
```yaml
# app calls local agent via sidecar
# agent has its own config, ACL, cache, and potential failure modes.
# You now monitor two services.
```

The problem was service sprawl and poor internal APIs. The solution shouldn't be another runtime. It's fixing the service boundaries and building robust internal libraries. Would I renew? No. I'm ripping them out.

— a2


Ship it, but test it first


   
Quote
(@grafana_knight_shift_2)
Estimable Member
Joined: 2 months ago
Posts: 110
 

You're right about the debugging pain. I've spent too many night shifts watching engineers trace a request through their app, only to get stuck because the config agent sidecar had a stale cache that wasn't emitting any metrics.

The vendor promise of "zero overhead" always misses the operational tax. You now have to:

- Patch the agent runtime CVEs independently.
- Set up separate dashboards for agent health, which they rarely provide out of the box.
- Untangle auth chains where the app authenticates to the agent, and the agent to the upstream service.

That said, I've seen teams succeed by treating the agent as a temporary crutch. They use it to quickly adopt a secret manager, but simultaneously build and phase in a thin, auditable internal library. The key is having a deletion date for the agent from day one. Without that, it becomes permanent infrastructure.


Sleep is for the weak


   
ReplyQuote