Aside from having all the data in there.. were the...
# general
j
Aside from having all the data in there.. were there integrations or something else that turned your developer portal from meh to awesome? Running a PoC on backstage and trying to get it into something interesting without it having all the services in it.
c
Do you have a specific set of features you are looking for in an IDP? I've spent a lot of time with Backstage, and have found that finding "awesome" is really about addressing your specific use cases with the platform.
j
There are many. I’m hoping it will be a central point of both information about services, but also a means to start ratcheting up quality and service stewardship.
c
Backstage, largely, has these islands of functionality (by way of plugins) and it's pretty pretty common for the result to feel just like that: somewhat disjointed functionality all under the same interface.
Full disclosure: I am a vendor in the space. But, the most "awesome" part that we've seen is when we bolt AI capabilities on top of the data. Instead of the interface being a relatively static React app, the interface becomes conversational and directly in your IDE.
j
which is to say.. "it's gonna feel janky" ?
c
Honestly, I think it really depends. It is non-trivial to get going and to maintain. We built and productized a fully-automated way to build and operate Backstage, and for a variety of reasons we are changing paths to support (what we think is) a more robust path forward.
There are certainly solid areas of Backstage, but they tend to be found in the core path: think docs, scaffolding, etc. and less so in the plugin ecosystem. Plugins have been a struggle for the community due to varied support levels, quality concerns, etc. Oftentimes plugins are brought to the community to be able to mark the "we support Backstage" check box, but are not always well-maintained after that.
j
I'm not trying to ask backstage specific questions.. but generally.. what's the watershed moment for a developer portal and how close can you get before your catalog it ~100% filled in?
c
And, likewise, I am not trying to bash Backstage...just giving my perspective from having worked and contributed to it.
For us, we were always after the data that exists under the IDP...essentialy a graph of the entities within the org. So, for us, the watershed moment was using that data to connect the entity data with an LLM (and other tools like MCP) to provide a natural language interface. From that interface we can interrogate and take specific actions against the live systems expressed by our entity graph.
j
How do you keep your entity graph up to date? Social pressure / process? Or some technical solution?
c
Similar to Backstage, we have processors that interrogate systems for entity data. But, unlike Backstage, where much of the data comes directly from those
catalog-info.yaml
files, we only need the high level entity data itself. Once we know about the entity, we directly interrogate the system itself (via MCP).
j
we directly interrogate the system itself (via MCP)
-- Which system?
e.g. like you're calling http apis or something?
c
Yes, MCP servers are just connectors to the data in those systems. So, here we know about say a Github Repo, so client may call the Github MCP for data about a Repo entity.
Backstage and similar tools will give directed views of ie. last Actions run status. But here we are able to use the LLM to create more complex flows. For instance: "tell me which repos have the highest rate of Actions build failures"
So here instead of looking at a (mostly) static React site which probably require the end user to dig for the data, I am asking the tools to correlate the data for me.