"Versionamento? Oh, io prendo sempre l’ultima versione - cosa mai potrebbe andare storto?"
Proprio questo atteggiamento è uno dei motivi per cui alcuni ingegneri vengono svegliati alle 3 del mattino. E anche il motivo per cui la mattina successiva, durante il Daily Stand-up, tutti fissano imbarazzati le proprie scarpe.
Parliamone brevemente nell’ultima parte della nostra serie "Terraform @ Scale", prima che capiti anche a voi.
Leggi tutto: Terraform @ Scale - Parte 7: Best Practice per il versionamento dei moduli
"Al diavolo la visibilità - l’importante è che funzioni!"
È con questo atteggiamento che la maggior parte dei team di Platform Engineering si avvia verso la rovina. È come cucinare bendati in una cucina sconosciuta: per un po’ può anche andare bene, ma quando qualcosa brucia, allora brucia davvero.
E nulla è peggiore dello sguardo smarrito sui volti quando tutto prende fuoco.
Nei due capitoli precedenti il dolore delle dipendenze è stato il nostro tema principale. Oggi vediamo quali possibilità abbiamo per tirare fuori vivo un bambino che è già caduto nel pozzo.
Leggi tutto: Terraform @ Scale - Parte 6c: Dipendenze tra moduli per esperti (e masochisti)
Nell’articolo precedente abbiamo esaminato la complessità nascosta dei moduli annidati e il cosiddetto Ripple-Effect, rendendoci progressivamente conto delle spiacevoli conseguenze che ciò può avere nell’esercizio operativo e nel lifecycle management. A tali problemi si può spalancare la porta commettendo errori da principianti - soprattutto quello di infilare più moduli, o addirittura tutti i moduli Terraform, in un unico repository Git. Con un po’ di seniority e una pianificazione accurata, tuttavia, è possibile minimizzare questi problemi sin dall’inizio.
In questa parte vedremo in pratica come affrontare tali dipendenze senza che i dolori prendano il sopravvento.
Leggi tutto: Terraform @ Scale - Parte 6b: Gestione pratica dei moduli annidati
Quando un singolo aggiornamento di un modulo blocca 47 team...
È lunedì mattina, ore 10:30. Il team di Platform Engineering di un grande fornitore di Managed Cloud Services ha appena rilasciato un "innocuo" aggiornamento del modulo di base per le istanze VM dalla versione v1.3.2 alla v1.4.0. La modifica? Un nuovo, ma obbligatorio Freeform-Tag per l’assegnazione dei costi alle risorse.
Ciò che nessuno aveva previsto: il Senior Engineer che un tempo, come decision maker, aveva insistito con forza affinché tutti i moduli Terraform venissero archiviati in un unico repository Git. “La versioning è troppo micromanagement. Così è più ordinato. E richiede meno lavoro”, aveva detto allora.
Lo stesso lunedì, ore 15:00: 47 team di clienti diversi segnalano che le loro pipeline CI/CD falliscono. Il motivo? I loro Root-Module fanno riferimento ai moduli aggiornati forniti dal provider, ma nessuno ha implementato i nuovi parametri nei propri Root-Module. Il controllo di conformità del provider è attivo e respinge i Terraform-Runs a causa dei tag obbligatori mancanti. Ciò che era stato pianificato come un miglioramento si è trasformato in un blocco organizzativo su larga scala con un impatto esterno massiccio sui clienti di hosting.
Benvenuti nel mondo delle dipendenze tra moduli in Terraform @ Scale.
Leggi tutto: Terraform @ Scale - Parte 6a: Comprendere e gestire i moduli annidati
Nel precedente articolo 5a abbiamo visto quanto rapidamente i grandi rollout con Terraform possano scontrarsi con i limiti API, ad esempio quando i test di disaster recovery creano centinaia di risorse in parallelo e gli errori 429 scatenano una valanga di retry. Questa continuazione riprende da lì e mostra come, con l’API Gateway di Oracle Cloud Infrastructure e Amazon API Gateway, sia possibile gestire consapevolmente i limiti, osservarli in maniera pulita e renderli operativamente solidi tramite “Policy as Code”.