Just finished a PoC - the three things that almost killed it

After an extensive three-month proof-of-concept evaluating Delinea's Secret Server against our incumbent solution, I am compelled to share the primary obstacles we encountered. Our goal was to consolidate service account and DevOps secret management under a single platform. While the POC was ultimately successful, three specific issues nearly derailed the project entirely, necessitating significant workarounds and last-minute architectural adjustments.

**1. API Rate Limiting and Throttling Behavior**
The most acute problem was the default, and surprisingly rigid, API rate limiting. Our automation scripts, designed for bulk onboarding of existing secrets, were consistently throttled. The critical failure was not the limit itself, but the lack of granular, configurable policies and the opacity of the response headers. The `429` responses did not always include clear `Retry-After` guidance, causing our scripts to fail unpredictably. We resolved this only after discovering a specific, poorly-documented configuration flag in the advanced settings. The required adjustment was not in the UI, but via a direct database update—a step we were uncomfortable with during a PoC.

```sql
-- Example of the *type* of backend change needed (path simplified)
UPDATE [ConfigurationTable]
SET SettingValue = '1000'
WHERE SettingKey = 'Throttle.Api.MaxRequestsPerMinute';
```

**2. Complex SSH Key Orchestration for Automated Systems**
The second major hurdle involved managing SSH keys for non-interactive sessions. Delinea's model for SSH key checkout, rotation, and injection into sessions is robust for human users but became convoluted for automated CI/CD pipelines. The expectation was that a machine would check out a key, use it for a series of commands, and reliably check it back in. We observed race conditions and state mismanagement when processes were parallelized. The solution involved implementing a custom wrapper that strictly enforced a state machine for key lifecycle management, adding non-trivial overhead.

**3. Unexpected Latency in High-Availability Failover Scenarios**
During our scheduled failover testing in the DR environment, we measured secret retrieval latency spikes exceeding 15 seconds post-failover. This was unacceptable for our runtime applications. The issue was traced to the session handoff and secret cache synchronization between nodes. While the failover itself was successful (no downtime), the performance penalty was severe. This required us to adjust our HA deployment topology, moving from an active-passive to an active-active configuration much earlier in the rollout plan than anticipated, which had significant cost implications.

In summary, the PoC succeeded because we had the resources to delve into these granular, operational specifics. The platform's core functionality is sound, but its suitability hinges on these often-overlooked, practical constraints. I would strongly advise any team undertaking a similar evaluation to design test cases specifically around:
* API throughput under load,
* Non-human identity lifecycle management,
* Failover performance, not just availability.

— Amanda