Nell'articolo Architettura a Microservizi: 7 ragioni per adottarla ho introdotto alcune valide motivazioni per pensare di strutturare la proprio applicazione con un’Architettura a Microservizi.

In questo articolo invece voglio esplorare una serie di ragioni per cui i Microservizi potrebbero essere un grosso errore. Quindi piuttosto che accorgersene tardi, conviene magari valutare tutte le opzioni possibili e se notate di cadere in una (o più) delle motivazioni seguenti pensateci molto bene prima di proseguire.

Non le prendete come motivazioni assolute. Sono più che altro quelle che reputo più importanti (in riferimento anche al panorama italiano) e frutto delle mie esperienze.

1 - Startup: per Moda o perchè è un Trend

Da tecnico, non dovrei neanche citare mode e trend, ma purtroppo capita molto spesso, soprattutto per nuovi progetti o in fase di startup. Applicazioni magari anche poco pretenziose, o *MVP con lo scopo di validare un'idea o testare il Mercato vengono spesso approcciate con un’Archiettura a Microservizi. Si pensa infatti al time to market inferiore, o a presunti approcci Agile per feature change frequenti che minimizzano i tempi di sviluppo.

La verità

I microservizi richiedono un grande sforzo di progettazione, implementazione, gestione/manutenzione e controllo.

Consigli

Pensare in grande è lecito, ma valutate e studiate molto bene l'obiettivo. Se è di breve termine, probabilmente conviene partire con un approccio tradizionale, introducento i microservizi mano a mano che se ne ha bisogno.

Ad esempio è lecito creare uns singola code base per la parte core dell'applicazione e demandare a (micro)servizi appositi dei task asincroni, o magari dei task che richiedono una tecnologia o librerie particolari (come nel caso di algoritmi di ML)

Consiglo per Startup o MVP

Iniziate con infrastrutture gestite il più possibile. Ogni cloud provider ne offre diverse, anche gratuite. Focalizzatevi sulla logica applicativa e fate gestire tutto il resto al provider.


2 - Poca conoscenza del dominio

Se non conosci affondo il dominio lascia perdere i microservizi.

Questo è il più grande errore che si possa fare nello sviluppo di un applicazione, anche quella più semplice. I microservizi per definizione hanno bisogno di essere strutturati in base al dominio applicativo per stabilire quelli che sono definiti boundaries o confini del servizio. E quindi le sue funzioni, il suo modello dati, le sue transazioni (se presenti) e il collocamento generale nell'architettura.

Consigli

Anche se il dominio è in continua evolutzione partite da un modello E/R, anche di massima. Gestite nello stesso contesto (servizio) le parti principali dell'applicazione e quelle con accoppiamento maggiore. Isolate in microservizi le funzionalità che necessitano di tecnologie particolari o che avete già individuato essere dei colli di bottiglia. All'aumento della conoscenza del dominio pensate a come scomporre il core creato in precedenza se ne avete bisogno.


3 - Applicazioni Altamente Transazionali

Se l'applicazione è fortemente sincrona e ha bisogno di transazioni che coinvolgono molte entità (oggetti di dominio) bisogna stare molto attenti. Se iniziate a disaccoppiare si rischia di avere bisogno di transazioni distribuite ed operazioni che sarebbero estremamente semplici e garantite ad esempio da un database diventerebbero un incubo (soprattutto in contesti asincroni)

Attenzione a scegliere il database

Se le transazioni sono importanti e complesse sciegliete un database relazionale. Usate tecnologie No-SQL solo per le feature che riuscite a disaccoppiare, e solo se streattamente necessario.


4 - Monoliti, Management e Processi Aziendali

Con applicazioni monolitiche o comunque con una singola codebase spesso il deployment è un processo lento, manuale, fatto da diversi (anche molti) passi ed in linea di massima un'unica volta per rilascio/passaggio in produzione. Di solito si cerca di migrare l'intero applicativo alla versione successiva, migrando le librerie, migrando il database, migrando l'application server e il core del servizio e così via.

Se il processo non è ben strutturato quello che succede spesso è che i project manager pregano per non avere regressioni, gli sviluppatori sanno che ci saranno, i tester non esistono (sono gli utenti).

Con i microservizi scordatevi l'approccio del passaggio in produzione manuale una tantum del tipo una volta al mese e così via.
O meglio, potete farlo certo, ma sarà un incubo.

Piuttosto (e non smetterò mai di dirlo), l'architettura a microservizi impone un processo differente per sviluppo, test, integrazione e rilascio. I processi aziendali potrebbero non essere del tutto compatibiliti, alla fine l'architettura è un mezzo che deve coesistere con le logiche aziendali, con le competenze del personale, ecc.

L'architettura a microservizi deve essere un espressione del processo, organizzazione e cultura dell'azienda. Non è semplicemente un mezzo tecnico, in mano agli sviluppatori.


5 - Non si vuole introdurre Automazione / DevOps

Molto semplice: Microservizi implica Automazione e DevOps.

L'automazione vi servirà per procedere agili, e per rilasciare feature più frequentemente. DevOps è quell'insieme di operazioni tra lo sviluppo applicativo, il testing e la gestione dell'infrastruttura a supporto. In parole povere l'insieme di operazioni necessarie a far coesistere i microservizi.

Oramai in aziende più strutturate il DevOps è diventato una vera e propria figura professionale (e direi importantissima). Per applicazioni semplici e/o non particolarmente critiche la pratica di DevOps può essere anche svolta dallo sviluppo stesso. Ad esempio se siete in fase di startup o di MVP è consigliabile utilizzare infrastrutture Serverless quanto più gestite possibile. Un valido esempio è (FireBase)[https://firebase.google.com/] di Google che praticamente astrae da ogni necessità di configurazione infrastrutturale.

Consigli

Non potete evitare processi di automazione e DevOps. Se siete decisi verso la direzione dei microservizi, anche solo per prova, partite da servizi managed, e non pensate all'infrastruttura. Se ne avrete l'esigenza sarà semplice iniziare a gestire anche l'infrastruttura, magari per gradi.


6 - Infrastruttura Proprietaria (in-house) vs Cloud Provider

Spesso le aziende, in determinati settori, tendono a mettere in piedi infrastrutture proprietarie: server, database, ecc..

Approcciare l'architettura a microservizi comporta una revisione dell'infrastruttura, dal setup al controllo e monitoraggio. I cloud provider fanno business sui microservizi perché si fanno carico di tutta la parte difficile dell'architettura: setup, deployment, load balancing, auto scaling, proxy, log management, monitoring (alert compresi), sicurezza, ecc..

Se volete una soluzione completamente in-house avete bisogno di tool e servizi a supporto dell'architettura a microservizi. Implementare da soli una tale architettura richiederà uno sforzo notevole e de tutto ingiustificato.

Giusto citare un caso reale: anche Netflix si appoggia su Aws, ed ha anche creato una serie di librerie per rendere più semplice la gestione dell'infrastruttura. (Qui)[https://aws.amazon.com/it/solutions/case-studies/netflix/] trovate qualche dettaglio ufficiale.


7 - Vincoli Tecnologici Particolari

Se per qualche motivo siete legati a certi linguaggi, tecnologie particolari o protocolli di comunicazione magari legacy, i microservizi potrebero andar bene solo per feature marginali e/o di integrazione con servizi di terze parti.

Perdereste infatti uno dei maggiori vantaggi offerti dall'architettura, ovvero la possibilità di creare servizi specifici, magari con tecnologie e linguaggi appropriati (ad esempio Python per Algoritmi di ML).

Attenzione

Se non potete contare su flessibilità tecnologica, o su linguaggi/tool moderni fate attenzione. Potreste dover spendere molto tempo ed energie per lo sviluppo di funzionalita NON BUSINESS ma necessarie per far funzionare correttamente l'architettura. Insomma ne deve valere la pena.

Anche qui il rischio è quello di dover reimplementare parte delle logiche necessarie per far funzionare correttamente l'architettura.