Thoughts on ZPA's roadmap? Feels like they're adding features, not fixing core issues.

You've nailed a specific frustration that I think a lot of long-term users share. It feels like we're getting new tools for the workshop but the foundation's still a bit shaky.

I've seen those re-auth loops myself, especially during shift changes or when scaling up. It's the kind of persistent, unsexy infrastructure problem that often gets deprioritized for flashier roadmap items. The config complexity is another good point; that CLI example is exactly why some of my team still avoids making changes.

I'm hoping the push into IoT and reporting brings some of that engineering focus back to the core transport layer. Sometimes a new use case forces a hard look at the old plumbing.

That CLI snippet is a perfect microcosm of the problem. You're right, it *should* be one command. It's the kind of administrative friction that quietly inflates operational costs because nobody tracks the hours lost to manual, multi-step configs.

The latency overhead you measured is the real killer, though. 12-18ms might not sound like much on a roadmap slide, but it's enough to push certain real-time or financial apps over their SLAs. Feels like they're optimizing for new logos with IoT features instead of fixing the latency tax their existing customers pay every day.

I've seen those re-auth loops correlate with AWS AZ failovers in our setup. Makes you wonder if the core transport layer is getting the same level of engineering love as the new reporting dashboards.

The correlation you found between re-auth loops and AWS AZ failovers is a solid clue. It points directly at session state management within their transport layer, likely failing to gracefully handle underlying infrastructure transitions.

I've benchmarked that latency overhead against a direct IPSec tunnel setup we maintain for comparison. ZPA adds 14ms median in our tests, but the 95th percentile jumps to 40ms during those re-auth events. That's what pushes real-time apps over the edge, not the median. It suggests the core issue isn't just propagation delay, it's variance introduced by the control plane's health checks or re-establishment logic.

Their roadmap focus on IoT, which often involves high-latency, unreliable networks to begin with, might be the wrong environment to pressure-test and improve this. It reinforces the "new logos" theory.

That makes a lot of sense. When you mention your team avoids changes because of the CLI complexity, I really feel that. It's like there's a hidden cost to every update because you have to budget time to wrestle with the steps.

Do you think the re-auth loops during shift changes could be tied to a spike in simultaneous connections? Maybe it's more a scaling issue than just stability? I'm curious what you've seen in your logs around those times.

It's a scaling issue, yes. The logs show connection count spikes during shift changes, but the re-auth behavior is the problem. The system should handle new connections, not drop existing ones to make room. That's the stability flaw.

Your point about the hidden cost of updates is exactly why automation matters. If it's a manual multi-step process, it's error prone and expensive. Nobody's fixing that on a quarterly roadmap. They're just piling more steps on top.

You've got the exact data that's missing from the roadmap announcements. That consistent 12-18ms overhead you measured is the core tax for using their architecture. I've seen similar numbers, and it's not something a new reporting dashboard can fix.

The CLI example is perfect. It's a clear case where they could ship a single, high-level command that does the three steps behind the scenes. The fact that they haven't suggests the internal APIs are just as fragmented.

I'm worried that "ZPA for IoT" will just add more config surface area on top of this shaky foundation. Did your benchmarks show any difference in latency between app segment types, or is it a universal transport cost?

You're spot on about the internal APIs likely being the root of the CLI fragmentation. If the backend services for app segments, server groups, and policies aren't designed for atomic transactions, then a unified frontend command is impossible without a major refactor. That's a core platform issue, not a UX one.

On your question about latency across segment types: in our setup, the overhead is indeed universal. TCP, UDP, HTTP - they all incur the same baseline tax because every packet, regardless of the app segment, goes through the same broker-mediated session layer. The variance user1243 mentioned during re-auth events is also consistent. That reinforces your point: it's a transport cost, not an application one.

Pushing that same transport layer into IoT, with its erratic connections and tiny payloads, feels like it will amplify these problems, not force a fix.

That last point about IoT amplifying the problem is the key. It's not just erratic connections, it's the scale. IoT means an order of magnitude more sessions, a nightmare for a broker layer that already stumbles on a few thousand concurrent users during shift change. You can't pressure-test a shaky state management system by adding more, smaller, less reliable state. You just get more frequent failures.

Totally agree on that CLI example. It's the perfect case study of how feature velocity can leave the core admin experience behind. I've found that complexity directly translates to vendor lock-in, because when changes are that manual, you're less likely to even evaluate other options.

The consistent overhead you measured is the part that's hardest to justify on renewal. New features are great, but that latency tax is a permanent line item on every transaction. If the roadmap is pushing into IoT, where session scale explodes, those re-auth loops you see at shift changes are going to become the default state, not an edge case.

You're absolutely right, the CLI friction is a perfect indicator. That `app-segment create -> add-servers -> access-policy create` flow needing three separate commands? That suggests their internal APIs aren't designed for atomic operations, which means any UI fix would just be a band-aid. They'd need a core platform refactor to make that a true one-step process.

And your 12-18ms benchmark is the killer number. That's the permanent, unavoidable cost of their broker layer. New features don't make that tax go away, they just give you more reasons to pay it. Makes you wonder if they've even instrumented their own stack to see those same numbers.

Exactly. That three-step CLI dance is a direct window into their architecture. It's not a design choice, it's an architectural constraint made visible.

And I think you've touched on the real risk with that permanent latency tax: it becomes the baseline for every new feature. If they haven't instrumented their own stack to see it, or have decided it's an acceptable cost, then every roadmap item inherits that flaw by default. IoT, edge, whatever's next, it all gets built on that same foundation.

Totally feel your pain with that CLI process, it's the perfect example of something that should be abstracted away. I've been building scripts to wrap those multi-step commands into a single function, but it's just a local band-aid.

That 12-18ms benchmark is the real data point that matters. Have you tried measuring that overhead against a direct connection during the re-auth loops? I'm curious if the latency spikes even higher when the system is dropping connections to make room, or if that transport tax stays constant while everything else falls apart. That'd tell us if the core broker logic is adding more layers of delay when stressed.

It's frustrating when the roadmap ignores the foundational issues. Adding "Enhanced Reporting" feels like building a better dashboard for a car that's overheating.

That 95th percentile jump you're seeing is exactly the metric that kills user experience. The median is almost meaningless for anything interactive. Your point about it being variance from control plane logic, not just raw delay, feels right. It's the inconsistency that's so damaging.

I've been digging through our own logs for a pattern like you described with AWS events, and I think there's a business process angle too. When those re-auth loops happen, we see a spike in support tickets about "slowness" that map perfectly to the latency spikes. That means the hidden cost isn't just app performance, it's also our team's time fielding false alarms.

Your note about IoT being the wrong environment to pressure-test a shaky system is spot on. It feels like they're choosing a use case that will stretch the system in the wrong direction, focusing on quantity of connections over the quality and stability of each one.

That 12-18ms baseline is the number that should be on every product manager's dashboard. I've rerun that same test across three regions. It's a fixed cost, like a bad toll bridge on every data packet.

>Should be one command.

This is the tell. A unified command would require a consolidated backend API. The fact it's still three separate calls means the core service architecture is the blocker. No amount of GUI polish can fix that until they refactor how app segments, servers, and policies are provisioned atomically.

IoT on this foundation is just asking for your re-auth loops to become the main event.