Creare applicazioni cloud native è l’approccio più evoluto che garantisce alle applicazioni di essere – per costruzione – portabili, scalabili ed estremamente agili nel proprio ciclo di vita. Dal punto di vista applicativo, questo approccio si declina sia in scelte tecnologiche (tra cui l’uso dei container e delle API per il provisioning dei servizi) sia di metodologia, con l’adozione delle pratiche di devOps. Se applichi questa metodologia, che garantisce agilità, velocità, sicurezza e grande controllo del software, anche le architetture che lo ospitano devono essere allo stesso modo robuste, flessibili ed estremamente dinamiche. Ecco che, così come il software è codice testato e rilasciato frequentemente con il sistema di versionamento, allo stesso modo l’infrastruttura che lo ospita deve essere costruita e aggiornata tramite lo stack di Infrastructure as Code (IaC), a prescindere dal Cloud provider utilizzato e dal linguaggio di IaC scelto. Certo, non esiste un solo tipo di cloud, ma il confronto tra i provider (o addirittura tra i paradigmi public vs hybrid cloud) non è il tema di questo articolo. Al contrario, è però importante sottolineare che anche la scelta del tool di Infrastructure as Code non è un dettaglio trascurabile.
Infrastructure as Code: dall’approccio dichiarativo a quello imperativo
Le prime soluzioni di Infrastructure as Code sposavano quasi tutte un approccio dichiarativo in cui viene definito uno stato del sistema tramite l’elenco di tutte le risorse e le proprietà desiderate, come AWS CloudFormation (specifico naturalmente per i servizi AWS) o il più diffuso Terraform (molto vantaggioso perché capace di gestire più piattaforme Cloud). Una sorta di lista della spesa di tutto ciò che la nostra infrastruttura deve contenere. Il trend si è sempre più spostato verso l’approccio imperativo o procedurale in cui si può definire dinamicamente come configurare il risultato.
In realtà, citando l’esperienza aziendale, il vero vantaggio è di fatto un approccio misto o, se vogliamo, di astrazione. Si può utilizzare, con grandi benefici, AWS CDK: il Cloud Development Kit di AWS è un framework che supporta numerosi linguaggi di programmazione (molto usato Python) con cui gli sviluppatori possono letteralmente creare architetture come se fossero pezzi di applicazione. Di fatto, si creano in maniera procedurale delle sintassi dichiarative di CloudFormation per costruire un’architettura usando solo codice python. Il nascente CDK for Terraform ripara da ogni rischio di lock-in verso AWS come unico cloud provider, permettendo al contempo di sfruttare al massimo le potenzialità di tutti i servizi AWS che ben si prestano all’hosting delle più avanzate applicazioni.
Perché adottare l’Infrastructure as Code
Il primo vantaggio di utilizzare la IaC è la replicabilità dell’architettura, sia per distribuirla – anche adattandola – su più ambienti della pipeline, sia per riproporla in altri use case simili. Sfruttando i costrutti, una delle principali funzionalità di CDK (ovvero moduli componibili e riutilizzabili) è possibile creare degli stack templates in un’ampia libreria IaC interna, in continuo aggiornamento. Tutte le infrastrutture replicabili, a partire dal core standard degli applicativi, possono essere a disposizione del team di delivery per la creazione di architetture robuste con grande agilità.
Il secondo grande vantaggio è che nell’ambiente cloud nulla viene più gestito manualmente: oltre a risparmiare tempo, in questo modo si riducono al massimo gli errori e i rischi di sicurezza. Il totale approccio devOps + IaC può permettere di mantenere distinti gli spazi di responsabilità: nessun developer avrà accesso all’ambiente di produzione di un tenant cloud dedicato a un progetto. In questo modo, l’architettura è creata con IaC e il software è rilasciato dalle pipeline di CI/CD (Continuos Integration / Continuos Delivery).
Il fatto che la stessa infrastruttura sia codice versionato, testato e documentato, fa sì che ogni esigenza di scalabilità, sicurezza o upgrade architetturale sia gestibile come una nuova funzionalità dell’applicazione. E se creare l’infrastruttura è come sviluppare un software (anche in termini pratici, significa scrivere codice) allora le competenze dei team si fondono: un cloud architect e un full stack developer si uniscono, le barriere tra i team scompaiono e il rilascio dell’applicazione è più rapido ed efficiente.
Conclusioni
L’Infrastructure as Code (IaC) è ormai lo standard de facto per la creazione e il mantenimento di architetture solide nel mondo delle applicazioni digitali evolute. Molte aziende, ormai, stanno adottando IaC e possono testimoniare non solo un incredibile boost in termini di efficienza e di replicabilità delle soluzioni, ma anche a livello di qualità e sicurezza, con un beneficio sostanziale nella collaborazione tra team e nello sviluppo di competenze interne.
