This message was deleted.

Hi Roni. I am a devops engineer at my company and I am learning about IDPs and fail to understand where an IDP, fits specifically, in the gitops process. I read a few of your articles, and some stuff makes sense, like a software catalog with templates, and a self-service form for other non-git tools like okta. Backstage kind of makes sense with a ton of customization, but I would never use an IDP to deploy directly to the cluster, or am I wrong here?

Hi Artem, a proper IDP should be able to integrate with your existing workflows. I mean that if today you deploy to cluster with a Jenkins job, the IDP should be able to trigger the Jenkins job and understand the result. If you work in a GitOps way, the IDP should be able to perform a git commit with the values that the developer filled in through the UI to the relevant helm chart, for example. To conclude, IDP should simplify the day-to-day life of your developers without changing your organization's workflows and best practices.

Well my Jenkins jobs and argo workflows are all tied into our gitops process, so no code is ever deployed directly like manually running a Jenkins job, or manually applying a k8s manifest. So I dont think I would like the IDP to trigger any Jenkins jobs in my org. My gitops process understands where to deploy, the issue comes up when devs need to create their own environments with custom parameters and secrets. This is why I thought I need an IDP, but I feel like this is something else.

Totally agree with you 💪You need to use an IDP to solve the things that cause the most friction for your developers. In your case is to enable devs to create their own environments, and you also can leverage GitOps for ephemeral environments, but this time the commit will be triggered by the IDP

Ok, this is getting close but not quite there. On my end, everything is IaC, so the developers themselves do pushes/commits and not another app. Maybe what I need is just Vault to store secrects and configs and have a github action call it.

A Idp would allow you to abstract that into a ui if needed, for example https://krateo.io/ which uses backstage and crossplane behind the scenes, it has a ui to spin up a app or even a cluster by using dropdowns ( for devs ) behind the scenes it translates what you picked in the ui into a gitops template that gets comitted and crossplane takes over from there, on the ops side of things they are the ones that create the templates that drive things behind the scenes. If a ui is not needed you can just use backstage to display status of things as a more of a central place to get info at a glance.