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.
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs