Microservizi: 7 motivi per NON utilizzarli

Nell'articolo Microservizi: 7 motivi per usarli ho introdotto alcune valide motivazioni per pensare di strutturare la propria 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'Architettura 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.

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)

2 - Poca conoscenza del dominio

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.

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)

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).

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 compatibili, alla fine l'architettura è un mezzo che deve coesistere con le logiche aziendali, con le competenze del personale, ecc.

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.

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..

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 potrebbero 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).

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