Announcing the software catalog dependency graph

Introduction

‍

The software catalog in the internal developer portal is much more than a microservices catalog. It is both services and infrastructure aware and shows all information in context. By combining information about clouds, environments, software, engineering tools as well as ownerships, docs, APIs and more, it provides the ability to really understand anything software in real time. 

Here’s a table to show the types of information shown in the software catalog (imagine the dependencies and contextual information hidden in the interplay of all these elements):

{{tabel-2}}

‍

In the real world, data is fragmented across many silos and devops tools, while devops and developers need to see the entire picture, in context. While some questions can be answered by looking at an individual entity within the software catalog (Who is on call? What version? Where’s the monitoring link? The API?), some require additional context - dependencies.

This would answer questions such as which cloud resources in the region are related to which environments and services, and what are the associated resources affected by an outage.

If the software catalog is a living inventory of anything software, cloud or in between, dependency mapping is a living map that lets you visualize dependencies in a way that is understandable to humans, and to filter what you need to see at any given time.

‍

Microservice dependency examples 

The software catalog sees it all - cloud resources, versions, kubernetes namespaces, on-call resources and more. 

But sometimes the human eye can’t make sense of  all dependencies, and this is when a dependency graph comes in handy.

The dependency graph visualizes the dependencies between entities in the software catalog, providing perfect context when assessing risks, troubleshooting, determining priorities and understanding the environment. 

Here are three examples:

‍

The microservice dependencies point of view 

In this example we can see a specific service, all its versions, which environment they are deployed on, the associated k8s namespaces and the multiple clouds where these entities exist.

‍

The devops point of view for microservice dependencies

In this example you can see a K8s cluster with all of its relations - the specific region in AWS, the namespaces inside the cluster in the running pods in each namespace. This graph gives you full visibility on the structure of the cluster

‍

The developer point of view of microservices dependencies

In this example, we can see that the "cart" service is related to another service, a kafka topic and a database (combination of software and resource dependencies). And we also can see the resource dependencies of the related service (the "order" service). This will help the developer who is trying to determine issues related to a service.

‍

The NOC or Security point of view for Software dependencies

Dependency graphs also play a role when security issues or audits are required, as in the log4j vulnerability. In this case, graphs make it easy to determine where dependent packages or other issues exist. This can also be done through searches or queries in port. (linK). This capability answers questions across clouds, accounts, microservices, deployments and versions.