[Italia-pm] Microservizi e disintegrazione

[Guido Brugnara]

----- Il 17-gen-18, alle 9:02, Ferruccio Zamuner nonsolosoft at diff.org ha scritto:

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

Da anni utilizzo LXC, concettualmente simile a "BSD jail" o Docker per quanto riguarda l'isolazione dei processi.

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

Il plus di Docker, rispetto a LXC e simili, è l'aver codificato la separazione negli storage del codice dai dati, semplificando il processo di aggiornamento ed aver sfuttato i file-system modermi per gestire container varianti originati dalle versioni disponibili nei repository.

> Tuttavia Docker e simili propongono interfacce piu' semplici.
> Su FreeBSD stanno adottando l'interfaccia Docker per manipolare le jail
> (lavoro quasi completato).

Non conosco BSD e l'interfaccia di LXC non mi pare complicata. A me sembra più complicato usare Docker.

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

Una recente valutazione per uno storage da 12Tbyte che teneva conto anche della banda necessaria ha orientato il cliente ad utilizzare nei NAS collocati nella propria sede.
 
> 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.

Se il software prodotto a vita breve non c'è problema, ma se la manutenzione è dell'ordine di grandezza dei decenni, meglio utilizzare gli attrezzi già a disposizione dell'azienda (indendo facente parte del know-how aziendale).
Se un nuovo strumento di viluppo viene valutato strategico è necessario che lo staff aziendale abbia le risorse per apprenderlo.

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

Chi mi assicura che il servizio rimaga tale per molti anni?
Purtroppo ogni provider ha le proprie API.
Un service con un'API semplice è semplice anche da sostituire, ma in ogni caso si deve metter mano al codice.

Recentemente ho dovuto metter mano ad un service per l'invio di SMS per cambiare fornitore e ho dovuto rifare completamente l'interfaccia.


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

Se intendi la capacità di servirsi di provider diversi che erogano lo stesso servizio, come ho detto prima per implementarlo dovrò gestire differente API.
L'adozioni di standard di fatto, come è stato per S3 si contano sulle dita di una mano.

Se invece intendo la scalabilità usando lo stesso service replicato su più nodi, Ok! MA ciò è pur sempre fattibile anche con service sotto il controllo della stessa organizzazione.
 
Per ora i service che offrono prezzi concorrenziali e pluralità di fornitori sono gli storage (NFS, SMB, S3, ..), i container (LXC, Docker, ...) o VM di vario genere. Per il resto è babele in tutti i sensi.

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

Vedrei la differenza più tra applicazione Machine to Machine e Machine to User

Le architetture possibili sono così variegate che trovo difficile ragionare in modo astratto senza esser fumoso.
Non amo riempir le pagine con concetti alla moda che spesso sono riedizioni di concetti esistenti da decenni. 

bye
gdo

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