Un confronto tra idempotenza e immutabilità

Molti in DevOps applicano la mentalità del bestiame non animali domestici implementando infrastrutture immutabili e ridistribuendo quando sono necessarie modifiche (anziché modificarle).

La gestione della configurazione ha un principio simile di idempotenza . Quali sono i vantaggi comparativi, le somiglianze e gli svantaggi dell'immutabilità rispetto all'impotenza e quale è più efficiente? Possono essere utilizzati in modo sinergico (ad es. Eliminazione periodica e ridistribuzione di VM o contenitori Docker mediante la gestione della configurazione?)

I due termini sono molto diversi.

Cominciamo con immutability, che significa letteralmente "nessuna mutazione" o "nessun cambiamento". Nel senso di DevOps, significa che una volta che hai creato un artefatto, che si tratti di un'immagine contenitore, di un'immagine VM, o forse di un pacchetto dal codice compilato, dichiari che non lo cambierai mai. Spesso, se sono necessarie modifiche, si dichiara che verrà invece creata una nuova versione di "cosa".

Il termine idempotenceindica che quando le modifiche vengono applicate più volte, lo stato viene modificato (modificato) una sola volta . In primo luogo, presuppone già che verranno applicate delle modifiche, il che significa che non è possibile avere qualcosa di immutabile e di avere azioni idempotenti (non vengono eseguite azioni mediante contratto).

Nell'uso degli strumenti di gestione della configurazione, idempotenceviene utilizzato in alcuni casi quando si applica la stessa modifica più volte. Come aggiungere la riga che dice localhostal /etc/hostsfile, non hai davvero bisogno di più di queste righe e se ne esiste già una è sicuro non provare ad aggiungere di nuovo.

Inoltre idempotentè un termine usato per descrivere le azioni che tentano di cambiare le cose, mentre immutableè usato per descrivere i nomi (oggetti) che si contrappongono ai cambiamenti fatti a loro.

Perché un immutableoggetto è utile? Perché quando lo copi, ad esempio da un ambiente di sviluppo a qa in produzione. Sai già abbastanza (ma non tutto) riguardo a come si comporterà. In molti casi, le parti che lavorano saranno coerenti e anche le parti rotte saranno coerenti.

Perché le idempotentazioni sono utili? Perché quando si desidera modificare uno stato di un oggetto, in molti casi è utile verificare solo che la modifica sia stata applicata e applicare le modifiche nel caso sia necessario. Ad esempio, quando un elemento di configurazione in un file manca o ha un valore errato, è utile aggiungerlo solo una volta o modificarlo una sola volta mentre si applica l'azione più volte. In molti altri casi, come i file di registro , non si desidera eseguire azioni idempotenti perché spesso si desidera aggiungere un'altra riga ogni volta che si verifica un evento.

Un'infrastruttura immutabile è, secondo me, un modello diverso da Gestione della configurazione. Sebbene possano essere usati insieme, affrontano i problemi per natura in due modi diversi.

Il concetto di manufatti immutabili ha una lunga storia, i sistemi Unix li usano da decenni per distribuire pacchetti software. Ma una volta distribuiti, i file di configurazione sono stati cambiati e le cose sono diventate mutabili. Idempotency fornisce alcune belle garanzie con i file mutabili, possiamo sapere quando le cose sono cambiate e aggiornare solo le cose che devono essere aggiornate. Tuttavia, non risolve tutti i problemi degli oggetti mutabili, dobbiamo ancora soddisfare un numero apparentemente infinito di casi limite. Poiché le cose sono mutabili e noi siamo idempotenti, dobbiamo prima stabilire quali cambiamenti devono essere fatti, quindi eseguirli generalmente in un ordine molto specifico. Quando si distribuiscono pacchetti software, in particolare con zero tempi di inattività, è necessario orchestrare attentamente le modifiche per evitare che vengano eliminate eventuali richieste.

Questa complessità alla fine può essere evitata distribuendo artefatti immutabili invece di mutarli sul posto, perché semplicemente sostituiamo un oggetto con un altro (che sia un binario, un contenitore o una macchina virtuale), lo mettiamo in servizio e ritiriamo quello vecchio . Questo è solo un esempio di una distribuzione zero dei tempi di fermo.

Con i progressi negli strumenti per permetterci di distribuire manufatti immutabili su migliaia di sistemi in un tempo molto breve stiamo vedendo l'uso di strumenti immutabili per gestire i sistemi molto più fattibili della gestione della configurazione. Tuttavia, gli strumenti non sono ancora presenti e c'è ancora un caso d'uso per entrambi. Ho fatto un discorso su questo argomento che spiega la progressione lineare da completamente mutabile a completamente immutabile, è uno spettro e ogni azienda sceglierà dove si adatta meglio a loro.