Software Catalog Templates: pre-made taxonomies for microservice, resource and software catalogs
Port’s secret power (well, it’s not that secret) is its software catalog. Port’s software catalog is a central metadata store for software, environments, resources, pipelines, CI/CD, cloud resources and more. The fact that it contains all this data supports all kinds of cool use cases from a CI/CD catalog to creating a Kubernetes catalog.
If you follow what we write about the data model underlying the software catalog - the heart of our no-code approach - we place a lot of emphasis on being able to choose your own software catalog. We talk about being able to use a “running service” blueprint and how to think about a taxonomy for your software catalog. But should we provide platform engineers that set up Port with a blank slate to begin defining their software data model? Up until now, we did. Our demo, for instance, contains an elaborate set of blueprints that form the software catalog. But we do know that each type of engineering environment and use case works best with specific approaches, or templates, to the software catalog data model. That’s why we’re announcing templates.
Why software catalog templates?
With templates, we’re truly delivering on the ability to quickly set up your internal developer portal with a software catalog template that best works with your use cases, data model and needs. We don’t expect your choice of template to be static - you can play with templates and improve them, introducing any type of blueprint you need and creating a super-opinionated software catalog that fits how your engineering organization works.
In the several days since we’ve started using templates, we’ve seen a huge change in how people interact with Port. But there’s more to it than just a faster and better setup for our clients. What this does is pave the way to think about Internal developer portals and how they fit with the core use cases in platform engineering. We’re certain this isn’t the last time we’ll explain the different templates we’ve started with and the best practices associated with them, because each company can find itself in one or some of the templates.
Six options to build a software catalog and counting…
This post will explore the six options covered in our first software catalog templates, letting you build a software catalog (through predefined Port Blueprints) by
- Mapping git provider data
- Using GitOps
- Connecting your CI/CD pipeline
- Mapping your Kubernetes ecosystem
- Mapping your cloud ecosystem
- Using IaC
Once you set up Port, you’re asked to select a template (or begin writing blueprints yourself). Whatever choice you made isn’t final. You can always edit templates or combine them.
Let’s do a deeper dive into each of the different templates. We’ll deal with IaC based software catalogs in a later post.
A microservice catalog using git providers
This is the classic “microservice catalog” use case which is about giving developers visibility into the software development lifecycle. In this case, the microservice catalog will collect data from git providers and populate the blueprint templates, creating software catalog entities that will show developers the information they need, in-context, with the right abstractions, permissions and more. This template also comes with a built-in maturity scorecard to ensure quality standards are met.
It’s pretty simple to add additional blueprints to this template, turning the microservice catalog into a metadata-rich software catalog containing additional information about CI/CD, cloud resources, Kubernetes and more.
A software catalog using GitOps
This template uses GitOps and generates a backstage-style C4 software catalog. The strength of this approach is that it goes beyond microservices, and catalogs underlying cloud resources, the deployments and the related dependencies. Note the API blueprint, which shows your API specifications through a swagger UI, and the built-in scorecards.
As always, you can add additional blueprints, such as running service and any other blueprint that comes in handy.
A CI/CD based microservice catalog
This method uses CI/CD to build a microservice catalog. This type of catalog unifies CI/CD data that is spread across multiple systems and repositories, so you can see all build and deployment configurations, artifacts, version numbers, environment variables, dependencies and more. By creating a single source of truth for CI/CD, you can also use it as part of automated workflows and solve version and security issues. For example, notify the relevant developers on Slack when a deployment has failed.
A Kubernetes catalog
This catalog is based on our Kubernetes exporter which supports any type of CRD, such as ArgoCD. This catalog takes the different Kubernetes resources (Deployments, pods, namespaces etc) and maps them into blueprints for a kubernetes catalog, creating Kubernetes entities. It also supports showing the relevant abstractions to developers, in order to reduce cognitive load, for instance, using the “workload” blueprint to abstract the different workload types (replicasets, deployments, daemonsets, statefulsets). To see how you can combine the K8s and microservice catalog templates to create a view of your services and deployments, watch this webinar.
By providing developers with an abstracted view of Kubernetes clusters, some of the complexity can be taken away, and standards enforced through Kubernetes scorecards to avoid misconfigurations. You can also use scorecards for deployment health, pod node placement and CPU limits so developers can troubleshoot issues.
Cloud resource catalog
Based on our cloud exporters this template builds a cloud resource software catalog. It brings live cloud resource data and maps it according to the blueprints into software catalog entities.
Adding cloud resource data into the software catalog enriches catalog data immensely. In the case of AWS you can add data about Lambda functions, S3 buckets, SQS queues, ECS services and anything in the AWS cloud control API (500 resources!).
Natural additions to this template can be SNS & SQS Topics, S3 Buckets, and RDS DB instances.
Our next template release will also add developer self-service templates to these blueprints. This will allow you to quickly implement popular actions such as scaffolding a microservice, creating a new incident, creating a cloud resource and more. Stay tuned!
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