[Italia-pm] Microservizi e disintegrazione

[Ferruccio Zamuner]

Ciao.

Cosimo grazie per partecipare a questa discussione in cui mi trovo a 
fare l'avvocato del diavolo :D

Inizio sostenendo che se siamo tutti d'accordo, o siamo "illuminati" 
rispetto agli altri che corrono dietro ai microservizi o forse tutti 
condividiamo gli stessi punti ciechi.

Quale avvocato del diavolo provo a insinuare altri dubbi, almeno prima 
di salire con voi sull'altare della luce. :D


On 23/01/2018 22:28, Cosimo Streppone wrote:
> {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.

Blockchain pensavo fosse l'ennesima buzz-word, ho scoperto che è alla 
base dei bitcoin e delle crypto valute.

Problemi reali da risolvere ne ho scoperti diversi dove proprio questa 
buzzword "blockchain", probabilmente con sistemi distribuiti potrebbe 
essere la chiave per affrontarli:
* riservatezza e diffusione di informazioni multimediali o genericamente 
soggette a copyright (per i media) e remunerazione delle stesse.
* controllo e contabilizzazione delle visualizzazioni di spot video
* contrattazione di servizi automatici, con relativa erogazione e 
verifica (smart contract)
* tutela dati clinici e biometrici, con diffusione degli stessi a sole 
persone autorizzate dal paziente/atleta/proprietario
* posta certificata finalmente ben fatta e non nella modalità "italiana" 
centralista e falsamente garantista :D

Tutto questo senza necessità di un sistema "centrale" che se da una 
parte potrebbe "garantire" in realtà limita e controlla lo scambio delle 
informazioni, di solito vantando una commissione per il suo operato 
(come le banche centrali e le banche in generale).

Ma tornando ai microservizi, direi inizialmente di pensarli dove il 
"software as a service" è possibile.
Pensando a quali Software As Service conosco oltre a Netflix e quelli di 
storage che avevamo già citato (dropbox, amazon S3):
* sistemi di pagamento (paypal, stripe, satispay e vari gateway di 
pagamento)
* sistemi di cambio di cryptovalute
* sistemi di commenti (disquis)
* carrello elettronico (potrebbe essere un servizio del tutto esterno al 
sito che vende)
* CRM (Salesforce)
* ERP (se c'e' un CRM, perché no?)


Forse centra poco, ma vedete voi:
sono cliente EOn, ricevo la notifica della bolletta della luce via 
email. Nella email c'e' un link che mi porta ad una pagina web statica 
personale memorizzata su amazon S3 che a sua volta ha i link per 
scaricare la mia bolletta in pdf, vedere le mie condizioni contrattuali, 
i miei consumi realitivi a quella mia bolletta. Ogni link citato è un 
altro file dentro Amazon S3.
Eon avrebbe potuto erogare il tutto in modo dinamico dai propri 
webserver?  Certo, ma la soluzione cosi' realizzata avrà dei vantaggi 
rispetto a quella dinamica?
Ricordo anni fa che le aziende di questo genere avevano il problema di 
creare a fine mese tante fatture in poco tempo: oltre che stamparle la 
generazione non era di per se' banale.
Ora potrebbero aver distribuito il calcolo (anche fossero semplici 
script) su N sistemi ciascuno che si occupa di un batch di clienti alla 
volta, e se i sistemi interni non bastano, possono "comprare" tempo 
macchina su Rackspace o Amazon ECS.
Certamente scala meglio e permette di determinare tempi certi di 
elaborazione, senza problemi di limite di banda sulla consultazione 
delle bollette.
E i microservizi? Boh, non so se ne fanno uso, ma è un esempio che trovo 
"innovativo" rispetto a come si ragionava qualche tempo fa.
A differenza di quanto suggeriva Gianni la settimana scorsa, non vedo 
problemi di sicurezza in questo modo anche se è "serverless".

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

Il problema che citi lo abbiamo gia' visto in passato.
Programmazione modulare: come separo il codice nei moduli?
Programmazione funzionale: quanto incapsulo in una singola funzione?
Pogrammazione ad oggetti: con quanta granularità divido il problema in 
classi?
Model View Controller: quanto lascio nel controller, cosa nel modello?
Microservizi: cosa intendiamo per applicazione monolitica?

Sicuramente la risposta è sempre relativa, dipende da molti fattori che 
con la pratica si sono chiariti ma spesso rimangono soggettivi.

Twitter nel 2010 ha creato un webservice "snowflake" in Scala che 
forniva solo identificativi univoci perché il database, Cassandra, non 
li generava internamente. Probabilmente era un microservizio 
antelittera. (fonte: 
http://rob.conery.io/2014/05/28/a-better-id-generator-for-postgresql/ 
che ho scovato per caso cercando esperienzed di sharding sugli uuid con 
PostgreSQL).


> 
> Consiglio la lettura di questo articolo, anche in relazione
> ai punti successivi.
> 
> https://blog.rapid7.com/2016/09/15/microservices-please-dont/

Ti ringrazio per l'interessante link.

Citandolo, quello che sto cercando di comprendere è quando
"moving to microservices will help you grow, scale, and make money".

La risposta è mai?
Forse no.



Ciao,               \ferz