Skip to content
Notifications
Clear all

My results after migrating 200 remote sales reps off Citrix

2 Posts
2 Users
0 Reactions
0 Views
(@kubernetes_tinker_99)
Estimable Member
Joined: 4 months ago
Posts: 56
Topic starter   [#9248]

Hey folks, kubernetes_tinker_99 here. I usually hang out in the GitOps and service mesh threads, but I just finished a massive infrastructure migration project that I thought was worth sharing here.

We moved 200+ remote sales engineers off a legacy Citrix VDI setup and onto Perimeter 81 for Zero Trust Network Access (ZTNA). The driver? Cost, complexity, and our sales team complaining about latency when demoing our SaaS platform (which runs on my k8s clusters, of course 😅). The goal was to give them simple, secure access to internal demo environments and CRM without the Citrix overhead.

Here’s the nitty-gritty of what we found:

**The Good:**
* **Deployment was shockingly fast.** We used their Terraform provider to automate gateway and policy creation. Wrapped it all in a Helm chart for good measure (old habits die hard).
* **The agent install for the reps was trivial.** A simple download, authenticate with SSO, and they're on the "secure" network. The reduction in support tickets for "I can't get into the demo portal" was about 90%.
* **Fine-grained access policies** were a win. We could define policies like: "Sales-EMEA group can only access the European demo API endpoints on port 443." This is way more precise than our old network-layer VPN.
* **Observability integration** was decent. We shipped their audit logs straight to our Loki stack. Seeing connection events as Kubernetes events was a fun hack.

**The Gotchas & Pitfalls:**
* **The "Smart DNS" feature** initially broke some of our internal service discovery (CoreDNS-based). Had to tweak the agent configs to exclude our `.cluster.local` zones.
* **Pricing model** can sneak up on you if you're using lots of gateways in different regions for low latency. We started in three regions and ended up needing five.
* **API rate limits** on their management API bit us during initial bulk policy creation. Had to add some `sleep` logic in our Terraform apply.

**Performance & The Bottom Line:**
The sales team's feedback was overwhelmingly positive. Page load times for internal tools improved because traffic is routed directly to the app, not through a VDI. Our security team loves the application-level access instead of broad network access.

For a team used to managing YAML all day, the Perimeter 81 console is a different world, but their Terraform provider made it manageable for us. It’s not a Kubernetes-native tool, but it solved a real business problem.

Would I recommend it for a pure *kubernetes-admin-to-cluster* access? Probably not, I'd use something like `kubectl` with OIDC or a service mesh. But for a large, non-technical remote workforce needing simple, secure access to specific applications? It was definitely the right move for us.

Has anyone else made a similar jump from traditional VPNs or VDIs? Curious how your experience compares, especially around managing policies at scale.


#k8s


   
Quote
(@benchmark_bob_42)
Reputable Member
Joined: 3 months ago
Posts: 151
 

Interesting project. While the deployment speed and user experience are compelling, I'm curious about the performance baseline, especially for your sales engineers demoing a SaaS platform. Did you capture any latency or bandwidth metrics before and after the cutover? Something like a simple synthetic transaction pinging the demo API from a standardized remote location could quantify the improvement beyond anecdotal reports.

The reduction in support tickets is a strong signal, but I'd be interested in whether you instrumented the ZTNA agent itself for any performance overhead on the endpoint. Even a small CPU or memory tax can become noticeable on sales reps' laptops over time.


-- bb42


   
ReplyQuote