The “cattle vs pets” analogy still matters, especially for brownfield automation. Learn how switching your infrastructure from “pet” names to “cattle” labels is a quick way to get the ball rolling without overhauling your environment.

. . . . . . . .

When teams talk about automation, one of the first objections I hear is that the environment is too old, too unique, or too complicated to automate.

While it’s true that brownfield automation can definitely be trickier than greenfield, it’s usually easier than people expect.

Because here’s the truth: you don’t need to start from scratch to make your infrastructure automation-friendly. You just need to start labeling it better. It’s about aligning with the cattle vs pets mindset that favors structure over identity.

Instead of trying to standardize everything at once or rewrite your environment from the ground up, you can start by organizing the information you already have more intelligently. And that begins with three simple labels: role, type, and status.

Why the Cattle vs Pets Analogy Still Matters for Automation

You may have heard the analogy: Some infrastructure is treated like pets, others like cattle. The idea is that pets are individually named, lovingly cared for, and irreplaceable. Cattle, on the other hand, are managed in bulk, identified by role, and easily replaced.

While the metaphor may be overused, it still carries real wisdom.

Infrastructure that behaves like pets resists automation because it’s managed by identity. Automation thrives when systems are treated based on function instead. That’s the heart of the cattle vs pets analogy—it emphasizes role over individuality. You don’t need to know which exact device is involved, you just need to know what kind of device it is and what it’s supposed to do.

Why Naming Falls Short—and What Cattle vs Pets Gets Right

For years, infrastructure teams used names as a makeshift database, trying to capture everything about the resource in as few letters as possible. We ended up with names like atl1-srv-web-lnx1 to represent a web server in Atlanta running Linux.

But as environments grew, those names got longer, more ambiguous, and harder to maintain. At some point it becomes nearly impossible to decipher what we wanted to capture in the first place.

Worse, names are inherently static. They’re not suited for capturing dynamic information like lifecycle stage or operational status. And if you’ve ever broken a script because someone deviated from the naming conventions, you know how fragile a name-stuffing approach can be.

Rather than trying to capture everything in names, a more resilient path is to store and manage that data separately. That’s where structured labels come in.

Label Resources with Role, Type, and Status

The easiest way to get started with making your infrastructure automation-friendly is to consistently tag each object with three attributes, what I like to call the three golden attributes:

• Role: What does it do?
• Type: What is it?
• Status: What’s its lifecycle state?

This simple classification system can and should be applied to almost everything: servers, virtual servers, IP addresses, sites, IP prefixes, VPC devices, interfaces, cables, circuits, routing protocols, and so on.

Applying the labels doesn’t require wholesale changes in your environment. And it creates the kind of structure automation thrives on.

Role, Type, and Status—How to Use Them

Role tells you the main function of an object:

• A server might be a web server or database.
• A network device might be a core router or an access switch.
• A site might be an office or datacenter.

Type captures implementation details:

• That server might be running Linux or Windows.
• That device might be running Arista EOS or Cisco IOS.
• That site might be a small-office or large-campus.

The type is very important because it usually defines the implementation and helps manage vendor-specific requirements.

Status is meant to capture all the lifecycle stages of an object:

• provisioning, active, maintenance, decommissioned

The list of possible statuses will vary greatly between a site and a server but the idea remains the same.

Map Roles and Statuses to Your Workflows

With the three golden attributes of role, types, and status applied to everything, it becomes far easier to reason about your infrastructure programmatically, and to build automated processes around it.

Even in a messy brownfield environment where there’s not a lot of standardization, consistent labels will allow you to filter, group, configure, or deploy based on the three attributes.

Most engineers can think about the expected configuration of an uplink interface on an access switch without knowing the name of the device or the interface. The exact implementation will depend on the type and status, but abstracting the names with the role is a huge step forward.

Statuses are also extremely helpful to keep track of the current state of an object in a bigger workflow. For example, when provisioning new infrastructure there are likely multiple steps involved, and between each step, a specific workflow needs to be executed, either manually or using automation.

Use a Source of Truth to Stay Organized

One reason we’ve traditionally used names or descriptions to store all our infrastructure data is that, until recently, we didn’t have a better place to save and organize it. That’s no longer the case.

A source of truth (SoT) is the modern solution for managing infrastructure data in a structured, extensible way.

It doesn’t have to be complex to get started. You can begin with a simple inventory using the three golden attributes and let it evolve into something more complex over time.
(Infrahub is purpose-built for this use case, by the way. It allows you to define your own schema and apply roles, types, and statuses to any object.)

Start Small: You Don’t Need a Full Overhaul

This isn’t an all-or-nothing proposition. You can start by labeling just one category of objects, like interfaces or sites, and expand from there. The key is consistency, not completeness.

Once your infrastructure is consistently labeled, you can start building workflows around those labels. Think about provisioning new devices, changing software, or auditing configurations. All of these can be automated more easily when driven by structured data.

Start Small: Think Cattle vs Pets

Old habits die hard. In my experience, the hardest change we face in undertaking an automation project isn’t refactoring code, but refactoring our mindset.

Part of that is about shifting our mental model from managing things by name to managing them by function and context. We’ve become accustomed to using names as a makeshift datastore because we didn’t have a better option. Now we do.

You truly don’t need a pristine greenfield environment to get started with automation. You don’t need to rip and replace. The first small step is stop thinking like a pet owner and start thinking like an infrastructure architect.