¿Qué es Pets vs cattle?
Cultura de ingeniería y práctica de software
Pets vs cattle es una metáfora sobre cómo los equipos gestionan servidores e infraestructura. Las "mascotas" (pets) son máquinas preciadas, atendidas a mano, con nombre, particularidades e historia. El "ganado" (cattle) son recursos estandarizados y reemplazables que pueden reconstruirse o sustituirse sin drama. En el trabajo moderno con la nube y plataformas, la metáfora suele abogar por la automatización, la consistencia y la resiliencia. No es un llamado a la negligencia. Es un recordatorio de que los sistemas deben sobrevivir a la sustitución, no depender de que alguien cuide con esmero una máquina especial.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Imaginemos dos formas muy distintas de gestionar una granja. En una, cada animal tiene nombre, comida favorita y una larga historia emotiva. En la otra, lo que importa es el rebaño. Si un animal enferma, la granja sigue funcionando porque el sistema está diseñado para la sustitución, no para el rescate. Los equipos de software tomaron esa imagen para explicar la infraestructura.
Un servidor "mascota" es aquel que todo el mundo conoce por su nombre. Alguien lo ajustó a mano hace tres años. Nadie recuerda cada cambio. La gente tiene cierto miedo de reiniciarlo. Un servidor "ganado" se construye a partir de una receta repetible, normalmente en código, y puede recrearse rápidamente. Si falla, se reemplaza en lugar de conectarse a él a medianoche para convencerlo de que vuelva a funcionar.
La expresión importa porque convierte un modelo operativo técnico en algo que cualquier persona no especialista puede visualizar de inmediato. Ayuda a explicar por qué las plataformas en la nube, los sistemas de contenedores, la ingeniería de plataformas y la automatización de infraestructura empujan a los equipos hacia la estandarización. También ayuda a entender por qué algunos entornos heredados se sienten lentos y frágiles, incluso cuando el hardware en sí es potente.
Por qué importa
Esta metáfora trata en realidad sobre el riesgo y los hábitos operativos. Los equipos que tratan la infraestructura central como mascotas suelen acumular conocimiento oculto, correcciones manuales, configuraciones puntuales y un temor silencioso al cambio. Eso tiende a ralentizar las publicaciones, a hacer los incidentes más ruidosos y a complicar los traspasos. Gran parte del trabajo operativo repetitivo, es decir, el trabajo operacional sin valor duradero, crece exactamente en ese terreno.
Tratar los recursos adecuados como ganado cambia la naturaleza del trabajo. La configuración se define en archivos, se mantiene en control de versiones, se prueba y los recursos se reconstruyen a partir de patrones conocidos. Eso reduce el misterio. También facilita el escalado, porque se añaden unidades conocidas en lugar de clonar la obra artesanal de alguien y esperar que se comporte bien.
Para los líderes, la metáfora es útil porque vincula el presupuesto con la fiabilidad. Un equipo puede pedir tiempo para automatizar compilaciones, estandarizar imágenes de máquinas o invertir en herramientas de plataforma. Eso puede sonar abstracto. Pets vs cattle hace que la disyuntiva sea más fácil de ver. No se está pagando por aficiones ingeniosas de ingeniería. Se está pagando para reducir excepciones frágiles y hacer que el entorno sea más fácil de gestionar. Si alguna vez se ha preguntado por qué un equipo de infraestructura puede moverse rápido mientras otro parece permanentemente atascado en una ceremonia cuidadosa, esta metáfora suele explicar la diferencia.
También tiene una dimensión humana. Un entorno de mascotas suele depender de héroes. Alguien conoce la extraña regla de DNS, la versión secreta del paquete o el orden en que deben ejecutarse seis comandos de shell. Eso puede parecer impresionante hasta que esa persona se va de vacaciones. Un entorno de ganado traslada el conocimiento a sistemas compartidos, lo cual es más saludable para el equipo y más amable con las personas que hacen el soporte.
Cómo funciona
El origen del término
La imagen despegó en la computación en la nube a principios de la década de 2010. Surgió de debates anteriores sobre escalado acerca de la diferencia entre hacer una máquina más grande y ejecutar muchas máquinas intercambiables juntas. En la era de la nube, la metáfora caló porque capturaba un cambio real. El mundo antiguo tenía servidores caros y de larga vida que a menudo se configuraban a mano. El mundo más nuevo ofrecía cómputo elástico, lo que significaba que se podían activar y desactivar recursos según la demanda, a menudo desde código.
Lo que hizo que la expresión se afianzara fue su contundencia. "Desviación de configuración" es preciso, pero no tiene mucho impacto. "Deja de tratar los servidores como mascotas", sí.
Cómo se ve una mascota en el trabajo real
Un servidor mascota tiene identidad. Alguien le dio un nombre útil o sentimental. Puede alojar varias cosas importantes porque el equipo fue añadiendo trabajo a la misma máquina fiable. Ha sido parcheado directamente mediante acceso remoto. Su configuración vive en parte en la documentación, en parte en la memoria y en parte en ningún sitio. Si se comporta mal, el instinto es repararlo en el lugar.
Esto no siempre es el resultado de una ingeniería descuidada. A veces es una respuesta racional a las herramientas disponibles en su momento. En entornos locales, los largos ciclos de aprovisionamiento y la configuración manual fomentaban la preservación cuidadosa. Si conseguir una máquina llevaba semanas o meses, era lógico tratarla como algo valioso. El problema es que estos hábitos envejecen mal cuando una empresa necesita velocidad.
Cómo se ve el ganado en el trabajo real
La infraestructura de ganado está definida, es repetible y desechable en el sentido técnico y limitado de la palabra. "Desechable" no significa sin importancia. Significa que el recurso no es único. Se crea a partir de una receta estándar, a menudo con infraestructura como código, lo que significa que los servidores, las redes y los componentes relacionados se declaran en archivos y se gestionan como software. Si una instancia falla, la automatización lanza otra.
Esto suele ir acompañado de infraestructura inmutable. "Inmutable" aquí significa que no se sigue editando una máquina en producción indefinidamente. Se construye una versión nueva y se reemplaza la antigua. Eso reduce la probabilidad de que una máquina se desvíe gradualmente del resto. También se adapta bien al autoescalado, es decir, añadir o eliminar cómputo automáticamente según la carga.
En la práctica, el ganado no siempre significa servidores literales. La unidad intercambiable puede ser una máquina virtual, un contenedor, un nodo trabajador, un rack o incluso un clúster completo. Lo importante no es la forma del elemento. Lo importante es que el sistema tolera la sustitución.
Qué debe y qué no debe convertirse en ganado
Aquí es donde la metáfora se vuelve más interesante. No todo debería desmantelarse sin más. El cómputo sin estado es el candidato clásico al ganado porque normalmente puede recrearse desde código y reconectarse a servicios compartidos. Los almacenes de datos son diferentes. Las bases de datos, los sistemas de archivos y las redes suelen tener ciclos de vida más largos y mantienen estado, es decir, información almacenada que debe sobrevivir más allá de un proceso o una máquina.
Por eso los equipos maduros no repiten "ganado" ante cada objeto del entorno. Deciden qué capas deben ser intercambiables y cuáles necesitan protección cuidadosa, copias de seguridad y cambios controlados. Una lectura útil es esta: hacer que las capas volátiles sean fáciles de reemplazar, y hacer que las capas con estado sean fáciles de proteger, observar y recuperar.
Cómo se manifiesta en la práctica
Normalmente se puede identificar un estilo de ganado por los hábitos que lo rodean. Los equipos dependen menos del acceso remoto y más de los pipelines. Reconstruyen en lugar de parchear en producción. Usan imágenes base estándar. Los registros, las métricas y las trazas se recopilan de forma centralizada porque el sistema de archivos local de ninguna máquina individual es un diario de confianza. La planificación de capacidad se hace sobre flotas, no sobre hosts individuales queridos.
Ese estilo también moldea la arquitectura. Si se sabe que las máquinas van y vienen, se diseña para el fallo. Se evita almacenar datos irremplazables en un solo nodo. Se distribuye la carga. Se usan comprobaciones de salud. Se automatiza el arranque y el apagado. Se deja de asumir que una máquina estará ahí para siempre solo porque está ahí ahora.
Dónde se usa mal
La metáfora se vuelve absurda cuando se trata como una religión en lugar de una regla general. Algunos equipos usan "ganado" para excusar una disciplina operativa débil. Dicen que una máquina es reemplazable, pero el proceso para reemplazarla es en parte manual y nadie lo ha probado bajo presión. Otros equipos imponen el modelo a sistemas que no están preparados para él y luego descubren que la parte verdaderamente importante no era el nivel de aplicación sin estado, sino el estado descuidado que había debajo.
También hay un error humano escondido en la expresión. Los servidores pueden ser ganado. Las personas no. Si alguien usa la metáfora para justificar tratar al personal como intercambiable, ha entendido el patrón de infraestructura y ha perdido de vista el sentido de tener un equipo que funcione.
Ejemplos
Una aplicación interna heredada se ejecuta en una máquina virtual llamada "prod-app-01". Tiene un paquete personalizado instalado desde un repositorio hace tiempo olvidado, una tarea cron especial y una regla de firewall que nadie sabe bien explicar. Cuando la máquina llena su disco, el equipo se conecta y empieza a borrar archivos a mano. Eso es una mascota. El riesgo no es solo técnico. Es organizacional, porque la confianza vive en la memoria tribal.
Un servicio más nuevo se ejecuta en una plataforma de contenedores. La imagen del servicio se construye en un pipeline, la configuración se almacena en código y las instancias se reemplazan durante el despliegue en lugar de modificarse en producción. Si una instancia falla, el tráfico se redirige y otra arranca. Eso es ganado. La calma es precisamente el objetivo. El fallo se espera y se gestiona.
Una granja de renderizado o una plataforma de procesamiento de datos suele estar en el medio. Los nodos trabajadores son ganado porque pueden aparecer y desaparecer con la carga de trabajo. El almacenamiento compartido y la base de datos no lo son, porque guardan el estado de los trabajos y los artefactos. Los buenos equipos separan estos ciclos de vida a propósito. Los malos agitan la metáfora y solo descubren después que hicieron desechable la parte fácil y misteriosa la parte difícil.
Malentendidos frecuentes
Un malentendido es que las mascotas son siempre señal de incompetencia. No necesariamente. Muchos entornos de mascotas se construyeron bajo restricciones muy diferentes, con hardware caro, aprovisionamiento más lento y automatización más débil. El problema no es que ese pasado existiera. El problema es quedarse atrapado en él.
Otro es que el ganado significa que no importa cuando las cosas fallan. En realidad, el ganado requiere más cuidado por adelantado. Se necesitan procesos de compilación limpios, automatización probada, buena observabilidad y rutas de recuperación claras. Es disciplinado, no descuidado.
Un tercer malentendido es que todo debería ser ganado. Eso es demasiado simplista. El cómputo suele encajar bien en el patrón. Los sistemas que almacenan datos, los registros de larga duración y los componentes de red críticos necesitan un tratamiento diferente, aunque partes de la infraestructura que los rodea estén estandarizadas.
La gente también reduce la idea al nombrado. Sí, los servidores con nombre son a menudo una señal de alerta. Pero el problema no es el nombre en sí. El problema es la unicidad. Se pueden tener máquinas numeradas y gestionarlas mal igualmente.
Por último, algunos equipos creen que migrar a contenedores significa que ya han terminado. No es así. Se pueden tener contenedores mascota con la misma facilidad que máquinas virtuales mascota si los hábitos de compilación, despliegue y ejecución siguen dependiendo de excepciones manuales.
Riesgos y límites
Bien utilizada, la metáfora fomenta la resiliencia, la consistencia y una menor dependencia de héroes. Mal utilizada, se convierte en un eslogan que oculta aristas peligrosas. Reconstruir un servidor solo es seguro si el proceso de reconstrucción es completo, está probado y es rápido. Si el entorno real sigue dependiendo de pasos no documentados, el ganado son atrezo de teatro.
También hay un límite de costes. El cómputo desechable puede llevar a una expansión descuidada si nadie vigila la utilización. "Fácil de crear" puede convertirse silenciosamente en "fácil de olvidar". FinOps y la disciplina de ingeniería van de la mano aquí.
La seguridad es otro límite. Los equipos a veces imaginan que la infraestructura nueva es automáticamente más segura. Solo lo es si las imágenes base, la gestión de secretos, el parcheo y los controles de acceso son sólidos. Recrear rápidamente una configuración débil solo significa que se puede recrear debilidad a alta velocidad.
Y hay una trampa cultural. Si cada decisión técnica interesante se convierte en construir una plataforma a medida para soportar la desechabilidad, se puede acabar en una espiral de yak-shaving. Si un equipo adopta una orquestación pesada principalmente porque parece moderna, y no porque el entorno la necesite, eso se acerca al resume-driven development. La buena versión de pets vs cattle hace que las operaciones sean aburridas en el mejor sentido. La mala versión convierte la metáfora en sí misma en una razón para añadir complejidad.
Qué hacer a continuación
Empiece por encontrar sus mascotas reales. Pregunte qué máquinas o entornos la gente teme reiniciar, parchear, migrar o traspasar. Esos son los puntos de presión. Luego haga una pregunta más útil que "¿Cómo modernizamos todo?": "¿Qué necesitaríamos para recrear esto de forma segura desde cero?"
Mueva la configuración al código. Estandarice imágenes y patrones de ejecución. Reduzca el acceso remoto ad hoc. Haga que las reconstrucciones sean rutinarias, no ceremoniales. Centralice los registros y la monitorización para que el conocimiento no viva en un solo nodo.
Sea explícito sobre los límites. Decida qué capas deben ser intercambiables y cuáles necesitan una gestión cuidadosa del estado. Las copias de seguridad, los simulacros de restauración y el manejo de datos importan tanto como la automatización sin estado.
Recompense a los equipos por eliminar la unicidad frágil, no por realizar rescates. Un proceso de publicación tranquilo y una rotación de incidentes sin sobresaltos son señales de madurez en ingeniería. También lo es una plataforma que los ingenieros promedio pueden usar bien. Aquí es también donde este tema se conecta con el debate del ingeniero 10x. La mejor cultura de infraestructura no depende de héroes permanentes. Hace que los heroísmos sean raros.
¿Tiene alguna pregunta o sugerencia, o quiere entender cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Pets vs cattle solo se aplica a servidores?
No. Se aplica a cualquier recurso operativo donde la intercambiabilidad importa. La unidad puede ser un servidor, un contenedor, un nodo trabajador, un rack o un clúster.
¿Puede una base de datos ser ganado?
Las partes que la rodean pueden serlo. La capa de base de datos en sí suele necesitar un manejo más cuidadoso porque almacena estado. Las réplicas, los patrones de conmutación por error y la infraestructura circundante reconstruible pueden igualmente reducir la fragilidad.
¿Es esto solo otra forma de decir "usa la nube"?
No exactamente. Las plataformas en la nube facilitan el patrón, pero la idea real es la repetibilidad y la sustitución segura. Se pueden seguir teniendo mascotas en la nube si se gestionan los recursos a mano.
¿Por qué los ingenieros tienen tanta aversión a los servidores mascota?
Porque los servidores mascota generan miedo. El miedo ralentiza el cambio, hace que los incidentes sean estresantes y convierte el mantenimiento en trabajo de detective.
¿Son siempre malos los servidores mascota?
No. Algunos sistemas heredados o muy especializados pueden seguir siendo más parecidos a mascotas durante un tiempo. El objetivo no es la pureza. El objetivo es reducir la unicidad innecesaria donde perjudica la velocidad y la fiabilidad.
¿Cuál es la señal más sencilla de que un equipo todavía tiene mascotas?
Alguien dice: "Por favor, no toques esa máquina, solo Sam sabe cómo funciona".
¿Cómo se relaciona esto con el yak shaving?
Un equipo puede empezar con un objetivo sensato, como hacer que los entornos sean reconstruibles, y luego perderse en una cadena de tareas secundarias y desvíos de herramientas. Eso es yak shaving clásico.
¿Cómo se relaciona esto con el resume-driven development?
Si un equipo impulsa una orquestación pesada o una plataforma llamativa principalmente porque parece moderna o beneficiosa para la carrera profesional, la metáfora se está usando como cobertura para la moda en lugar de para la idoneidad.