Announcing the Software Catalog Dependency Graph
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):
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.
Book a demo right now to check out Port's developer portal yourself
It's a Trap - Jenkins as Self service UI
How do GitOps affect developer experience?
It's a Trap - Jenkins as Self service UI. Click her to download the eBook
Learning from CyberArk - building an internal developer platform in-house
Example JSON block
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Scaffold a new microservice
Deploy (canary or blue-green)
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Add / Remove / Update Column to table
Run Airflow DAG
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
A/B testing traffic route
Spin up remote Jupyter notebook
Containers & Serverless
Software and more