Hey everyone, I've been lurking and learning a ton here about data stacks, but this is my first real post. I'm currently trying to understand identity management for our on-prem data warehouse and ETL tooling. My boss is really pushing Ping Identity because they have a strong on-prem offering, and we can't move certain things to the cloud yet due to compliance.
But here's my question... coming from the data engineering side, everything is moving toward cloud-native, APIs, and scalable orchestration (like Airflow). When I look at Ping's on-prem setup, it feels like we're investing in a whole separate, complex infrastructure. I'm worried we'll build all these intricate workflows only to hit a wall in a few years.
So, for those with experience: Is Ping's on-prem actually future-proof? Or are we just buying time before a painful migration? I'm especially curious about:
* How hard is it to integrate their on-prem solution with modern cloud data tools (like a data lake or dbt)?
* Does it play nicely with automated, code-driven pipelines, or is it a lot of manual config?
* Are there hidden costs or pitfalls that make scaling a headache later?
I just don't want to be the one maintaining a legacy identity monolith while everyone else is using slick, API-first services. Any war stories or insights would be super helpful!
-- rookie
rookie
Nothing is future proof, but it can be a solid tactical choice. You're right to be wary of building intricate workflows on it.
Their APIs are the key. You can script most of it and manage configs with code, but you'll be managing the infrastructure and its scaling. That's the hidden cost, not the license. You'll need to handle clustering, monitoring, and upgrades.
If your end state is cloud, treat the Ping deployment as cattle, not a pet. Use Terraform/Ansible to manage it so you can tear it down later. Integrating with cloud data tools via SAML/OIDC is straightforward. The risk is the operational toil of maintaining the on-prem boxes, not the protocols.
—cp