Improve discoverability with inventories and relationship tracking

As your organization grows, so does the amount of stuff you need to keep track of. It’s not uncommon to find duplicative efforts because one team doesn’t know about the other one. As people move between teams, new people join the company and others leave, projects can become orphaned. Inventories help solve these issues.

An inventory a tool or system used to track, manage, and organize an organization's technical assets. These assets include code, APIs, containers, virtual machines (VMs), team permissions, and more.

Not keeping track of assets can lead to technical sprawl and waste simply because you can't easily discover what already exists. Losing track of what already exists is a common challenge. For example, consider this quote:

We've got a ton of containers or [VM] instances running. Can we delete our old VMs? Nobody knows. We need to come up with a way to clean up old stuff and use proper tags so that we know who’s the owner or team who can inform us on what can we do and what the lifecycle is…. We don’t know if we can shut down a particular VM because we are not certain what will happen. - Martin, DevOps Engineer, Large Logistics Company

How tailored inventories improve tracking, security, and reuse

Part of what you need is an inventory that provides help to track all the "stuff" that you’ve created or built in your ecosystem that internal customers can visualize in a comprehensible way.

An inventory can improve security, promote reuse, and generally make discovery easier. There are different tools available for tracking different types of assets. Each of these tools provides an inventory to help you manage, track, and clean up waste.

Available tracking tools include:

• Azure Deployment Environments let you track complex infrastructure created through infrastructure as code (IaC) as an abstract environment
• Azure API Center provides a way for developers to discover and consume APIs.
• Package registries like GitHub Packages or Azure Artifacts (or other inventories of approved packages and SDKs) improve supply chain security.

When deciding on the visibility of your inventories, consider the best approach for your organization. Some organizations allow all developers to see software assets, but only a few can modify them, similar to an open kitchen. Others, especially in regulated industries, restrict access more tightly, sometimes even limiting visibility to project names due to sensitivity.

Use relationships to aid in discovery and tracking

Having one or more inventory systems that help you track what you have is critical to platform engineering practices and avoiding technical sprawl. Initially having a set of flat inventory lists might be enough. However, you can also improve discoverability by adding relationships between different assets across multiple inventories. Regardless of the level of visibility you require, having a centralized aggregation point enables teams to quickly search and discover all the assets available to them. This promotes reuse, reduces redundancy, and establishes a consistent approach to governance.

Consider the relationship between an API definition and the deployed application code that implements the interface. This code is stored in a repository and managed by a team and provides documentation on its use. Dev, test, prod, and even temporary sandbox environments are created. In cloud native scenarios, the environments might be deployed into a shared Kubernetes cluster. The development team building the API, and any internal consumers of it needs to be able to get information about each of these things, but how the resources relate isn't obvious.

To start, you might use something as simple as a wiki page to help track how each thing relates to one another. But documentation ages quickly and can be difficult both find and parse. Ideally, you would have a system with a relationship graph that can power user interfaces to traverse these relationships in your inventory. To truly improve discoverability, you’ll need to be able to associate things stored in multiple types of inventories or graphs together. You might not need to consume inventories directly, but you'll likely want to be able to associate it with information in an API catalog system.

To use the digital store analogy, it can also be useful to associate the items (templates) in your catalog with the resulting inventory contents. For example, if you realize one of your templates creates an insecure configuration, you'll need to quickly find all the resources that were created the template to fix them. Even start right application templates are essentially starter kit bundles in this catalog that tie to other types of catalog items (like IaC templates). Tracking these associations would allow you to proactively find any application that references a bad IaC template even if no infrastructure has been provisioned yet.

A simplified variation of this conceptual, high-level developer platform graph can be found in a few toolkits and products today, though what it is called varies. For example, the open-source portal toolkit Backstage.io calls this a software catalog while other products use different terms. However, most of these products and toolkits assume you're using their broader feature set, and require the contents of your inventories be duplicated inside them. This duplication means that the contents of the catalog database isn't user specific, can become stale, and isn't controlled by the actual source system's user authorization mechanisms. However, this may work just fine for your organization if you're following an open kitchen approach.

Learn more about concepts that can help.