Il sistema proposto porta con sé un notevole margine prestazionale e di abbattimento di costi in più rispetto alla classica architettura monolitica.
8.1
Costi fissi
Parlando di costi fissi, si intende il costo monetario e di tempo che si deve spendere per con- durre manutenzione sul sistema da parte dell’azienda che lo mantiene. Un sistema mono- litico soffre di costi fissi molto alti, in quanto ogni operazione come ad esempio il deploy di aggiornamenti, esecuzione di test, etc.. richiedono risorse costanti. Se al primo rilascio è stato speso una unità t di tempo per la messa online, ad ogni rilascio il sistema deve spendere di nuovo un tempo maggiore o uguale a t. Durante un nuovo rilascio per la diffusione di aggiornamenti, per la messa online dovranno essere riavviate le macchine virtuali, e succes- sivamente al avvio completato potranno essere riavviate le applicazioni. Questo porta a una somma di tempi considerevoli. Prendiamo il caso di una macchina virtuale usata in azienda che per il completo avvio del sistema operativo ci mette 2 minuti, mentre l’applicazione ci mette dai 30 ai 40 secondi. Ponendo il caso di avere anche un numero esiguo di mac- chine come quella usata, mettiamo 50, nel caso si debba effettuare un aggiornamento su tutta la piattaforma, riavviando tutte le macchine al caso pessimo si ha un tempo pari a più di due ore per la messa online completa. Questo tempo non solo è molto alto, ma cresce con l’aumentare delle dimensioni del sistema. Con anche la differenza di una decina di secondi in più per l’avvio per applicativo, si può avere un aumento in tempi considerevole dell’ordine delle decine di minuti.
Figure 28. grafico di tempistiche di messa online in rilascio su applicativo monolitico Lo stesso fenomeno si presenta per la richiesta di risorse hardware. Mettendo il caso che il monolite sia ospitato su una macchina virtuale, una parte di memoria è sempre dedicata al sistema operativo della macchina virtuale, e un altro pezzo è costante o maggiore di una certa quantità dedicata al sistema effettivo. Anche le risorse richieste dall’applicativo au- mentano costantemente e non è facile scalarle per adattarsi al traffico. In caso la richiesta di traffico aumenti, e si necessiti scalare con una nuova istanza dell’applicativo, sarà nec- essario replicare l’intera macchina virtuale. Seguendo l’esempio dell’azienda con una in- stallazione tipica di Ubuntu server con i requisiti tipici, solo per il sistema operativo sono riservati 1.75GB di memoria. L’applicativo monolitico pesa sui 500MB, per una somma totale di 2.25GB per macchina virtuale, che riprendendo l’esempio di prima con 50 mac- chine, si ha un totale di 125GB occupati solo nell’ospitare il sistema. Questo spazio va ad aumentare progressivamente con l’aggiunta di upgrade del sistema, nuovi framework, etc. Nel caso del sistema a microservizi su Openshift invece si ha un notevole miglioramento e risparmio di risorse. Il tempo necessario per rilasciare un applicativo/aggiornamento è ri- dotto all’osso, essenzialmente al deploy dell’immagine Docker sulla piattaforma. Non c’è
bisogno di avviare una macchina virtuale con sistema operativo correlato, in quanto il nos- tro applicativo ha tutto ciò che è strettamente necessario per il suo funzionamento dentro l’immagine Docker. L’onere della gestione del sistema operativo e delle risorse hardware necessarie al funzionamento è tutto a carico della piattaforma di Openshift, quindi può es- sere omesso il tempo di messa online dell’istanza di sistema operativo nuova per ogni nodo del sistema, in quanto è un’operazione non necessaria. Se si necessita scalare, basterà repli- care un pod, quindi istanziare semplicemente un nuovo pod dall’immagine Docker associata, ed essere online e pronti all’uso in una frazione di tempo rispetto al modello monolitico. Un nostro microservizio per effettuare il deploy su Openshift ci impiega circa una decina di sec- ondi a deploy. L’unico momento in cui questo tempo può definirsi considerevole è al primo avvio dell’intero sistema, che quindi deve effettuare il rilascio completo del sistema come il caso monolitico. In questo caso però si ha comunque un guadagno in tempo e risorse di computazione, in quanto non deve essere caricato e avviato un sistema operativo.
Figure 29. grafico di tempistiche di messa online in rilascio su applicativo microservizi In conclusione, i microservizi avranno un tempo di riavvio, deploy, test molto ridotto, in quanto non devono reistanziare o riavviare con loro il sistema operativo, risparmiando un
gran quantitativo di risorse hardware. I microservizi sono lightweight per definizione. Il rilascio è anche reso più preciso dall’alto disaccoppiamento delle componenti, che ci perme- ttono in caso di aggiornamento semplicemente di sostituire uno o più pod per volta, invece di dover reistanziare tutto il sistema già messo in piedi. La sostituzione a caldo poi riduce anche i tempi di disservizio dovuti alla reistanziazione dei pod , mentre il monolite richiede tempi sempre più lunghi di disservizio, man mano che si scala e le sue componenti aumentano di dimensione e numero. C’è anche da evidenziare che il monolite man mano che necessita scalare, crea un grosso spreco di risorse. Mettiamo il caso che l’utenza necessiti un traffico maggiore a una o più frazioni del sistema, che ci spingono a dover scalare in alto e quindi creare una replica. Replicando tutto, aumentiamo il traffico disponibile e rendiamo il sistema in grado di sostenere un lavoro maggiore, ma creiamo anche una grossa fetta di sistema che non era necessario far scalare, e quindi un peso non necessario nei riguardi di memoria e di gestione del traffico, per non parlare di tempo inutile sprecato a deployare. I microservizi non soffrono di questo fenomeno, in quanto il loro disaccoppiamento ci permette di scalare solo dove serve, evitando di creare repliche di parti di sistema non necessarie. Su Openshift è possibile anche bilanciare il carico di lavoro tra i vari pod e programmare autonomamente di scalare in alto o in basso un pod a piacimento per l’adattamento corretto al carico di lavoro.
8.2
Test
Prima di ogni deploy, per un rilascio di qualità, è bene eseguire dei test sulla nuova versione, che ci permettano di identificare errori immediatamente e non farli arrivare nell’ambiente del cliente finale. Dato l’alto accoppiamento delle componenti del monolite, i test sono estesi a gran parte se non alla totalità delle funzioni offerte, in quanto un aggiornamento può portare a un impatto a catena su una grossa fetta del sistema. Anche con l’aiuto di test automatici, questi richiederanno un tempo considerevole per l’esecuzione data la dimensioni del sistema da testare. I microservizi non soffrono di questo problema, in quanto essendo disaccoppiati fortemente tra di loro, è possibile eseguire test circoscritti alle loro zone di interesse, quindi a una frazione minima del sistema. I test automatici offrono un vantaggio considerevole in questa fase del rilascio, in quanto se ben costruiti, riducono al minimo la necessità di test manuali e abbattono quindi i costi. Poniamo il caso il sistema in forma
monolitica debba fare un aggiornamento alla politica del calcolo delle offerte sugli ordini della mensa, questo è di interesse alla totalità delle funzioni degli utenti, dei menu’ e dei posti di esposizione, senza contare i servizi di cassa. Un aggiornamento in quel settore ci porterà a testare che tutte le funzioni elencate svolgano ancora un corretto servizio e non vengano introdotte regressioni di alcun tipo rispetto al rilascio precedente. Nel caso della infrastruttura a microservizi invece, possiamo limitarci a testare la zona di interesse degli ordini, riducendo a più di un quarto il carico di test da fare del monolite. Questo ci porta a identificare anomalie più velocemente, più efficacemente e con meno sforzo, mentre nel caso monolitico si può incorrere in anomalie in fase di rilascio sfuggite ai test, data l’eccessiva mole di funzioni da testare.
8.3
Time to market
L’uso dei microservizi conferisce un aumento nella velocità di sviluppo considerevole, che permette tempi di consegna dell’operato nettamente superiore a quella di un applicativo monolitico. La struttura con granularità ridotta favorisce la metodologia di sviluppo Agile, che consente a piccoli sprint di consegnare il prodotto sviluppato in complicità del feedback dall’utente finale, riducendo così il rifacimento di robe già scritte ma non supervisionate e revisioni post-consegna, ma aumentando allo stesso tempo la soddisfazione degli utenti fi- nali del prodotto. La infrastruttura consente l’organizzazione di più team per il lavoro in parti autonome e altamente indipendenti le une dalle altre, così da ridurre i tempi di sviluppo e massimizzare la produttività.