So the whole team was convinced moving our secret management to Delinea's cloud service was the obvious "modern" play. Lift and shift, they said. It'll be fine, they said. Now our CI/CD pipelines have developed a fascinating new hobby: waiting.
The latency hit isn't subtle. What was a sub-50ms fetch from our on-prem Secret Server instance is now a 300-400ms round trip to the cloud, per secret. Multiply that by a dozen secrets across a deployment orchestration. Our Kubernetes clusters, especially at the edge sites, are not amused. The `kubelet` pulling image pull secrets now contributes a noticeable delay to pod startup.
```yaml
# This used to be a non-event. Now it's a bottleneck.
apiVersion: v1
kind: Pod
spec:
imagePullSecrets:
- name: regcred # <- External secret fetch via CSI driver adds ~0.3s per pod
```
The real comedy is in the "high availability" promise. Our on-prem setup had a clear, predictable failure domain. Now, when their cloud region has a hiccup—which happened twice last month—our entire secret fetch infrastructure grinds to a halt, not just a single data center. The retry logic in our clients just piles on the pain.
Has anyone else actually benchmarked this transition, or are we all just accepting the performance tax as the cost of not having to run the servers ourselves? I'm curious if this is a universal experience or if we've configured ourselves into a particularly slow corner.
I'm an IT manager at a mid-sized logistics company, and we've been running Delinea Cloud for about eight months after switching from a local Secret Server vault. Our main use is securing API keys and database credentials across a mix of cloud VMs and containerized apps.
Here's a breakdown based on our experience:
1. **Latency Hit**: It's real. Local fetches were under 20ms for us. Delinea Cloud consistently adds 200-350ms from our primary AWS region, and over 600ms from our edge offices. The delay compounds in CI/CD steps.
2. **HA and Outages**: The failure domain changes completely. We had one cloud region outage that took down secret access for three hours. Our on-prem setup would have failed over to the secondary node in a different rack. There's no local failover now.
3. **Pricing Surprise**: The per-user license seemed straightforward. The hidden cost was the API call volume from our automated systems. We had to move to a higher tier, which added about 30% to our projected cost.
4. **Client Retry Logic**: The standard SDK retries on failures are aggressive. During latency spikes, this can create a thundering herd problem and make things worse. We had to implement custom backoff in our integrations.
Given your focus on Kubernetes and edge sites, I'd recommend sticking with a self-hosted secret manager like HashiCorp Vault if you can support it. If you need the managed service model, ask the team: what's the exact pod startup delay tolerance, and can you accept secrets being unavailable during a cloud provider outage?
Exactly. The "failure domain changes completely" is the part everyone forgets in the glossy sales deck. You've traded a local, bounded failure for a shared, opaque one. When your on-prem node had a hiccup, your team could physically walk to the rack. Now you're in a support queue with a thousand other tenants, hoping their SREs had their coffee.
And the API call pricing got us too, though in a different way. We saw the same tier jump for automated systems, but then also got dinged for "high-availability queries" because the SDK retries counted as separate calls. So your point about the thundering herd during latency spikes isn't just a performance issue, it directly inflates the bill. Did you find their support was any help in adjusting the retry logic, or did you have to fork the client library yourself?
Your k8s cluster is 40% idle.