Una recente ricerca Fortune Business Insights quantifica il valore del mercato dei microservizi per il 2022 in oltre 1,2 miliardi di dollari, ne prevede la crescita a oltre 1,5 miliardi per il 2023 ed un’accelerazione fino ad oltre 6 miliardi per il 2030.
Si tratta di una metodologia di sviluppo delle applicazioni basata su componenti e servizi modulari. In particolare, il modello prevede che ogni “mini” modulo sia destinato al supporto di attività e obiettivi molto specifici ma sempre sia prevista un’interfaccia diretta di comunicazione con altri sistemi e servizi definita oramai comunemente da un’Api, ovvero le Application Programming Interfaces.
Il principale vantaggio del modello è la possibilità di ‘decentralizzare’ lo sviluppo software e quindi fornire un vantaggio considerevole in termini di flessibilità e risparmio di tempo e risorse al modello DevOps, nello sviluppo di applicazioni complesse.
I microservizi crescono perché, soprattutto negli scenari cloud, permettono l’integrazione di operazioni IT, riducendo i costi complessivi, ed accelerando lo sviluppo delle Web app che più si prestano a soddisfare i requisiti di flessibilità e di accelerazione nel rilascio delle release. Non è un caso quindi che anche le Pmi apprezzino l’adozione di un modello di ‘consumo’ dei microservizi on-demand, per il rapporto costo-efficacia e la disponibilità di servizi miniaturizzati che permettono di sviluppare, distribuire e scalare le Web app in autonomia, sul proprio stack tecnologico, piuttosto che creare applicazioni monolitiche. In un contesto in cui si punta sull’automazione è evidente come la prospettiva microservizi possa favorire il cambio di paradigma.
Aws, Microsoft, Ibm (anche con Red Hat), Salesforce, F5, Broadcom e Software AG, Talend sono tra gli attori più importanti in questo mercato. Pur da non confondersi con le più recenti architetture microservizi un riferimento iniziale per orientarsi può essere il modello Ibm Soa (service-oriented architecture). Definisce un modo per rendere i componenti software riutilizzabili e interoperabili mediante delle interfacce di servizio.
I servizi utilizzano standard di interfaccia comuni e un modello architettonico tali da poter essere rapidamente incorporati in nuove applicazioni. Questo solleva lo sviluppatore da una serie di passaggi: per esempio tutti quelli necessari a connettersi o fornire interoperabilità con le funzioni esistenti. Ecco, pur essendo un modello ‘vicino all’ideale’, tra Soa e microservizi è possibile comunque distinguere differenze tecniche, soprattutto nell’utilizzo dell’Enterprise Service Bus (Esb), a seconda del campo di applicazione. Soa è una risposta di livello aziendale per standardizzare il modo in cui tutti i servizi Web dialogano e si integrano, mentre l’architettura dei microservizi riguarda in modo specifico ogni applicazione che attinge, appunto, a “mini” componenti già disponibili.
Aws, a sua volta, sottolinea alcuni aspetti a nostro avviso da rimarcare.
Per esempio, la possibilità di non applicare un unico approccio all’intera applicazione per cui i team preservano la libertà di scegliere gli strumenti migliori per risolvere problemi specifici – significa che è possibile utilizzare il linguaggio di programmazione, il database o il framework più adatti per ciascuna funzione specifica, anziché essere vincolati a una tecnologia unica per l’intera applicazione -; ed un servizio scritto per una certa funzione in ogni caso potrà essere utilizzato come blocco costruttivo per un’altra funzionalità. I vantaggi in termini di resilienza si legano invece al fatto che in un’applicazione, in caso di malfunzionamenti, è possibile isolare il servizio senza bloccare l’intera applicazione.
I ‘detrattori’ del modello, invece, rimarcano, tra i rischi legati alla sua adozione, l’esposizione dei dati che ‘caricati’ e distribuiti negli ambienti multicloud estendono le superfici di attacco, ma soprattutto indicano nella perdita di visibilità e controllo sui singoli componenti dell’applicazione un elemento a scapito dell’integrità, della sicurezza e della coesione dell’applicazione stessa.
Gli analisti sottolineano diverse altre criticità, smarcabili in verità più come avvertimenti per un corretto utilizzo. Per esempio, Gartner che definisce il microservizio come “un componente applicativo con un ambito di azione limitato, fortemente incapsulato, ad accoppiamento flessibile, distribuibile e scalabile in modo indipendente” mette in evidenza la complessità nel “mantenere” i microservizi davvero indipendenti tra loro, e rimarca come essi comunque non siano la soluzione al tema dello sviluppo flessibile ed efficace per il cloud sempre e comunque.
Microservizi, un’architettura complessa
E’ certo che l’architettura migliora l’agilità, perché in ambito DevOps facilita pratiche di distribuzione continua incrementando la cadenza dei rilasci di nuove funzionalità ma parliamo anche di un’architettura complessa. Se le funzionalità di un software arrivano dall’integrazione di componenti distribuiti, sviluppati e testati indipendentemente tra loro, la progettazione a monte è più complicata. E non bisogna dimenticare che se pure è vero che i team IT distribuiscono microservizi con i container, non sono la stessa cosa. E ai team resta inoltre da capire quando e come scomporre le funzionalità in servizi separati. Su questi aspetti è interessante la prospettiva di analisi offerta da Red Hat.
Il vendor chiede di puntare l’attenzione sui problemi legati sì, alla complessità, ma anche all’effettivo margine di produttività. La complessità si lega alla capacità di identificare le dipendenze tra servizi ed evitare le incompatibilità che si possono incontrare nella sovrapposizione delle release. Nel tempo serve quindi automatizzare e monitorare preservando la visibilità sull’impianto nel complesso come nel dettaglio, sull’efficienza della connettività tra i microservizi e senza dimenticare che proprio con questa architettura è stressato anche il concetto di debugging perché – evidenzia Red Hat – “la scelta di un ambiente di sviluppo integrato locale non è percorribile con la molteplicità di servizi attiva”. Per questo il vendor, per questo segmento, propone soluzioni per consentire la “suddivisione” delle applicazioni monolitiche in microservizi, anche per quanto riguarda gestione e orchestrazione, fino alla gestione dei dati generati e con Red Hat Openshift (piattaforma container per Kubernetes) declina un metodo unificato per la connessione, la gestione e il monitoraggio delle applicazioni basate sui microservizi.
Un ecosistema
Per quanto riguarda l’approccio di ecosistema all’architettura, Talend propone invece una best practice basata su quattro livelli. Per quanto riguarda l’hardware comprende server host fisici, DB e sistemi operativi con strumenti di gestione per la configurazione come Ansible, Chef o Puppet così da governare la scalabilità. Lato sviluppo sotto attenzione è invece dove vengono sviluppate le applicazioni, “il livello comprende quindi gli strumenti di sviluppo self-service per la creazione dei DB, tabelle, message broker, schemi e porte”. Logging e monitoraggio sono quindi giustamente considerati fondamentali perché, indirizzati correttamente, portano ad un’implementazione quasi automatica. Il terzo livello è quello dove vive il microservizio, che comprende le istruzioni di configurazione e dove vengono allocati gli strumenti self-service qui attingono gli altri servizi.
In questa rassegna, mutuata da Talend, lasciamo intenzionalmente come ultimo il livello delle comunicazioni perché di fatto impatta su tutti gli altri. Senza, nessuna altra parte dell’architettura funziona. I dati utilizzano prevalentemente il protocollo Http, ma non solo (si pensi ai protocolli leggeri come gRpc) per esempio in fase di autenticazione, gestione ordini, generazione report: il microservizio invia messaggi tramite Http o un altro protocollo previsto ed è importante che tra i dati la comunicazione sia in grado di ‘passare funzionalità di scoperta, registro e bilanciamento del carico sull’intera infrastruttura di microservizi. Ultimo, ma non meno importante, l’adozione dei microservizi richiede un cambiamento culturale e organizzativo significativo, oltre a una pianificazione attenta per garantire il successo a lungo termine.
© RIPRODUZIONE RISERVATA
