I microservizi sono un approccio allo sviluppo software che ha visto una marea crescente di interesse nell’ultimo decennio circa, andando di pari passo con altre tendenze come lo sviluppo agile e nativo del cloud e, in particolare, l’uso di contenitori come veicolo per la distribuzione di componenti software.
Adozione di microservizi è andata aumentando negli ultimi anni. Un sondaggio condotto da O’Reilly nel 2020 di oltre 1.500 organizzazioni ha riscontrato che solo un quarto circa non utilizzava affatto i microservizi. Del 75% che lo era, solo il 10% li utilizzava da più di cinque anni, il che significa che la maggior parte ha fatto il grande passo con i microservizi negli ultimi anni.
I microservizi non sono una tecnologia specifica, ma sono invece uno stile di architettura software e un approccio alla progettazione di applicazioni e servizi. Invece di creare un’applicazione come un’unica entità monolitica, l’approccio dei microservizi consiste nel suddividere la funzionalità richiesta in una raccolta di servizi più piccoli e distribuibili in modo indipendente che comunicano tra loro.
Questo approccio presenta diversi vantaggi, uno dei quali è la scalabilità più semplice, poiché i singoli componenti possono essere ridimensionati indipendentemente l’uno dall’altro. Ad esempio, solo le parti dell’applicazione che potrebbero essere soggette a un’elevata domanda devono essere ridimensionate, in genere avviando nuove istanze di quel componente per bilanciare il carico di lavoro, anziché ridimensionare l’intera applicazione.
I microservizi si prestano anche a un processo di sviluppo agile, perché le dimensioni ridotte delle parti componenti facilitano il miglioramento continuo e consentono aggiornamenti più rapidi del codice. Consente inoltre di utilizzare diversi linguaggi di programmazione per componenti diversi, poiché alcuni linguaggi potrebbero essere più adatti a determinati tipi di attività. Poiché le parti dei componenti sono piccole, è più facile per gli sviluppatori comprendere il codice, il che può avere un effetto a catena sull’affidabilità.
Un altro vantaggio è la possibilità di ridurre i tempi di fermo attraverso un migliore isolamento dei guasti. Se una singola istanza di microservizio ha esito negativo, è meno probabile che l’intera applicazione o servizio venga disattivata.
Potenziali svantaggi
Sebbene ci siano vantaggi in un approccio basato sui microservizi, ci sono anche alcuni aspetti negativi che le organizzazioni devono considerare. Ad esempio, sebbene lo sviluppo di ogni componente del microservizio possa essere più semplice, l’applicazione o il servizio nella sua interezza potrebbe diventare più complesso da gestire.
Ciò è particolarmente vero con una distribuzione di qualsiasi scala, che potrebbe coinvolgere decine o centinaia di singole istanze di diversi componenti di microservizi. La complessità deriva non solo dalla gestione della comunicazione tra tutte queste istanze separate, ma dal monitoraggio di ciascuna di esse per garantire che funzionino entro i parametri previsti e che non consumino più risorse di quelle normalmente richieste, il che potrebbe indicare la presenza di un problema.
Anche il test e il debug possono diventare più difficili con i microservizi, semplicemente perché tracciare l’origine di un bug può essere più difficile in una rete di istanze di microservizi, ognuna con il proprio set di log. Anche il test dell’intera applicazione può essere complicato, perché ogni microservizio può essere testato correttamente solo dopo che sono stati testati anche tutti i servizi da cui dipende.
In particolare, il monitoraggio è più importante in una distribuzione di microservizi, ma la natura distribuita dei componenti lo rende più complesso rispetto alle applicazioni tradizionali, che sono in gran parte autonome. Il sistema di monitoraggio deve operare a livello di ogni singola istanza di microservizio, tenendo d’occhio allo stesso tempo la rete di dipendenze tra i diversi componenti.
Il modo in cui operano i microservizi ha anche implicazioni per l’infrastruttura dell’organizzazione. Il supporto del ridimensionamento automatico per soddisfare l’aumento della domanda implica che le risorse per le nuove istanze di microservizi devono essere in grado di essere fornite tramite chiamate API (Application Programming Interface), il che implica un certo livello di infrastruttura definita dal software simile al cloud.
I dati possono essere un altro problema spinoso quando si crea un’applicazione o un servizio basato su un’architettura di microservizi o, per essere più precisi, dove archiviare i dati. Questo perché è probabile che ogni istanza di microservizio disponga del proprio archivio dati, ma alcune applicazioni potrebbero richiedere la possibilità di accedere a un repository condiviso. Diversi servizi avranno anche diversi requisiti di archiviazione dei dati, con alcuni nel settore che affermano che a Il database NoSQL ha più senso, mentre altri sostengono di attenersi a SQL, se questo è ciò che l’organizzazione ha già implementato.
Ci sono altre opinioni divergenti su questo tema, con alcuni esperti che consigliano che un unico database (ma forse non un singolo schema) condiviso da più servizi sia l’approccio migliore, perché, da un lato, consente alle organizzazioni di riutilizzare le procedure che hanno in luogo per il backup e il ripristino del database. Altri lo sconsigliano, perché crea un potenziale singolo punto di errore che va contro l’etica dei microservizi.
Pianifica attentamente
Ciò significa che l’architettura dei microservizi potrebbe non essere adatta a tutte le organizzazioni, né a tutti i tipi di applicazioni. Tuttavia, le ragioni alla base della sua crescente adozione sono che i microservizi semplificano l’implementazione di un approccio più agile alla distribuzione dei servizi, che molte organizzazioni stanno ora cercando.
“Le organizzazioni che seguono il percorso dei microservizi tendono ad essere più all’avanguardia rispetto al resto”, afferma l’analista indipendente Clive Longbottom. “In quanto tali, tenderanno anche ad essere più aperti a pensare a ciò di cui ha bisogno il passaggio a una nuova topologia architettonica. Storicamente, la maggior parte dei cambiamenti è stata evolutiva: le architetture di microservizi di successo sono rivoluzionarie e richiedono un ripensamento completo di ciò che viene fatto”.
In altre parole, i microservizi potrebbero essere più adatti a un’implementazione “green field” che viene creata da zero, piuttosto che alle organizzazioni che cercano di eseguire il refactoring o aggiornare un’applicazione esistente.
Come già notato, DockerI contenitori software in stile sono una tecnologia che nella mente di molti è stata associata ai microservizi, sebbene siano solo un modo per implementare una distribuzione distribuita come i microservizi. Altri modi potrebbero includere macchine virtuali leggere o persino distribuire istanze di microservizi come codice non virtualizzato in esecuzione in un ambiente server, proprio come le applicazioni quotidiane. Elaborazione senza server funzioni sarebbe un altro modo di implementare i microservizi.
I container sono forse più adatti delle macchine virtuali, perché richiedono meno risorse ed è molto più rapido generare una nuova istanza di container piuttosto che avviare una nuova macchina virtuale. I container sono ora anche una tecnologia relativamente matura, con un ampio ecosistema di strumenti per supportare l’orchestrazione (come Kubernetes), comunicazioni (come Istio) e monitoraggio.
È interessante notare che il sondaggio O’Reilly ha rilevato che una percentuale superiore alla media di intervistati che ha riportato risultati positivi con i microservizi ha scelto di istanziarli utilizzando i contenitori, mentre una percentuale maggiore di intervistati che ha descritto i propri sforzi di microservizi come infruttuosi non ha utilizzato i contenitori.
Ciò potrebbe suggerire che i container siano un’opzione meno rischiosa quando si implementano i microservizi, ma ancora una volta si tratta più di scegliere la tecnologia giusta per l’applicazione e i requisiti specifici dell’organizzazione.
“Se guardiamo solo a un microservizio, è solo uno stub funzionale”, afferma Paciock. “Il contenitore dovrebbe fornire all’ambiente le esigenze del microservizio, con l’orchestrazione e così via, gestendo il provisioning, l’applicazione di patch, l’aggiornamento e lo spostamento dei microservizi come richiesto attraverso le piattaforme più ampie”.
In altre parole, la creazione di microservizi comporta un diverso tipo di complessità rispetto agli stili di applicazione tradizionali e più monolitici. Per questo motivo, può essere considerata una tecnologia più adatta per applicazioni moderne o native del cloud di nuova costruzione, o per le organizzazioni che revisionano il proprio IT come parte di un processo di trasformazione digitale.
More Stories
Risultati salutari sull’allentamento del Covid
Ukrtelecom e Iskratel lanciano l’espansione della rete in fibra da 12 milioni di euro in Ucraina
L’acquisizione di tecnologia per le forze dell’ordine richiede un esame più approfondito