"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”.
Sono le 14:30 di un normale martedì pomeriggio. Il team DevOps di un fornitore di servizi finanziari svizzero avvia come di consueto la propria pipeline Terraform per il test mensile di Disaster Recovery. 300 macchine virtuali, 150 backend di load balancer, 500 record DNS e innumerevoli regole di rete devono essere provisionati nella regione di backup.
Dopo 5 minuti, la pipeline si interrompe. HTTP 429: Too Many Requests.
Le successive 3 ore vengono spese dal team per ripulire manualmente le risorse parzialmente provisionate, mentre il management guarda nervosamente l’orologio.
Il test di DR è fallito prima ancora di iniziare.
Leggi tutto: Terraform @ Scale - Parte 5a: comprendere gli API Limits
Altri articoli …
- La bomba dei certificati è innescata: la scadenza dei 200 giorni minaccia il Suo core business!
- Terraform @ Scale - Parte 4b: Best Practices per Data Sources scalabili
- Terraform @ Scale - Parte 4a: le Data Sources sono pericolose!
- Terraform @ Scale - Parte 3c: Monitoraggio e allerta per eventi di Blast Radius
