In­fra­struc­tu­re as Code (IaC): gestione di un'in­fra­strut­tu­ra IT tramite codice

Per quanto riguarda le in­fra­strut­tu­re IT è quasi ine­vi­ta­bi­le ricorrere a hardware vir­tua­liz­za­ti che possono essere gestiti tramite software. Le risorse di ar­chi­via­zio­ne, server e rete, o anche interi data center, possono essere as­sem­bla­ti con pre­ci­sio­ne e scalati in qualsiasi momento senza la necessità di un accesso manuale ai ri­spet­ti­vi di­spo­si­ti­vi. Grazie ai fornitori di In­fra­struc­tu­re as a Service, l'hard­ware sot­to­stan­te, definito dal software, può anche essere no­leg­gia­to a basso costo, rendendo l'in­fra­strut­tu­ra interna com­ple­ta­men­te superflua.

La gestione delle varie risorse rimane comunque im­pe­gna­ti­va, so­prat­tut­to a causa del crescente numero di esigenze che le in­fra­strut­tu­re IT devono sod­di­sfa­re e del fatto che i servizi di diversi fornitori IaaS sono spesso uti­liz­za­ti con­tem­po­ra­nea­men­te. Il principio "In­fra­struc­tu­re as Code", noto anche come "in­fra­strut­tu­ra pro­gram­ma­bi­le", sta di­ven­tan­do sempre più im­por­tan­te.

L'In­fra­struc­tu­re as Code, o IaC, è un paradigma IT che definisce in lin­guag­gio in­for­ma­ti­co non soltanto il software stesso, ma anche l'in­fra­strut­tu­ra ne­ces­sa­ria per il suo fun­zio­na­men­to, come lo spazio di ar­chi­via­zio­ne, la potenza di calcolo o le risorse di rete. In linea di principio, si tratta di pro­gram­ma­re anche strutture hardware come codice ese­gui­bi­le, che può essere fa­cil­men­te adattato, duplicato, can­cel­la­to e “ver­sio­na­to” in qualsiasi momento. Il concetto di In­fra­struc­tu­re as Code si basa su moderne tec­no­lo­gie cloud come la vir­tua­liz­za­zio­ne e la gestione delle risorse definite tramite software, che con­sen­to­no la gestione del­l'hard­ware senza accesso manuale ai di­spo­si­ti­vi sot­to­stan­ti.

Il numero di requisiti che i prodotti software devono sod­di­sfa­re è cresciuto ra­pi­da­men­te negli ultimi anni, com­por­tan­do, ad esempio, cicli di sviluppo sempre più brevi e una ricerca della massima di­spo­ni­bi­li­tà e fles­si­bi­li­tà. Oltre allo sviluppo ot­ti­miz­za­to del codice, sono fon­da­men­ta­li per una struttura com­ples­si­va di successo, che sia stabile e, so­prat­tut­to, com­pe­ti­ti­va, il mi­glio­ra­men­to continuo e la ma­nu­ten­zio­ne intensiva del­l'in­fra­strut­tu­ra hardware sot­to­stan­te. È qui che entra in gioco l'In­fra­struc­tu­re as Code, perché l'o­biet­ti­vo dell’"in­fra­strut­tu­ra pro­gram­ma­bi­le" è proprio quello di aumentare la qualità e l'ef­fi­cien­za delle in­fra­strut­tu­re. Alcuni obiettivi e i compiti fon­da­men­ta­li dell'IaC sono i seguenti:

• au­to­ma­tiz­za­re i processi manuali il più possibile;
• abbattere i confini tra le ap­pli­ca­zio­ni e gli ambienti in cui vengono eseguite;
• creare un flusso di lavoro fles­si­bi­le che sem­pli­fi­chi la col­la­bo­ra­zio­ne a livello aziendale per tutte le persone coinvolte nel processo di sviluppo;
• rendere i movimenti di contenuti e le modifiche tra­spa­ren­ti e com­pren­si­bi­li in qualsiasi momento;
• rendere le con­fi­gu­ra­zio­ni hardware "testabili" come quelle software.

Nell'ambiente classico, non vir­tua­liz­za­to, tutte le risorse sono sempre legate di­ret­ta­men­te al­l'hard­ware fisico, il che non solo si traduce in un'in­fra­strut­tu­ra meno fles­si­bi­le, ma comporta anche un notevole lavoro manuale per eventuali modifiche alla con­fi­gu­ra­zio­ne.

Con la vir­tua­liz­za­zio­ne del­l'hard­ware dei server, dello storage e delle strutture di rete, questa si­tua­zio­ne è cambiata in modo si­gni­fi­ca­ti­vo: questa tec­no­lo­gia consente ai fornitori di offrire ai clienti risorse scalabili a livello centrale senza dover assegnare hardware dedicati. Da un lato, ciò ga­ran­ti­sce un'af­fi­da­bi­li­tà no­te­vol­men­te superiore, in quanto un hardware difettoso può, ad esempio, essere so­sti­tui­to im­me­dia­ta­men­te. D'altro canto, è molto più facile per entrambe le parti ag­giun­ge­re nuove risorse o ridurre le risorse già no­leg­gia­te.

Gli ambienti definiti da software (software defined) vanno oltre le normali in­fra­strut­tu­re vir­tua­liz­za­te. Queste sono, infatti, ca­rat­te­riz­za­te dal fatto che la logica di controllo è com­ple­ta­men­te astratta dai singoli com­po­nen­ti hardware e im­ple­men­ta­ta in un software di controllo centrale. Fornitori e clienti possono con­trol­la­re fa­cil­men­te questa unità di controllo grazie alle in­ter­fac­ce e agli strumenti appositi e as­sem­bla­re e scalare in­di­vi­dual­men­te le strutture IT. Entrambe le parti be­ne­fi­cia­no, inoltre, del­l'au­men­to delle pre­sta­zio­ni del­l'hard­ware, dato che non è re­spon­sa­bi­le del­l'e­la­bo­ra­zio­ne dei dati.

L'In­fra­struc­tu­re as Code utilizza le suddette tecniche au­to­ma­tiz­zan­do la gestione con­trol­la­ta da software delle ri­spet­ti­ve risorse vir­tua­liz­za­te per sfruttare al meglio le po­ten­zia­li­tà del cloud. L'IaC non va, pertanto, inteso come un'al­ter­na­ti­va, ma come un'in­te­gra­zio­ne o ot­ti­miz­za­zio­ne del­l'in­fra­strut­tu­ra definita da software.

L'In­fra­struc­tu­re as Code con­tri­bui­sce in modo decisivo a sod­di­sfa­re le esigenze di uno sviluppo agile del software. Grazie a script pre­con­fi­gu­ra­ti, le ne­ces­sa­rie modifiche al­l'in­fra­strut­tu­ra vengono eseguite a una velocità che non si può rag­giun­ge­re con l'am­mi­ni­stra­zio­ne manuale. Non importa se gli adat­ta­men­ti devono essere ef­fet­tua­ti nel cuore della notte, nel fine settimana o durante giorni festivi. Anche il po­ten­zia­le di errori di­mi­nui­sce, so­prat­tut­to nelle fasi am­mi­ni­stra­ti­ve molto ri­pe­ti­ti­ve, perché vengono evitati gli errori di im­mis­sio­ne e di battitura. Oltre al­l'e­le­va­ta velocità e al basso tasso di errori, l'In­fra­struc­tu­re as Code offre i seguenti vantaggi rispetto al­l'am­mi­ni­stra­zio­ne manuale:

• Ef­fi­cien­za elevata: l'IaC offre la pos­si­bi­li­tà di au­to­ma­tiz­za­re la maggior parte della gestione delle risorse, con­tri­buen­do in modo decisivo al­l'ot­ti­miz­za­zio­ne del Software De­ve­lo­p­ment Life Cycle (SDLC), ovvero l'intero processo di sviluppo.
   
• Riu­ti­liz­za­bi­li­tà: una volta che il codice è stato scritto per un'in­fra­strut­tu­ra, può essere eseguito infinite volte e in qualsiasi momento. Lo stesso vale, ad esempio, per gli ambienti sandbox durante la fase di sviluppo.
   
• Gestione delle versioni: dove c'è il codice, è possibile anche la gestione delle versioni, con­sen­ten­do al­l'In­fra­struc­tu­re as Code di do­cu­men­ta­re e tenere traccia delle modifiche apportate. Uno dei vantaggi di questo è che una con­fi­gu­ra­zio­ne pre­ce­den­te può essere ri­pri­sti­na­ta senza problemi.
   
• Mi­ni­miz­za­zio­ne dei costi/oneri: l'au­to­ma­zio­ne della gestione del­l'in­fra­strut­tu­ra consente di ri­spar­mia­re molto tempo e denaro che possono essere investiti in altri settori.

Que­st'ul­ti­mo vantaggio relativo al risparmio di tempo e costi non è, tuttavia, privo di limiti. In un ambiente In­fra­struc­tu­re as Code ben pro­gram­ma­to è cer­ta­men­te vero, ma non bisogna tra­scu­ra­re gli sforzi legati alla pro­get­ta­zio­ne e alla rea­liz­za­zio­ne: per molti am­mi­ni­stra­to­ri re­spon­sa­bi­li, il modello IaC rap­pre­sen­ta un grande cam­bia­men­to, perché senza una com­pren­sio­ne completa dei concetti del­l'ar­chi­tet­tu­ra cloud e senza com­pe­ten­ze in linguaggi di pro­gram­ma­zio­ne come Java, Node.js, Python, ecc. e nell'utilizzo di API, è difficile passare a un'in­fra­strut­tu­ra au­to­ma­tiz­za­ta o alla sua im­ple­men­ta­zio­ne. So­prat­tut­to al­l'i­ni­zio, si devono pre­ven­ti­va­re costi re­la­ti­va­men­te alti e un elevato impegno per la for­ma­zio­ne.

Già al­l'i­ni­zio è stato sot­to­li­nea­to che le imprese si affidano, nella maggior parte dei casi, ai servizi di diversi fornitori IaaS. Di con­se­guen­za, gli am­mi­ni­stra­to­ri devono con­fron­tar­si con le ca­rat­te­ri­sti­che e, so­prat­tut­to, con le diverse in­ter­fac­ce delle ri­spet­ti­ve piat­ta­for­me. In al­ter­na­ti­va, speciali strumenti o framework IaC offrono i propri linguaggi di con­fi­gu­ra­zio­ne, che con­sen­to­no la gestione cross-vendor delle risorse e rendono superflua la co­no­scen­za precisa delle API uti­liz­za­te. Alcune delle soluzioni più popolari sono:

• Terraform: Terraform è una soluzione open source svi­lup­pa­ta da HashiCrop, la cui versione base può essere scaricata e uti­liz­za­ta gra­tui­ta­men­te. Le due versioni a pagamento offrono fun­zio­na­li­tà per le strutture, l'or­ga­niz­za­zio­ne e il lavoro in team.
   
• AWS Clou­d­For­ma­tion: Clou­d­For­ma­tion è lo strumento IaC interno di Amazon Web Services (AWS) e come tale è pra­ti­ca­men­te in­di­spen­sa­bi­le per tutti coloro che lavorano con prodotti AWS come ELB, S3 o EFS. Non ci sono costi ag­giun­ti­vi per l'uso, quindi gli utenti pagano solo per le risorse che prenotano.
   
• Google Cloud De­ploy­ment Manager: il De­ploy­ment Manager è per la piat­ta­for­ma cloud di Google quello che Clou­d­For­ma­tion è per AWS. Chi ricorre quindi alle risorse IaaS di Google può gestirle co­mo­da­men­te con lo strumento gratuito tramite file di con­fi­gu­ra­zio­ne centrali nel lin­guag­gio di markup YAML.
   
• Chef Infra: Chef Infra è la soluzione IaC del­l'a­zien­da sta­tu­ni­ten­se Chef. Da aprile 2019 sotto la licenza gratuita Apache 2.0, Chef Infra è uti­liz­za­to, tra l'altro, da Facebook. Le piat­ta­for­me sup­por­ta­te includono Google Cloud, Microsoft Azure, Amazon EC2 e OpenStack.
   
• Red Hat Ansible Tower: lo strumento In­fra­struc­tu­re as Code Ansible fa parte del por­ta­fo­glio della società di software Red Hat dal 2015. Esso offre un dashboard visivo, una propria linea di comando e una potente REST API. I due pacchetti di­spo­ni­bi­li, "Standard" e "Premium", sono, tuttavia, a pagamento.

L'ap­proc­cio In­fra­struc­tu­re as Code interessa tutte le aziende che svi­lup­pa­no e ge­sti­sco­no ap­pli­ca­zio­ni complesse e dipendono quindi da un'in­fra­strut­tu­ra al­tret­tan­to ampia e potente. Le ragioni de­ter­mi­nan­ti a favore della pro­gram­ma­zio­ne di in­fra­strut­tu­re sono:

• l'u­ti­liz­zo di una grande quantità di risorse IaaS;
• l'in­fra­strut­tu­ra è no­leg­gia­ta da molti fornitori o piat­ta­for­me diverse;
• l'in­fra­strut­tu­ra necessita di adat­ta­men­ti regolari;
• le modifiche in­fra­strut­tu­ra­li devono essere do­cu­men­ta­te ade­gua­ta­men­te;
• è richiesta una col­la­bo­ra­zio­ne ottimale tra am­mi­ni­stra­to­ri e svi­lup­pa­to­ri.

Anche se le aziende possono so­stan­zial­men­te pro­gram­ma­re i propri file di con­fi­gu­ra­zio­ne IaC, come in parte cer­ta­men­te avviene, tali strumenti e framework vengono uti­liz­za­ti dagli am­mi­ni­stra­to­ri che lavorano quo­ti­dia­na­men­te con IaC. Invece di esempi concreti di In­fra­struc­tu­re as Code, le seguenti clip mostrano come uti­liz­za­re questi pratici strumenti IaC (qui AWS Clou­d­For­ma­tion e Terraform) per pro­gram­ma­re il codice di un’in­fra­strut­tu­ra.