Differenza tra infrastruttura per microservizi e infrastruttura come codice (IaC)

Infrastrutture per microservizi

Un’architettura a microservizi permette di dividere un’applicazione in differenti servizi indipendenti, atti a svolgere un’unica funzionalità di business e aventi delle interfacce per comunicare tra loro.

Invece di utilizzare un unico grande database, in questa architettura ogni servizio ha il proprio, strutturato secondo le proprie esigenze. “Non è necessario che i servizi condividano lo stesso stack di tecnologie, le stesse librerie o gli stessi framework” [9]. Ognuno di essi, infatti, non offre visibilità agli altri, ma come detto in precedenza espone delle API (Application Programming Interface) per comunicare con l’esterno.

Il passaggio all’architettura a microservizi introduce diversi vantaggi:

• sviluppo più agile e rapido che favorisce l’integrazione continua. Un singolo team di sviluppo può sviluppare, modificare, testare e rilasciare un microservizio, scegliendo indipendentemente il framework o il linguaggio che reputa più Ne consegue un ritmo di rilascio più veloce.
• è possibile effettuare correzioni di bug o aggiornamenti contestualizzati alla singola funzione, senza dover ridistribuire l’intera applicazione.
• riusabilità: trattandosi di servizi mirati ad una singola funzione di business, possono essere riciclati e riutilizzati sia all’interno dell’applicazione stessa che in altri contesti.
• la scalabilità è notevolmente migliorata, grazie al fatto di poter istanziare in seguito a reali necessità di un servizio, allocando risorse “on demand” in maniera elastica.
• individuazione errori ed eliminazione del single-point-of-failure: grazie a questa architettura distribuita, viene eliminato l’elemento centrale che poteva essere un single-point-of-failure. Separando e isolando i servizi l’individuazione di errori diviene più semplice ed efficace.

Una volta sviluppato, dove risiede un microservizio?

Un microservizio, in fase di installazione ed esecuzione, richiede all’ambiente in cui risiede molte tecnologie e configurazioni per trarre vantaggio dalle sue caratteristiche. Ma configurare in modo corretto un’infrastruttura in modo classico può essere molto dispendioso e richiedere la partecipazione di una figura specializzata, come un sistemista. Inoltre questo, essendo un approccio “manuale”, si presta particolarmente all’introduzione di errori o mal-configurazioni.

Assolutamente in linea con la metodologia DevOps è nata la cosiddetta Infrastruttura come Codice, per ovviare a questi problemi e cercare di semplificare la configurazione del sistema ospitante l’applicazione.

Infrastruttura come codice

Il concetto di IaC (Infrastructure as Code) nasce come detto in contrapposizione alla pratica di configurazione manuale delle infrastrutture.

Come suggerisce il nome, si basa sull’idea di sviluppare ed utilizzare del software che gestisca la configurazione e la messa in funzione dell’infrastruttura alla base di applicazioni. Questo approccio rende l’infrastruttura stessa più elastica e flessibile, ed aggiunge due qualità: ripetibilità e scalabilità.

L’uso di Infrastructure as Code permette di creare un’infrastruttura in maniera più semplice e di ridurre il numero di errori in fase di configurazione, soprattutto nei casi in cui si abbia bisogno di riconfigurarla frequentemente. Supporta pienamente l’idea di infrastruttura cloud, non diversa dalla precedente se non per il fatto di essere virtualizzata ed offerta come servizio e che, proprio per questo motivo, prende il nome di IaaS (Infrastructure as a Service).

“IaaS costituisce la base del cloud computing e consente agli utenti di realizzare piattaforme IT virtualizzate facilmente scalabili”. Oltre a IaaS, esistono altri tipi di infrastrutture fruite come servizi cloud, come PaaS (Platform as a Service) e SaaS (Software as a Service).