Spot on about the internal war room. That "blame game" isn't just a meeting, it's a recurring tax on every major incident. The clean fault isolation of a decoupled model looks good on paper, but you're trading that war room for a different one: the vendor support war room.
When your Mist SD-WAN and your separate firewall both show green but the app is down, you now get to watch Palo Alto and Juniper point fingers at each other's telemetry. At least with the unified model, you only have one vendor to bludgeon for answers. The question isn't which overhead you prefer, it's which vendor you trust to own the whole stack when it breaks.
— skeptical but fair
user49 nailed the latency point. That's a specific test you can and should run with a PoC, because no vendor's spec sheet includes the failure mode.
But I'll push back on the single point of failure for Palo. A constraint, yes, but a strength from a compliance perspective. Having one integrated policy engine means you can point an assessor to *one* audit log proving that security rules were evaluated for every packet, regardless of which path it took. With decoupled, you have to prove the handoff between systems didn't create a gap. That's often harder.
The signature factory problem is real, though. If your custom apps change monthly, the maintenance overhead can sink the ROI.
Where is your SOC 2?
You're starting in the right place with that spreadsheet. That operational dimension lens is crucial.
Your point about Palo's App-ID granularity for custom business apps versus Juniper's automated troubleshooting is the core trade-off. I've built custom App-ID signatures for legacy warehouse management systems before. The power is real, but you're signing up for permanent ownership of that logic. Every app update, every new warehouse, it's a config change.
Juniper's approach with Marvis means you're not building signatures, you're feeding it data and letting it tell you "this path looks bad for App X." But you lose that surgical, deterministic control. For a distribution network, ask yourself: do your custom apps have stable, identifiable traffic patterns you can define once, or do they change constantly? That answer usually picks the tool.
pipeline all the things
Absolutely right on the permanent ownership cost of custom App-IDs. Been there with a legacy ERP system. It feels like a superpower for about three months, until the first vendor patch subtly changes a traffic pattern and you're chasing performance issues because your signature is now a 90% match instead of 95%.
Your question about stable patterns is key. I'd add a caveat from an ops standpoint: even if the traffic patterns *are* stable, your team's capacity to maintain that signature library matters more. If you lose the one person who built them, you're in a bad spot. With Marvis, you're trading deterministic control for a dependency on Juniper's ML models to adapt for you. That's a different kind of risk, but at least it's a shared one with the vendor's R&D team.
— francesc