Architettura a Microservizi vs. Architettura Monolitica

Se l’obiettivo è quello di produrre software facilmente “manutenibile” nel tempo, scalabile e solido, allora dovremmo concentrarci di più sul “Carico Cognitivo” a cui sottoponiamo i programmatori e non tanto sulla diatriba MONOLITICO vs. MICROSERVIZI.

Il nuovo trend delle Architetture a Microservizi

Molte aziende si stanno spostando dalla classica architettura monolitica (una singola applicazione centralizzata che svolge tutte le funzioni) ad un’architettura più frastagliata e “distribuibile” come quella dei Microservizi.

I motivi di questa transizione, tuttavia, non dovrebbero essere ricercati da un punto di vista tecnologico o prettamente architetturale, ma semplicemente tenendo in considerazione lo stress e lo sforzo mentale a cui sottoponiamo il team di sviluppo.
In modo particolare quando deve lavorare a più mani su un’applicazione (monolitica o a microservizi), coordinandosi per non demolire il lavoro dei colleghi e dovendosi preoccupare di tantissime problematiche non prettamente riconducibili al proprio ambito di specializzazione (es: deploy, architettura database, ux, architettura dei componenti, pattern, ecc..).

Il punto è il Carico Cognitivo a cui sottoponiamo il Team

Anziché pensare all’architettura, pensiamo alle persone che devono lavorarci sopra.

Quante decisioni non prettamente collegate allo sviluppo devono prendere in una giornata di lavoro?

Più sono queste decisione e più pesante è il Carico Cognitivo a cui li stiamo sottoponendo.

Le conseguenze? BUG!

Il Carico Cognitivo può essere diviso in 3 categorie:
- Intrinseco (o sintattico): direttamente correlato all’attività di programmazione. “Come si scrive una classe?” “Come si fa un ciclo for?”
- Esterno (o di ambiente): non correlata all’attività di programmazione.
“Come devo deployare l’applicazione?” “Qual’è il comando linux per…?” “Qual’è il limite di righe di codice per un microservizio?”
- Elettivo (o semantico): attività che migliorano il design e l’espressività del software (refactoring, disaccoppiamento, best practice, standard).
“Come posso far comunicare questi due servizi?”

Mentre il Carico Cognitivo Intrinseco è inevitabile (superabile con formazione, affiancamento e scelta delle tecnologie di sviluppo) e quello Elettivo è auspicabile, il Carico Cognitivo Esterno è dannoso.

Ridurre il Carico Cognitivo Esterno

Ovvero, fare in modo che i programmatori possano concentrarsi al massimo sulle attività Elettive e non siano distratti o disturbati da attività di deploy, problemi di debug o testing, onerose attività di configurazione (del sistema, dell’IDE o del database).

Il Carico Cognitivo Esterno non è direttamente correlato all’architettura monolitica o a microservizi, ma è presente con risvolti differenti in ogni architettura. E’ più una questione di “piattaforma” e strumenti.

Rivedere i propri processi interni, la suddivisione del team, gli strumenti di sviluppo e l’architettura in termini di Carico Cognitivo può fare la differenza tra avere un software di facile manutenzione nel medio periodo o un problema che costerà tempo e risorse.

Migliorare la vita ai propri programmatori

Per elevare la qualità del nostro software la strada migliore è quella di migliorare la vita ai nostri programmatori.

Ridurre il Carico Cognitivo Esterno significa fare in modo di semplificare al massimo il lavoro dei programmatori .

Ecco alcuni punti su cui riflettere:
- Standard di deploy (compilatori, sistemi operativi, procedura scritta, ecc..)
- Standard di sviluppo (IDE diversi, nessuno standard di scrittura del codice, nessuno standard di database, nessun protocollo preferenziale, ecc..)
- Molteplicità di linguaggi: anche se spesso è inevitabile per motivi tecnici, avete comunque idea di quale sia il Carico Cognitivo a cui sottoponiamo il programmatore costringendolo a passare da un linguaggio ad un’altro più volte al giorno?
- Difficoltà di comunicazione: le persone devono comunicare e condividere i punti di vista. Il 60% del tempo deve essere dedicato all’analisi e al confronto, il 40% a programmare in silenzio.
- Organizzazione del tempo: pause fissate, magari sfruttate per chiarire dubbi, cinque minuti di brainstorming o anche solo bersi una tisana in relax.
- Educazione e rispetto: che non vuol dire solamente tenere il telefono o la chat spenta, usare le cuffie o non urlare al telefono. Soprattutto vuol dire scrivere il codice prima di tutto per gli altri, non per se stessi. Quindi codice pulito, con nomi di variabili, metodi e classi scelti in modo coerente ed esplicativo, routine chiare e tanti commenti che descrivano il workflow e l’idea del programmatore. Il codice ben fatto si capisce a colpo d’occhio, non spulciando i virtuosismi sintattici dettati dall’ego.
- Senso di responsabilità nei confronti del proprio codice: Le cose di tutti finiscono per essere di nessuno. Chi sviluppa un modulo o un microservizio deve sentire la paternità del proprio lavoro, come un artista.
- Senso di responsabilità nei confronti dei propri colleghi: i membri di un team di sviluppo sono una squadra. Se ci si accorge che un compagno è in difficoltà o non ha chiaro una task, ci si ferma e si affronta il problema.
Se uno “si fa male”, la squadra rischia di perdere.

Come abbiamo risolto questi problemi in Botika

Non abbiamo la bacchetta magica, ne ricette segrete.
Ci mettiamo tanta attenzione e dedizione. Personalmente ho sempre dato il massimo nel cercare di migliorare la vita dei miei ragazzi.
Anch’io faccio lo stesso mestiere e sperimento quotidianamente sia la frustrazione che la soddisfazione nel risolvere problemi ai nostri clienti.

Se qualcosa non va nel mio team, il responsabile sono io.
Una volta cambiata la prospettiva con cui guardavo all’architettura in termini di Carico Cognitivo, ho iniziato a riflettere su come ridurlo al minimo .

Inizialmente siamo partiti definendo rigidi standard di scrittura e formattazione del codice per agevolare la lettura e la comprensione.
Poi abbiamo definito un codice etico che punta al rispetto delle persone ed alla responsabilizzazione.
Abbiamo lavorato anche sulla gestione del tempo e sulla comunicazione.

Fatto questo, tuttavia, restava ancora molto lavoro da fare per ridurre il Carico Cognitivo Esterno. A questo punto avevamo un buon team, affiatato e rispettoso l’uno dell’altro, con uno standard di scrittura ed una buona capacità di analisi e confronto.

Il problema dei linguaggi multipli, del tempo perso nei deploy e della programmazione in team.

Troppi linguaggi in un solo progetto creano fatica mentale e richiedono skill di alto livello.
In genere il problema diventa pesante quando la soluzione offerta al cliente comprende una GUI ed una serie di procedure server side.
Per noi il “must” è che il team sia interscambiabile, almeno entro certi limiti (non certo UX con SysOps, ma gli sviluppatori devono poter intervenire sul codice dei colleghi).

Per la GUI si potrebbe lavorare in .NET, Java, Delphi o HTML5.
Server side abbiamo da anni definito uno standard su Java (per vari motivi, tra cui evitare costi nascosti ai nostri clienti, buone performance, multipiattaforma, assoluta solidità e maturità della JVM, disponibilità di framework, scalabilità e disponibilità di soluzioni open source).

In HTML5 abbiamo trovato un’ottima soluzione con Webpack e Typescript, per cui la scelta è stata facile. Ci siamo scritti una piccola libreria a componenti ed abbiamo definito il primo standard sul linguaggio client-side: Typescript.
Con Electron abbiamo risolto il problema del desktop.

Rimaneva il problema che server-side si programmava ancora in Java e di quello non potevamo fare a meno anche se Node.js non sarebbe stato affatto male. Ma Java è un’altra cosa quando le tue soluzioni devono inserirsi nei sistemi informativi di aziende di medio/grandi dimensioni.

Anche il deploy crea problemi: distrae e fa perdere tempo.
In fase di sviluppo capita spesso di dover effettuare le stesso operazioni moltissime volte ogni ora.

Ma la cosa più difficile da ottenere è stimolare il Carico Cognitivo Elettivo, cioè quell’attenzione e quella concentrazione che portano a dire a fine progetto: “ragazzi, questa architettura è un capolavoro!”.

Come aiutare i programmatori a concentrarsi al massimo sulle business logic e sull’interazione tra i moduli senza preoccuparsi troppo di tutto il contorno?

Ecco la piattaforma che abbiamo chiamato Mosaico

Negli anni (ormai quasi 30) abbiamo sviluppato tante tecnologie in tanti linguaggi. Ogni esperienza ci ha arricchito.
Personalmente ho imparato a guardare le architetture con occhi diversi, ma soprattutto ho imparato ad impegnami nel progettarle per risolvere prima di tutto i problemi interni di sviluppo.

Quando abbiamo pensato a Mosaico l’abbiamo fatto proprio in quest’ottica: migliorare la vita a noi stessi.

In Mosaico, l’architettura a microservizi é potenziata da un sistema di hot-deploy gestito direttamente dal core.
Il deploy non è più un problema, bastano due click.

Progettare un’applicazione, anche molto complessa, a microservizi consente di suddividere la roadmap in piccoli task e consente al team di lavorare in parallelo sui moduli senza sovrapposizioni o interferenze che oltre a distrarre e far perdere il focus rischierebbero di introdurre malfunzionamenti.

Anche il refactoring e la manutenzione diventano meno impattanti se l’architettura dei microservizi è ben fatta.

Il linguaggio di programmazione per i microservizi è Typescript.
Mentre il kernel gira su Java Virtual Machine, le “micromacchine” Javascript sono sandbox autonome e completamente agnostiche.
Lavorare con lo stesso linguaggio e framework sia server-side che client-side evita al programmatore un faticoso switch mentale ed alleggerisce di molto il Carico Cognitivo Intrinseco.

Un sistema di pooling e load balancing si preoccupa di servire tutte le richieste esterne in tempo reale. Il programmatore non deve preoccuparsi dell’architettura dell’Application Server o di come gestire le code.

Il sistema di monitoraggio è in grado di controllare lo stato di salute della piattaforma ed eventualmente intervenire per ripristinare i servizi in fault.
Anche eventuali bug non compromettono il funzionamento e l’integrità del sistema.

Quando programmi su Mosaico, è lui che si prende cura di te 😀
Questa è quello che noi chiamiamo “Alchimia Digitale”.

P.S.
Qui puoi approfondire alcune funzionalità sviluppate su Mosaico