GeekTechStuff

In a DevOps sense, “cattle not pets” means creating services and / or infrastructure that can be maintained, destroyed and re-deployed with little human interaction.

Why Cattle Not Pets?

Imagine the scenario: As a tech user, IT professional or engineer you may find yourself in charge of looking after a particular piece of technology (e.g. an NginX web server running on Linux). You could spend a large amount of time manually downloading / installing the various applications that are needed on the server, setting directory/file permissions, creating local user accounts and tweaking settings. Then you could schedule a regular time in your diary / calendar to look at installing updates, run the update commands and manually check everything is still working okay. That’s a lot of manual work, and that server is getting a lot of your attention (just as a pet would).

Then one horrible day the server dies and as a budget saving you have only been backing up the directory containing the web content. Now time is going to have to be spent (again) manually downloading / installing the various applications, setting directory / file permissions, creating local user accounts, tweaking settings…etc…etc…etc…

To make the scenario a little worse, imagine that several other servers have become your responsibility and each requires just as much time /effort as they are all manually created. It would be like taking care of several new puppies (dogs) or kittens (cats) that need time to nature, learn and grown – i.e. A lot of your time / attention, and hopefully (as pets) they grow a bond with you.

Where Does Cattle Come In?

Cattle farmers care for their cattle, but in a slightly different way to pet owners care about their pets. I don’t recall ever seeing a cattle farmer trying to teach a cow to sit, or trying to teach a cow where to do its toilet business, or giving a cow prime space on the comfy sofa. In the same sense tech users, IT professionals and engineers need to care for services / infrastructure but not to the level where the services / infrastructure are becoming pets.

How Is This Achieved? Automation!

Instead of manually downloading / installing software, manually creating local user accounts, or manually tweaking configuration files, spend some time automating the process. There may be an initial time loss whilst the tasks are placed into configuration scripts (e.g. Bash or PowerShell scripts) or, in my opinion an even better solution, configuration management solutions (e.g. Ansible playbooks) is more than worth it when the tasks have to be carried out a second or more time.

Alongside configuration is Infrastructure as Code (IaC) – imagine this scenario: You are the tech go to for a small team or organisation that has built it’s infrastructure in the cloud (choose the most appropriate one). One morning you get to the office (or if you are remote, you log in) and find that something horrible has happened – several services have stopped working, devices in the cloud have stopped talking to each other and someone has accidentally deleted load balancers / virtual machines. After you get over the initial panic you now have the job of going through logs to track what has been moved / deleted and putting it back / recreating it. But what rules did the security groups have in them? What permissions did the identity roles have? It’s going to take some time to sort.

If the infrastructure had been defined as Infrastructure as Code using a tool such as Terraform then the infrastructure could be destroyed and rebuilt using a few commands. The configuration of what needs to be built, where it should be built, which roles need creating and what their permissions are, could have all been saved into the infrastructure code. Of course, you would still need to figure out who / what caused the horrible issue in the first place, but at least it is more easily solved.

Is It That Simple?

As mentioned above, getting to the stage of having Ansible playbooks and Terraform plans ready to apply takes time. First up is the time spent planning how to implement the tools. It is important to have a good plan as it builds the solid foundation, get it wrong and you may spend more time (or multiple attempts) trying to get a solution in place or correcting the solution you have put into place.

Then there is time looking at the tasks that can be automated or placed in a playbook, and placing them into a playbook. For tools like Ansible there are roles (via Ansible Galaxy) that can help, but to me this is the fun bit of figuring out how to get a machine to certain state using only the configuration tooling (less human interaction the better for me in the future). This stage also involves time writing, testing, adjusting and retesting any automation.

Finally there is the culture of the organisation. I mentioned this briefly in a previous post, but if the culture of an organisation doesn’t want to automate or is not willing to use the tools then you may find services / infrastructure becoming someone else’s “pet”. This can cause issues such as configuration drift, as you try to define configuration or infrastructure in code and then someone else later manually tweaks that configuration so that it is different. At first it may not seem like an issue, but the moment the automation is used for deployment it will show the issue as something will break and time then has to be spent finding out what broke and why. This can be made even harder if the other person has not documented their changes.

Is It Only For Teams And Organisations?

I use the same mindset of “cattle not pets” at home with my personal DevOps environment. I have Ansible playbooks configured to carry out different types of configuration depending on how I want to deploy a Raspberry Pi (I frequently destroy and rebuild them for different tasks), or Vagrant / Ansible Playbooks ready to help deploy virtual infrastructure. In my opinion, if you are new to this approach then starting at home with this mindset is best as it gives you an opportunity to build it, refine it and then take it into the workplace to discuss with others.