Negli ultimi anni Nexsoft è sempre più coinvolta in progetti di migrazione da applicazioni monolitiche ad applicazioni a microservizi basate su container. Ripercorriamo insieme i nostri 20 anni di storia per osservare le evoluzioni del deployment avvenute in questi anni.
Il server fisico
Oltre 20 anni fa le applicazioni erano eseguite nella maggior parte dei casi su server fisici.
Pur essendo possibile definire i limiti delle risorse in termini di richiesta lato applicazioni, in un server fisico risultava difficile scalare le risorse “a caldo” e senza dover necessariamente causare dei “fermi” macchina e questo causava molti problemi. Quando più applicazioni erano eseguite sullo stesso server, si verificavano situazioni per cui un’applicazione assorbiva la maggior parte delle risorse e, di conseguenza, le altre applicazioni avevano un decadimento della QoS.
In quel periodo gli architetti software richiedevano di eseguire un’unica applicazione per ogni server (soluzione costosissima!) ed i sistemisti erano quindi sempre impegnati nel trovare il giusto trade-off nelle allocazioni delle singole applicazioni sui singoli server.
Il deployment virtualizzato
Circa 15 anni fa in Italia cominciò la diffusione del deployment virtualizzato: questo permise di eseguire più macchine virtuali (VM) su un singolo server fisico opportunamente attrezzato.
La virtualizzazione consentì di isolare le applicazioni in più macchine virtuali e fornire un livello superiore di scalabilità hardware e di sicurezza, dal momento che le informazioni di un’applicazione non erano liberamente accessibili da un’altra applicazione ed era possibile modificare in hot time e senza fermi macchina le risorse delle singole VM.
La virtualizzazione consentì un migliore utilizzo delle risorse, riducendo i costi per l’hardware ed una migliore scalabilità, dato che un’applicazione poteva essere aggiunta o aggiornata facilmente.
Ogni Virtual Machine era una macchina completa che eseguiva tutti i componenti, compreso il proprio sistema operativo, poggiato sull’hardware virtualizzato.
Il deployment in container
Da circa 5 anni si è diffuso, invece, il deployment in container: i container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni.
Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora.
Poiché sono disaccoppiati dall’infrastruttura sottostante, i cintainer risultano portabili tra differenti cloud e diverse distribuzioni.
Volendo raggruppare in un grafico le 3 metodiche è possibile schematizzarle in questo modo:
I vantaggi d’uso dei container
I container sono diventati popolari dal momento che offrono molteplici vantaggi, ad esempio:
- Creazione e distribuzione di applicazioni in modalità Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all’uso di immagini VM.
- Efficienza delle risorse: I container non richiedono un sistema operativo separato, quindi occupano meno risorse. Alcuni potrebbero obiettare che il contenitore offre vantaggi simili alle macchine virtuali. Tuttavia, le macchine virtuali sono spesso di dimensioni gigabyte. I contenitori sono generalmente nella gamma dei megabyte in quanto ogni singolo container è composto da N layer logici che, nel caso il singolo layer fosse utilizzato da più containers, sarebbe presente sul server una sola volta.
- Indipendenza dalla piattaforma: i container sono portabili . Tutte le dipendenze dell’applicazione sono incluse, consentendo di eseguire facilmente le applicazioni su ambienti diversi sia su server fisici che su quelli virtuali. Ciò offre alle organizzazioni una grande flessibilità, accelerando il processo di sviluppo e consentendo agli sviluppatori di passare facilmente ad altri ambienti cloud.
- Condivisione efficace delle risorse: sebbene i contenitori vengano eseguiti sullo stesso server e condividano le stesse risorse, non comunicano tra loro (come per le VM). Se un’applicazione si blocca, l’altra continuerà a funzionare senza problemi. Questa condivisione efficace delle risorse, unita all’isolamento, si traduce in una riduzione dei rischi per la sicurezza: gli effetti negativi di un’applicazione non si diffondono agli altri contenitori in esecuzione.
- Ambiente prevedibile: i contenitori consentono agli sviluppatori di creare ambienti prevedibili isolati da altre applicazioni. Pertanto, la containerizzazione consente ai programmatori di eseguire la coerenza nel lavoro indipendentemente da dove viene distribuita l’applicazione.
- Ridimensionamento uniforme e scalabilità: un altro importante vantaggio dei contenitori è il ridimensionamento orizzontale. Quando si lavora in un ambiente cluster, è possibile aggiungere contenitori identici per scalare l’intero processo. Con le procedure di scalabilità intelligenti, si possono eseguire i container in tempo reale e ridurre drasticamente i costi delle risorse. Ciò accelera anche il ritorno sull’investimento mentre si lavora con i container.
- Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all’immutabilità dell’immagine stessa).
- Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell’applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall’infrastruttura sottostante. L’osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni.
- Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel Cloud.
- Gestione incentrata sulle applicazioni: aumenta il livello di astrazione dall’esecuzione di un sistema operativo su hardware virtualizzato all’esecuzione di un’applicazione su un sistema operativo utilizzando risorse logiche.
- Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente – niente stack monolitici che girano su una singola grande macchina ma una serie di microservizi appunto, opportunamente “orchestrati” tramite software di “orchestrator” (ad es. Kubernates). In questa ottica ogni singolo “servizio” erogato dall’applicazione è frutto di N microservizi, chiaramente servizi diversi possono avere in comune “microservizi” con altri servizi.
Conclusioni
Nexsoft ha attraversato le evoluzioni degli ultimi vent’anni di sviluppo delle architetture informatiche e ha adeguato le sue metodiche di deployment, risultando oggi un’azienda pienamente competitiva nello sviluppo di vantaggiose soluzioni a microservizi.
.
Se anche tu vuoi saperne di più sulla tipologia di progetti informatici che sviluppiamo per i nostri clienti aziende,
dai un’occhiata alle nostre pagine web dedicate!
