Pets versus cattle

Traditionally, pets or cattle has been a way of defining your data center resources. It’s an analogy that describes a collection of hardware or virtualized resources as either pets or cattle.

Pets

Pets are resources that are owned by individual users/teams or managed on an individual basis.

Normally, they are seen as important fixed points within any application architecture and, like with a pet, you do the following:

• You give them names: For example, your server may have a hostname that looks something like backendapplication.server.domain.com, so it is easily identifiable.
• You feed and water them: For example, you take and keep backups that you review regularly. You keep a close eye on resource utilization and add more RAM and drive space as required.
• If they get ill, you care for them: They have monitoring agents installed, meaning you are alerted if there is a problem – sometimes 24/7 – and if there is an issue, you do everything you can to restore service by having troubleshooting procedures in place.
• You expect them to live for a long time: Given their importance within your application architecture and that you are caring for them, you expect them to be around for quite a while.

Resources that are now considered pets have typically been around for some time, and their configuration has organically evolved over that time based on their utilization, making them each a unique deployment, which is why you care for them, just like having a real pet – a good example of this is a long-running server.

Cattle

With resources that have been deployed to be treated as cattle, you only care about the health of the herd and not an individual resource:

• There are too many of them to give names: For example, your servers may have a hostname that looks something like beapp001.server.domain.com to beapp015.server.domain.com; you just keep incrementing the number rather than assigning a unique name that makes them easily identifiable.
• You watch them from afar: Given the number of resources, you only really care about the availability of the herd, meaning you probably only just ship performance stats and logs from the resources, and you do not need to back them up as it would be quick to replace them.
• If they get ill, you replace them: As already mentioned, if there is an issue with a resource, rather than troubleshoot the problem, you terminate it and replace it with another resource ASAP. Typically, this process is automated so that a resource is quickly taken out of service and another one put in place.
• You don’t expect them to live for a long time: Given their numbers, they can be quite short-lived – in some cases, resources may only exist for a short amount of time to handle an increase in the workload. Once the demand for additional resources has ceased, some of the resources are terminated.

Conclusion

Pets versus cattle mainly applies to application deployment strategies rather than purely just the underlying infrastructure. After all, let’s say your application, for whatever reason, needs to run as a single fixed point – for example, your application does the following:

• Writes essential files to the local disc, which can’t be lost if an instance is terminated
• Has manual steps for bringing an application instance online after it has been deployed
• Is licensed to a MAC address or CPU ID of a host

In this case, you may not be able to treat your deployments as cattle, but you can write your Infrastructure as Code so that the bulk of your deployment is as automated as possible.

These are technical reasons, but there are some considerations from a business point of view as well.

The one that will get most businesses’ attention is cost efficiency. Your choice of either a pets or cattle approach could have a significant impact on your hosting costs.

The cattle approach, which treats servers as ephemeral resources, allows for better resource utilization and automated scaling, potentially reducing costs. On the other hand, deploying pets, which emphasizes individual server care, may result in higher maintenance and management costs but could be justified for mission-critical applications that demand special attention.

Taking a cattle approach enables faster deployment and scaling of your workloads; this allows businesses to respond more quickly to market changes and customer needs. Deploying pets might lead to longer deployment times, potentially impacting a company’s competitiveness.

Regulatory and security requirements could also influence the choice between pet and cattle deployments. The pets approach, focusing on managing individual resources, may be more appropriate for businesses with strict regulatory or security requirements, as it allows for more fine-grained control and auditing of server configurations. However, the cattle approach, emphasizing automation and rapid scaling, might not provide the same level of control and may require additional efforts to ensure compliance and security.

Now that we have a good idea of the type of deployments you could be dealing with, let’s now talk about what this means for an Infrastructure-as-Code deployment.