hey team, is anyone aware of a developer portal that allows for externalizing or inverting the dependency on the service catalog. For example say we already have a rudimentary service catalog database and we want to continue to use it as the source of truth but add on additional capabilities that an IDP offers such as self-service scaffolding wizards or relationship graphs with third party vendor tools and products such as linking services in our catalog with tools like DataDog or doc services like Confluence or Git* Pages. Seems like most of the dev portals center around their own graph db and expect us to instrument our pipelines to mirror metadata about our services into the dev portal's catalog, but if the dev portal could call out to find out information from an external catalog that we own and maintain, that would be a pretty unique and compelling feature.

Hi there! Disclaimer: I am the CTO of getport.io. When selecting a developer portal, it's important to consider two key capabilities: the ability to create any desired data model and an API-first approach. Data model flexibility: A developer portal should empower you to create any data model you require, allowing you to mirror the structure of your database within the portal. This ensures seamless integration and consistency between your database and the developer portal. API-first approach: It's crucial to choose a developer portal that offers effortless ingestion and updating of entities, without enforcing the use of a YAML file for each entity. This flexibility enables the platform engineers to interact with the portal easily. Leveraging these two capabilities, you can establish a simple cron job that synchronizes data between your database and the developer portal. This ensures that the information remains up to date and reflects the latest changes. Then you can create self-service experiences for developers and visualize the relationships between different entities within the portal. I hope it helps!

I think there’s two different use cases. I’m writing a blog post right now about how Service Catalog is about the Developer Loop side and then there is a fan out into production into environments which is about the Operator side. These are different concepts and require different data models. Its important to understand what problem the service catalog is solving — is it developer creation velocity or operating velocity. Having a context switch btwn the two IMO is actually a good thing. In essence simple back links should solve this and strong naming conventions can go a long way

@Yonatan Boguslavski thanks for your reply, I'm aware we could easily sync data into the portal if necessary and an api first approach is definitely preferable here should we need to go that route. I suppose what we were wondering is if there exists any portals that allow us to bring our own catalog and annotate it via the portal system. We have quite a large service catalog already and some of the entities we are interested in capturing get down to a pretty granular level such as the networking infrastructure level. This may not be relevant to service owners / maintainers, but if a networking outage occurs having that relationship modeled so that service owners become aware instantly is very nice. Having to re-model all of those relationships in a portal slightly suboptimal.