Traditionally enterprises operated a “limited” number of servers in their IT footprint. A server hosted a single operating system and commonly served a single application. Whenever a new server was introduced to a company an administrator would take it into his care and would nurture its wellbeing for the lifetime of the machine. Commonly treating it as a well loved pet, ensuring the health of the machine and spending endless hours tuning it, improving it and nurturing it.

With the introduction, or rather the introduction into mainstream, of virtualization the “pet culture” diminished a bit. Administrators moved away from the love for the combination of hardware and software as a single entity. The new pets became more the virtual operating systems, as administrators had to take care of more “pets” (virtual machines) the love per virtual machine diminished. However, still administrators spend hours tuning, improving and nurturing the virtual machines entrusted to them.

With the introduction of more rapidly deployment methods and public- and private-cloud thinking the way administrators care for their (virtual) machines diminishes even more. The industry moves more and more to a model where a virtual machine is something considered unimportant and replaceable.  With the introduction of more rapidly deployment methods and public- and private-cloud the creation and re-creation of a virtual machine and the implementation of the needed applications on this machine has become something that can be fully automated and is a repetitive procedure.

Instead of caring for a instance of a virtual machine like a pet virtual instances are becoming more cattle like. When owning a large stock of cattle the care per cattle is less than that for a single pet. Cattle are replaceable and less “loved” than the average cat.

When we take, as an example, the Oracle public cloud solution and the compute instances you can deploy on this cloud; once you have ensured that you can deploy all the machines you need in a fully automated manner and can “order” them the time spend on debugging a specific issue on one of the instances will be less than you would in cases where you cannot simply re-order the machine.

In many situations a standard fix-before-deploy time of 15 minutes is used. For business critical systems this number can even be very much lower. In case an issue is seen on a machine an engineer will spend maximum 15 minutes in trying to resolve the issue manually. In case the issue is not resolved in 15 minutes the machine is “destroyed” and a new machine is re-depolyed based upon a template and automated deployment routines.

For more information about this topic, feel free to contact Johan Louwers directly via