[Italia-pm] Microservizi e disintegrazione
Ferruccio Zamuner
nonsolosoft at diff.org
Tue Jan 30 15:12:48 PST 2018
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
More information about the Italia-pm
mailing list