[Italia-pm] Microservizi e disintegrazione

[Ferruccio Zamuner]

Ciao Guido,

circa 3 anni fa, anche io ho avuto la tua stessa reazione quando ho 
letto per la prima volta questa novità dei microservizi.
L'esperienza maturata, le soluzioni scelte con cura negli anni, ma chi 
ce lo fa fare di cambiare qualcosa?
In particolare investire per ottenere forse non troppo di più.

Scomporre i problemi lo sapevamo già fare, risolverli è il nostro 
mestiere, programmazione modulare e ad oggetti l'abbiamo appresa;
perché atomizzarli quando per anni abbiamo puntato all'integrazione e 
alla scalabilità verticale?

I container: da anni uso le jail su BSD, in particolare per software che 
so ben gestire in sicurezza sui miei server, come PostgreSQL o sendmail, 
un web server.
Inscatolarli ulteriormente non mi è mai parso un passo avanti.

L'autore di Docker ha tratto ispirazione dalla jail BSD: una sorta di 
chroot on steroids, uno strato di sicurezza e isolamento anche dello 
stack tcp simile alla macchina virtuale, e grazie alla condivisione 
dello stesso sistema operativo arrivano a contenere migliaia di jail su 
un server fisico quasi senza overhead.
Tuttavia Docker e simili propongono interfacce piu' semplici.
Su FreeBSD stanno adottando l'interfaccia Docker per manipolare le jail 
(lavoro quasi completato).

Mi sono chiesto: cosa si può ottenere, almeno in teoria, di buono dai 
microservzi o da questa architettura?

1) esistono microservizi con API ben definite, forse possiamo almeno 
ispirarci o renderci "compatibili".
Ad esempio lo storage il cliente può acquistarlo da chi preferisce e non 
dobbiamo più "rifatturarlo" nè conteggiargli l'uso e limiti della banda 
in uscita.

2) alcuni componenti, estratti dalle applicazioni, possono costituire 
mattoni pronti all'uso per nuove applicazioni.
Se l'interfaccia è compatibile con microservizi esistenti, è possibile 
che anche altri li considerino.
Mantenendo l'esempio dello storage, ci sono più soluzioni di backup che 
ora considerano come target ogni servizio compatibile con Amazon S3.

3) i progetti possono essere realizzati con linguaggi via via "alla 
moda", con persone entusiaste di usarli.
Posso commissionare microservizi a terzi, o a sviluppatori nuovi senza 
formali sul resto del nostro ambiente di sviluppo, tanto li metto in un 
container dedicato e non rischio di "sporcare" fuori o introdurre grossi 
problemi di sicurezza.

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.

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.

6) verifica continua di livello di servizio: posso avere test che 
verificano periodicamente ogni servizio nell'ambiente di produzione,
gli stessi posso usarli come stress test sull'ambiente di sviluppo.

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.

7) cambiare un servizio, non è catastrofico, le altre parti 
possono/devono ignorare il cambiamento, ma eventualmente (re)agire se un 
microservizio non è disponibile.

Probabilmente non ho esaurito gli argomenti.

Abbiamo visto questa architettura al lavoro per software come servizio 
(Saas) rivolto ai soluzione business to consumer (B2C).
A quali condizioni questa architettura porta un vantaggio competitivo 
nel business to business (B2B)?


Guido, che ne pensi?


Ciao,                        \ferz


On 12/01/2018 10:14, Guido Brugnara wrote:
> ----- Il 11-gen-18, alle 11:01, Ferruccio Zamuner nonsolosoft at diff.org ha scritto:
>> I microservizi ===CUT===
>>
>> Mi piacerebbe capire se avete maturato già esperienze in quest'ottica di
>> microservizi e quanto il perl è stato utilizzato per la loro realizzazione.
>> ===CUT===
> 
> E' una valutazione che ho fatto ma che nella mia realtà non porta vantaggi perché l'utilizzo di microservices di terze parti è più costoso e/o crea dipendenza.
> 
> Certamente le competenze necessarie per il loro utilizzo sono inferiori e difatti sono utili per coloro che sistemisti non sono, ma fintanto che un'azienda ha al suo interno queste competenze difficile che troverà conveniente "fare lo spezzatino" delle loro applicazioni.
> 
> bye
> gdo
> 


-- 
Oggi e' sempre un giorno migliore di ieri.