A Simple Strategy to Convert Your Pets into Cattle

When it comes to automation, one of the first objections I often hear is that our environment is too old, looks complicated, and is too unique to automate.

While it’s true that automating a brownfield environment can be more challenging than a greenfield one, in my experience, it’s easier than most people think if you follow this simple strategy to convert your pets into cattle without making significant changes.

The pets vs. cattle metaphor

Usually the pets vs cattle metaphor represents the idea that in order to automate, we need everything to be standardized. People often think everything needs to be the same; otherwise, automation becomes impossible. While standardization is important, it’s possible to address it piece by piece without needing to standardize everything at once.

One of the ways to understand pets vs. cattle is pets have names, whereas cattle don’t because they are commodities. There is wisdom hidden in this analogy. To progress in automation, we need to think of our infrastructure in terms of role and function instead of using names. Once we start thinking about our infrastructure based on role and function, it becomes much easier to define standards for all or parts of these roles and start automating.

The trap of overloading names with information

Many times, I’ve been involved in projects that tried to use the name of a server or network device as a makeshift database to capture everything about this resource in as few letters as possible, such as: atl1-srv-web-lnx1 to represent a web server in Atlanta running Linux.

While this may seem like a good idea at first, naming conventions evolve over time, and it becomes impossible to decipher what we wanted to capture in these names. Another common mistake is carrying multiple meanings in the same information. For example, using the role of a device to assume how it should be configured. Initially, these ideas seem great, but over time, as the infrastructure evolves, there is always a good business reason to deviate from the initial rules, leading to problems.

The key is to move away from names. In the cloud, it feels easier to automate because we don’t control the names given to each resource, and the cloud provider tends to allocate names or IP addresses that are hard to remember anyway.

The 3 golden attributes

Now there are the names we give objects and the names that are inherent properties of systems we are trying to manage. As an example, for a network device, we usually define the name of the device but we don’t define the name of the interfaces. Nonetheless whether we choose a name or not the goal is to label everything we want to manage with the 3 golden attributes : Role, Type & Status.

Role, Type and Status can and should be applied to almost everything : Server, Virtual Server, IP address, Site, IP Prefix, VPC, Device, Interface, Cable, Circuit, Routing Protocol etc …

Let’s explore these 3 golden attributes to understand better how to use them

Role

Role defines the main function of an element: 

• For a server : is it a database or web server
• For a network device : is it a core router or an access switch
• For a site : is it a manufacturing site or an office.

In some cases a given object may have multiple roles, if it’s delivering multiple functions, as an example : a server hosting both a web portal and a file server.

Type

The type captures implementation differences:

• For a server : is it running linux or windows
• For a network device : is it running Cisco or Arista
• For a site : is it a large office or a small one.

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

Status

The status is meant to capture all the stages of the lifecycle of each object

• Active
• Provisioning
• Maintenance
• Software-Upgrade
• Closed-for-Business

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

Map statuses & roles to your workflows

Once we have properly classified all our resources, it becomes much easier to reason about them and build automated processes around them. 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, as illustrated below.

Organizing information with a Source of Truth

One reason we’ve used names or descriptions to store all this information is that, until recently, we didn’t have a better place to save and organize it. 

A Source of Truth (SoT) is perfect for organizing all this information consistently. It doesn’t have to be complex to get started; you can begin with a simple inventory using these three golden attributes and let it evolve into something more complex over time.

By the way, it’s particularly helpful in context to have a SoT where the schema is flexible and can be changed incrementally to evolve with your needs. This is exactly with these use cases in mind that we created Infrahub in the first place to provide the most flexible Source of Truth that will allow you to define your own schema, with your own Statutes, Types and Roles on any objects. 

Conclusion

In my experience, the hardest change we face in automation is not refactoring code, but rather it is refactoring our mindset to work in a different way. 

Old habits die hard. We’ve been so used to using naming as a makeshift datastore because the problem it was trying to solve didn’t have a better solution.