[Italia-pm] Microservizi e disintegrazione

[Cosimo Streppone]

{repost del repost, forse stavolta ce la faccio?}

On Wed, Jan 17, 2018, at 09:02, Ferruccio Zamuner wrote:

> microservices

Microservices, come container e blockchain fa figo e hipster.
Vedo molte realtà investire in queste tecnologie perché lo fanno
altri, non perché ci sono reali problemi da risolvere.

Quando qualcuno parla di applicazioni monolitiche, magari intende
5k linee di node.js ... C'è una componente di esperienza personale
che rende queste definizioni relative. In altre parole, per me
5K (o 50K!) linee di codice non sono una applicazione "grande".

Consiglio la lettura di questo articolo, anche in relazione
ai punti successivi.

https://blog.rapid7.com/2016/09/15/microservices-please-dont/

> I container

Non ho ancora avuto modo di lavorare con un sistema di produzione
che usasse container, quindi non mi esprimo.

Passando da container a macchina fisica c'è una differenza di prestazioni
che fa paura, quello l'ho visto.

> 1) esistono microservizi con API ben definite, forse possiamo almeno 
> ispirarci o renderci "compatibili". ...
> 2) alcuni componenti, estratti dalle applicazioni, possono costituire 
> mattoni pronti all'uso per nuove applicazioni.

D'accordo.

> 3) i progetti possono essere realizzati con linguaggi via via "alla 
> moda", con persone entusiaste di usarli.

In alcune aziende, questo produce insalate di progetti che muoiono
dopo essere stati scritti perché nessuno vuole o può mantenerli.

Personalmente, penso che non sia molto "etico" scrivere un software in
linguaggio X perché X è alla moda o lo preferisco a Y, invece di
vedere cosa è conveniente per la mia azienda.
Certo, succede nel mondo reale tutti i giorni.

> 4) ogni microservizio è specializzato per risolvere un solo problema, in 
> modo lineare e semplice, non mi interessa come, mi basta che passi i 
> test che definisco per la qualità dei sorgenti, per l'interfaccia (API), 
> per le prestazioni.
> Un servizio è specializzato per risolvere un solo problema in un modo 
> semplice e senza "feature", dato che dietro ogni feature si nascondono 
> bug anche difficili da scovare.

Vedi articolo sopra.

> 5) un nuovo concetto di fault tollerant: il sistema deve accorgersi che 
> non funziona qualcosa e reagire se possibile in modo non catastrofico, 
> ad esempio passando dai protocolli di autodiscovery per capire se è 
> attiva un'istanza diversa dei servizi con cui si deve connettere, se non 
> è possibile tracciare e segnalare il disguido gestendo l'eccezione.

Vedi articolo sopra, più, ora improvvisamente tutti i componenti devono
avere il loro layer di fault tolerance, load balancing, ecc.. ecc..
Un vantaggio?

> 6) scalabilità orizzontale. Ho sempre ritenuto la scalabilità verticale 
> più economica, ma quella orizzontale pare regga meglio gli spike.
> Mi piacerebbe avere occasione di affrontare un progetto che abbia picchi 
> di traffico.

La scalabilità dipende dall'applicazione, non dal modo in cui è
o non è divisa in microservices. Un'applicazione monolitica di 1M linee può
essere orizzontalmente scalabile. Nessuna legge lo impedisce.

Ciao!

-- 
Cosimo