Salta al contenuto

Cosa significa pets vs cattle nella gestione dei server?

Analogia che distingue i server unici, curati a mano quando si guastano (pets), da quelli identici creati in automatico e sostituiti al primo guasto (cattle).

Pets vs cattle (animali da compagnia contro bestiame) è l'analogia che distingue due modi di gestire i server. Un pet è un server unico, con un nome proprio, configurato a mano: quando si ammala qualcuno lo cura, perché nessun altro potrebbe prenderne il posto. Il cattle, il bestiame, è un gruppo di server identici, costruiti da procedure automatiche e numerati invece che battezzati: quando uno si guasta non lo si ripara, lo si spegne e lo si sostituisce con una copia nuova, mentre il servizio continua sugli altri. La differenza non sta nell'hardware ma nell'atteggiamento: un server è bestiame se si può distruggere e ricreare in qualsiasi momento senza che nessuno se ne accorga; è un animale da compagnia se è insostituibile e non deve mai fermarsi. L'analogia è diventata un modo rapido per spiegare cosa cambia con il cloud a chi decide, e per chiedersi quali sistemi dell'azienda dipendono ancora da cure individuali.

Leggi anche: Infrastructure as Code (IaC) · Descrivere server, reti e servizi cloud in file di codice versionato invece che configurarli a mano, così l'infrastruttura si crea e ricrea in modo riproducibile.

Da dove viene l'analogia

L'immagine non nasce nel cloud. Randy Bias, di Cloudscaling, ha raccontato nella sua ricostruzione del 2016 di averla trovata nel 2011 o nel 2012 in una presentazione di Bill Baker, ingegnere di Microsoft, sulla scalabilità di SQL Server, dove la usava per contrapporre più macchine affiancate a una sola sempre più potente. Bias l'ha portata nel cloud e ha messo l'accento sulla sostituibilità: nelle sue slide del febbraio 2012, che indicano Baker come fonte, l'animale da compagnia si chiama garfield.company.com e il bestiame web001.company.com. Il capitolo sull'automazione del libro di Google del 2016 sulla Site Reliability Engineering la cita in una nota.

Cosa serve per passare al bestiame

Servono due condizioni. La prima è l'automazione: un server che si ricrea solo a memoria non è sostituibile, quindi il passaggio va di pari passo con l'infrastructure as code e spesso con i container. La seconda è un'architettura senza stato locale (stateless): il server non conserva nulla di insostituibile, perché dati e sessioni stanno altrove. Il manifesto Twelve-Factor App ne fa due regole: processi stateless e disposability, cioè processi che si avviano o si fermano in un attimo e reggono uno spegnimento improvviso. I sistemi che custodiscono dati restano il caso difficile. Bias precisa che un archivio di dati progettato per reggere i guasti, multi-master (più nodi accettano scritture) e su più di due nodi, come un cluster Cassandra, può essere bestiame, mentre il classico database primario con una replica passiva resta un animale da compagnia: lì servono backup e prove di ripristino.

Un esempio enterprise

Un distributore di trecento dipendenti ha il portale clienti su quattro server identici e il gestionale su una sola macchina fisica, con una licenza legata a quell'hardware e una configurazione che conosce solo il sistemista che l'ha montata. Se cade un server del portale, la procedura automatica ne crea uno nuovo e i clienti non se ne accorgono. Se cade il gestionale, l'azienda si ferma finché quella persona non lo rimette in piedi. La strada sensata non è trasformare tutto in bestiame: è riconoscere il gestionale come animale da compagnia, documentarne la ricostruzione, verificare con il fornitore se la licenza ne consente lo spostamento e provare il ripristino, come prevede un piano di disaster recovery.

Perché conta per chi decide

La domanda utile è quali macchine sono ancora animali da compagnia: di solito i sistemi legacy, i server singoli vincolati a una licenza, i database configurati a mano, le macchine che "è meglio non toccare". Ognuno ha due costi nascosti: un tempo di ripristino affidato a una riparazione manuale e il rischio legato a una persona chiave, l'unica che conosce la configurazione. Passare al bestiame costa automazione e a volte una riprogettazione, quindi conviene partire da dove un guasto pesa di più. Per ciò che resta animale da compagnia, la scelta onesta è dichiararlo e misurarne davvero il tempo di ripristino.

  • Infrastructure as Code (IaC) · Descrivere server, reti e servizi cloud in file di codice versionato invece che configurarli a mano, così l'infrastruttura si crea e ricrea in modo riproducibile.
  • Docker · Docker impacchetta un'applicazione con librerie, configurazioni e programmi di supporto in un container, che si avvia identico su qualsiasi computer o server.
  • CI/CD · Continuous Integration e Continuous Delivery: ogni modifica al software viene testata e portata in produzione in modo automatico e frequente.
  • Business continuity vs disaster recovery · La continuità operativa tiene in piedi l'attività durante l'incidente, il disaster recovery rimette in piedi i sistemi dopo.
  • Sistema legacy · Un'applicazione ancora critica e difficile da cambiare: stack obsoleto, competenze rare, senza supporto del fornitore.

Vedi nell'universo

Se l'AI ti serve in produzione, non in una demo, è il mio lavoro.

VEDI INTEGRAZIONI AI

Oppure scrivimi.