Infrastructure as Code (IaC): cos’è?

Infrastructure as Code (IaC)

Infrastructure as Code (IaC): concetti base, confronto tra le tecnologie più usate (CloudFormation, CDK e Terraform) e i motivi per cui un’azienda dovrebbe scegliere questo approccio per lo sviluppo e la manutenzione della propria infrastruttura su AWS.

 

Prima di approfondire l’Infrastructure as Code (IaC) è importante sottolineare che quando un’azienda si approccia al voler utilizzare l’infrastruttura AWS, gli scenari più comuni sono principalmente due:

  • 1. l’azienda potrebbe voler migrare interamente o parte dei propri servizi esistenti gestiti in quel momento on premise;
  • 2. l’azienda preferisce partire da zero con un nuovo progetto direttamente sul Cloud.

Possono sembrare casi completamente diversi, ma in entrambi ci sono spesso valide ragioni per le quali l’azienda potrebbe avere la necessità di terminare la propria transizione in tempi stretti: un contratto in scadenza presso il datacenter attuale, dei limiti tecnici dell’infrastruttura on premise che non permettono all’azienda di operare pienamente, una startup che ha bisogno di lanciare il proprio prodotto per potersi rendere fruibile dai propri clienti e molto altro.

IaC: come individuare l’approccio migliore

Spesso si rischia di farsi prendere dalla fretta e scegliere un approccio manuale che può sembrare inizialmente più semplice e veloce. Il problema di questo approccio è la facilità con cui si può perdere traccia delle modifiche fatte in fase di configurazione e fine tuning. Questo può comportare varie problematiche. Nel breve periodo, ad esempio, il non riuscire a replicare interamente l’ambiente di test su quello di produzione ritrovandosi problemi inaspettati a ridosso delle scadenze di go-live/migrazione. Oppure a lungo andare la difficoltà di manutenzione dell’infrastruttura in quanto il personale tecnico, potenzialmente diverso nel tempo, non avrà tutte le indicazioni necessarie per poter operare.

Per ridurre e/o risolvere queste problematiche l’approccio migliore è definire dei template di codice per la propria infrastruttura, tramite tecnologie come AWS CloudFormation, AWS CDK (Cloud Development Kit) e Terraform.
Con l’Infrastructure As Code (IaC) quindi intendiamo la definizione dell’infrastruttura tramite dei file con linguaggi e sintassi specifici che permettono un approccio programmatico alla gestione dei servizi Cloud.
Sono tecnologie diverse tra loro e non è oggetto di questa discussione andarle ad approfondire tutte, ma è utile vedere brevemente le loro caratteristiche principali.

AWS CloudFormation

CloudFormation è a tutti gli effetti un servizio AWS, ed il primo riguardo IaC in linea temporale, e può quindi essere visitato sulla console. Il funzionamento si basa sulla definizione di file scritti in linguaggio JSON o YAML con una sintassi ben precisa, che vengono poi caricati manualmente sulla console oppure automaticamente tramite delle pipeline apposite di CI/CD (Continuous Integration e Continuous Delivery). Di seguito un esempio di istanza EC2 in CloudFormation, utilizzando il linguaggio YAML. I campi dati inseriti sono stringhe, oppure riferimenti a variabili dichiarate precedentemente e la formattazione ha una struttura molto rigida.

un esempio di istanza EC2 in CloudFormation, utilizzando il linguaggio YAML

AWS Cloud Development Kit (CDK)

AWS CDK è un sistema di templetizzazione costruito ad un livello più alto di CloudFormation e che permette l’utilizzo dei linguaggi di programmazione più diffusi tra gli sviluppatori come Javascript, Typescript, Python, Go, Java ed altri ancora.
Un progetto CDK ha una struttura ben definita, che facilita la suddivisione dell’infrastruttura in più aree di interesse. Di seguito un esempio di istanza EC2 in CDK, utilizzando il linguaggio TypeScript. Le variabili possono essere di qualsiasi tipo permesso dal linguaggio, oppure provenire da stack differenti che sono stati importati.

un esempio di istanza EC2 in CDK, utilizzando il linguaggio TypeScript

Terraform

Terraform è un progetto open source, inizialmente sviluppato da HashiCorp.
É una tecnologia molto matura, che permette la definizione delle risorse infrastrutturali tramite un linguaggio di programmazione appositamente sviluppato chiamato HCL (HashiCorp Configuration Language) con una struttura simile al JSON, che è agnostico rispetto al Cloud Provider scelto. Di seguito un esempio di istanza EC2 in Terraform, utilizzando il linguaggio HCL. Anche qui le variabili possono essere dichiarate in altri moduli o parti del codice e poi importate.

un esempio di istanza EC2 in Terraform, utilizzando il linguaggio HCL

Costi

Riguardo l’argomento costi questi approcci non comportano una spesa diretta, nel senso che non si pagano le operazioni di deploy, ma richiedono chiaramente di pagare per le risorse che verranno create tramite i template IaC secondo le tariffe standard di quei servizi espresse da AWS.

I vantaggi dell’approccio IaC

Qualunque sia la tecnologia scelta si potranno ottenere dei template uniformi, replicabili, versionati e testabili. Tutti gli approcci permettono il riuso del codice, così che si possa anche risparmiare tempo per non dover reinventare la ruota ed usare componenti magari provenienti da altri progetti precedenti dell’azienda, ma che con poche modifiche possono essere adattati, riducendo ampiamente i tempi di sviluppo e gli errori umani.
Ad esempio questo significa che se in un progetto l’ambiente di test è stato ben definito e templetizzato si può passare al rilascio e quindi alla creazione dell’ambiente di produzione in rapidità, con la sicurezza che le configurazioni codificate verranno replicate sul nuovo ambiente.

Precisiamo che con il termine ambiente possiamo intendere sia un’infrastruttura che contiene tutte le risorse in un unico account, sia un progetto che è diviso su più account AWS. Il valore aggiunto della replicazione delle configurazioni che viene dato dall’utilizzo dell’approccio IaC persiste, in quanto semplicemente il template IaC verrà configurato con tutti gli account sui quali dovrà essere rilasciato.

Problematiche dell’approccio IaC

Ovviamente il rilascio di un progetto è solo l’inizio del suo percorso. La manutenzione dell’infrastruttura è spesso dove l’approccio manuale inizia a mostrare i propri difetti in quanto diventa sempre più difficile applicare le modifiche che si rendono necessarie nel tempo. I motivi possono essere i più disparati: dal cambio di personale tecnico che si occupa del progetto alla scarsa documentazione realizzata per tenere traccia delle modifiche fatte manualmente, o magari più semplicemente, una mancanza di competenze approfondite.

Ci possono comunque essere delle problematiche nello scegliere di utilizzare un approccio Infrastructure as Code (IaC). In primo luogo la dipendenza dal codice, che comporta la necessità di avere almeno una figura di riferimento all’interno dell’azienda con le competenze per poter operare le modifiche sul template che si renderanno necessarie nel tempo.
Come secondo aspetto è bene tenere a mente che ci sarà una porzione di tempo iniziale in cui lo sviluppo potrebbe essere più lento rispetto ad un approccio manuale, in quanto il personale dovrà acquisire le competenze necessarie e tracciare le configurazioni che dovranno essere templetizzate.

Quando pensiamo a tutti gli steps necessari al rilascio di un’applicazione, essere in grado di operare con rapidità ed automazioni è la chiave per garantire un rilascio veloce e di successo. La stessa mentalità deve essere applicata all’infrastruttura che sorregge tale applicazione, in quanto è chiaramente una parte fondamentale che però spesso si tende a vedere più distaccata ed in sottofondo.

Vale la pena affrontare i punti critici di un approccio IaC in quanto i benefici sono decisamente maggiori: la possibilità di versionamento dei template infrastrutturali, il poter collaborare e riusare il codice prodotto con i comuni strumenti usati dagli sviluppatori, automatizzare task complessi riducendo gli errori umani, e facilitare la manutenzione e gli aggiornamenti dei vari ambienti in uso.

IaC: trend di crescita

Dati i trend di crescita del Cloud, in futuro possiamo aspettarci che gli strumenti di IaC assumeranno sempre più importanza, sia per ambienti puramente Cloud, sia per soluzioni ibride in cui le aziende vogliono integrare la propria infrastruttura privata con il provider scelto.
Che si tratti di una multinazionale oppure di una startup, ogni azienda che ha intenzione di spostare la propria infrastruttura sul Cloud ha la possibilità di beneficiare enormemente dall’utilizzo di un approccio IaC.

Non perdere i prossimi articoli dove parleremo degli approcci dell’Infrastructure as Code (IaC) con riferimento al mondo AWS.

Per ricevere aggiornamenti su questi temi contattateci all’indirizzo hello@zero12.it, oppure seguite i nostri canali social per restare informati sulle prossime pubblicazioni!

Ciao 🙂

 

Se vuoi approfondire il Cloud Development Kit attraverso un esempio pratico clicca qui per leggere l’articolo

Alessandro Dindinelli

AWS Specialist zero12 – Var Group Company

 

 

0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Sentitevi liberi di contribuire!

Lascia un commento