Microservizi per l’edge computing

Cos’è l’architettura dei microservizi?
Prima di tutto, prendiamoci un momento per pensare a cosa è e cosa non è l’architettura dei microservizi.
Il “microservizio” è una di quelle tendenze di ingegneria del software sovraccariche si aspettative ma nel contempo confuse.
Questo è ciò che noi di G2 pensiamo a riguardo:
Nell’architettura dei microservizi, più servizi liberamente accoppiati lavorano insieme. Ogni servizio si concentra su un unico scopo e presenta un’elevata coesione di comportamenti e dati correlati.
Questa definizione porta con se tre principi di progettazione dei microservizi:
#1 – Unico scopo: ogni servizio dovrebbe concentrarsi su un unico scopo e farlo bene.
#2 – Accoppiamento allentato (loose coupling): i servizi sanno poco l’uno dell’altro. Una modifica a un servizio non dovrebbe richiedere la modifica degli altri. La comunicazione tra i servizi dovrebbe avvenire solo attraverso le interfacce pubbliche del servizio.
3# – Alta coesione: ogni servizio racchiude insieme tutti i comportamenti e i dati correlati. Se è necessario creare una nuova funzionalità, tutte le modifiche dovrebbero essere localizzate in un solo servizio.

Quando modelliamo i microservizi, occorre essere disciplinati in tutti e tre i principi di progettazione. È l’unico modo per ottenere il pieno potenziale dell’architettura dei microservizi. Mancare uno qualsiasi di loro diventerebbe un anti-modello.
Senza un unico scopo, ogni microservizio finirebbe per fare troppe cose, crescendo come più servizi “monolitici“. Non otterremo tutti i vantaggi dell’architettura dei microservizi e pagheremo i costi operativi.
Senza un accoppiamento libero, le modifiche a un servizio influirebbero su altri servizi, quindi non saremmo in grado di rilasciare le modifiche in modo rapido e sicuro, che è il vantaggio principale dell’architettura dei microservizi. Ancora più importante, i problemi causati da un accoppiamento stretto potrebbero essere disastrosi, ad esempio incoerenze dei dati o persino perdita di dati.
Senza un’elevata coesione, ci ritroveremo con un sistema monolitico distribuito, un insieme disordinato di servizi che devono essere modificati e implementati allo stesso tempo per creare una singola funzionalità. Un sistema monolitico distribuito è spesso molto peggiore di un sistema monolitico centralizzato a causa della complessità e del costo del coordinamento di più servizi, a volte tra più team.
Nel frattempo, è anche importante rendersi conto di cosa non è un microservizio:
Un microservizio NON è un servizio che dispone di un numero ridotto di righe di codice o esegue attività “micro”.
Questo malinteso deriva dal nome “microservizio” che lo lascia intendere. L’obiettivo dell’architettura dei microservizi non è avere il maggior numero possibile di piccoli servizi. I servizi potrebbero essere complessi e sostanziali purché soddisfino i tre principi di cui sopra.
Un microservizio non è un servizio creato continuamente con nuove tecnologie. Anche se l’architettura dei microservizi consente ai team di testare la nuova tecnologia più facilmente, non è l’obiettivo principale dell’architettura dei microservizi. È assolutamente corretto creare nuovi servizi con lo stesso identico stack tecnologico, a condizione che il team tragga vantaggio da servizi disaccoppiati.
Un microservizio non è un servizio che deve essere creato da zero. Quando hai già un’app monolitica ben progettata, evita di prendere l’abitudine di creare ogni nuovo servizio da zero. Potrebbero esserci opportunità per estrarre la logica direttamente dal servizio monolitico. Ancora una volta, i tre principi precedenti dovrebbero essere mantenuti.

Conclusione
L’approccio allo sviluppo di applicazioni monolitiche ci è stata utile per diversi anni, ma ha iniziato a essere un freno alla realizzazione di grandi progetti e un ostacolo all’iterazione rapida. Abbiamo iniziato ad adottare in modo sistematico e strategico l’architettura dei microservizi. Siamo ancora nella fase iniziale di questo viaggio, ma ne abbiamo già visto i vantaggi e le potenzialità: ha aumentato notevolmente la produttività dello sviluppo, ci ha permesso di pensare in grande e apportare miglioramenti sostanziali ai prodotti e ha sbloccato il team di ingegneri per testare in sicurezza le nuove tecnologie.