Hey all. I'm working on a proposal for an IDP and ...
# general
d
Hey all. I'm working on a proposal for an IDP and want to include a graph based backend. It seems like the options are pretty limited, especially if you aren't considering Humanitec due to the potential cost at scale and risk of vendor lock. I've looked at kratix and honestly couldn't get it running with a bucket state store, which with our security requirements would be a necessity. And it seems a bit immature for me to sell. I've looked at kusion, which I like. However, it's very much golang based (which I like, but my org won't). And it looks difficult for me to use our existing terraform modules and python library used in our pipeline libraries. Looking more objectively, we use Jenkins for CI and ArgoCD for CD. I would love to implement a graph based backend for the platform. We have a lot of custom logic built into a python library that our DevOps team wrote that can be reused. We also have a great library of terraform modules that could be used for non-k8s infrastructure. Are there other options I should look into? Or am I looking at building something myself?
j
Have you considered backstage? Its an open-source IDP project used by Spotify and I find that it’s been pretty great
d
We do have an implementation of backstage. Based on what I've been reading, that serves well as the UI but not so much the backend orchestrator
b
Why is it important that the backend has a graph-based implementation?
d
Open to suggestions. The ultimate goal is the developers don't have to manage the pipeline. CI picks up changes to a workload from virtually any repository and orchestrates changes to argocd, terraform, automations etc
platformengineering.org has done a good job steering me away from building out a pipeline that triggers other pipelines
c
So is the intention to use the graph as as an event source? Like, as the graph mutates, you will take some action?
d
☝️ yes I think so
again, open to other backend ideas
c
We are well down the path (headed to beta imminently) for a graph-based platform. Our first iteration is really about connecting the entities within the organization, and using those connections to either interrogate or take action against live systems.
Eventing has been on our roadmap for a while now, and we have good ideas on how this will take shape, but would love to hear more about your requirements.
Incidentally, we are using Apache AGE under the covers.
d
Anyone use KubeVela for a backend?
d
I am keen to hear alternatives as well, @Dylan Justice, thanks for the timely question.
d
Kratix has all the promise but I'm just struggling to prove it out in my environment. Kusion works but I don't want to have to rebuild all the business logic. [Radius](radapp.io) looks promising, but I'm afraid it's still too much IaC for our developers. A [score](score.dev) implementation may be required to do the translation. [KubeVela](kubevela.io) is looking the most promising
a
👋 I am one of the Kratix maintainers and glad to hear you are seeing good things in it but of course sorry to hear environment issues. I think we sorted the AWS permissions issue for you via the community slack yesterday but very happy to jump on anything else you run into including design/architecture if it helps!
d
I definitely appreciate the response. Looking forward to trying it out again.