From nonsolosoft at diff.org Thu Jan 11 02:01:47 2018 From: nonsolosoft at diff.org (Ferruccio Zamuner) Date: Thu, 11 Jan 2018 11:01:47 +0100 Subject: [Italia-pm] Microservizi e disintegrazione Message-ID: Ciao perlisti! E' da un po' che ci pensavo, vorrei capire quanto l'argomento ? di interesse tra noi. I microservizi si sono imposti come nuovo paradigma di sviluppo: non piu' applicazioni monolitiche ma piccole app, ciascuna specializzata per un solo singolo compito, con API ben definite e minimali, addirittura da eseguirsi in container diversi (docker, jail, macchine virtuali). La parte sistemistica diventa importante perche' deve rimanere leggera, isolata e rapidamente instanziabile (Puppet, Ansible, Chef e simili permettono di automatizzare il deployment in sviluppo, test e produzione), ora sono DevOps e non pi? i sistemisti ad occuparsene. Progettare una applicazioni in questo modo significa strutturare la soluzione in componenti disaccoppiate, che si innestano solo tramite le interfacce definite dalle API. Ogni componente puo' essere realizzata in qualsivoglia linguaggio, puo' essere aggiornata o modificata, riscritta a piacere a patto che rispetti l'API. Alcune di queste app diventano una infrastruttura che fornisce servizi ad uno o piu' siti web o app per smartphone, altre app sono servizi di terze parti, gratuiti o a pagamento (Amazon S3 ad esempio). E' come se da una applicazione MVC ogni controller diventasse un servizio e una applicazione a se' stante, anche l'autenticazione utente diventa un'app esterna (OAuth/OpenID). Il ruolo del progettista software si concentra nel conoscere i mattoncini disponibili, focalizzare i servizi mancanti, definirne l'interfaccia e assemblare la soluzione. Un tempo il database era al centro del sistema, ora abbiamo dati diffusi che potrebbero non esistere fuori dal singolo microservizio, la fantomatica "sessione" pu? essere ripensata da capo, ora ? una macchina a stati finiti che prevale. Gli iscritti a questa mailing list sono distribuiti nel globo, hanno una formazione eterogenea e nella loro vita si sono misurati con problemi molto diversi. Mi piacerebbe capire se avete maturato gi? esperienze in quest'ottica di microservizi e quanto il perl ? stato utilizzato per la loro realizzazione. Quali microservizi avete integrato nella vostra soluzione, con una piccola descrizione e motivazione. Quali strumenti di progettazione avete trovato utili e perch? potreste consigliarli. Se per caso avete realizzato microservizi in Perl che siano disponibili, gratuitamente o meno, al resto della comunit? di sviluppatori. Le domande potrebbero essere ancora molte, per oggi mi fermo qui. Ciao, \ferz Un testo sull'argomento: Building Microservices di Sam Newman, O'Reilly 2015 From nonsolosoft at diff.org Thu Jan 11 23:31:50 2018 From: nonsolosoft at diff.org (Ferruccio Zamuner) Date: Fri, 12 Jan 2018 08:31:50 +0100 Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: References: Message-ID: <90b22af3-b204-f999-e01d-a9d9e4d24a2a@diff.org> On 11/01/2018 11:01, Ferruccio Zamuner wrote: > Un testo sull'argomento: > Building Microservices di Sam Newman, O'Reilly 2015 Ulteriori link: https://www.oreilly.com/tags/microservices From gdo at leader.it Fri Jan 12 01:14:12 2018 From: gdo at leader.it (Guido Brugnara) Date: Fri, 12 Jan 2018 10:14:12 +0100 (CET) Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: References: Message-ID: <1842543523.881.1515748452484.JavaMail.zimbra@leader.it> ----- Il 11-gen-18, alle 11:01, Ferruccio Zamuner nonsolosoft at diff.org ha scritto: > Ciao perlisti! > > E' da un po' che ci pensavo, vorrei capire quanto l'argomento ? di > interesse tra noi. > > 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 From mmarongiu at tiscali.it Mon Jan 15 02:09:48 2018 From: mmarongiu at tiscali.it (Marco Marongiu) Date: Mon, 15 Jan 2018 11:09:48 +0100 Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: References: Message-ID: On 11/01/18 11:01, Ferruccio Zamuner wrote: > Mi piacerebbe capire se avete maturato gi? esperienze in quest'ottica di > microservizi e quanto il perl ? stato utilizzato per la loro realizzazione. Ciao! Batto un colpo solo per confermare che sono vivo e vegeto e leggo la mail, ma non ho niente da contribuire a questa discussione purtroppo. Ciao! -- bronto From nonsolosoft at diff.org Wed Jan 17 00:02:58 2018 From: nonsolosoft at diff.org (Ferruccio Zamuner) Date: Wed, 17 Jan 2018 09:02:58 +0100 Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: <1842543523.881.1515748452484.JavaMail.zimbra@leader.it> References: <1842543523.881.1515748452484.JavaMail.zimbra@leader.it> Message-ID: <91701570-0afa-5519-d897-734798294184@diff.org> 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. From gdo at leader.it Wed Jan 17 09:29:36 2018 From: gdo at leader.it (Guido Brugnara) Date: Wed, 17 Jan 2018 18:29:36 +0100 (CET) Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: <91701570-0afa-5519-d897-734798294184@diff.org> References: <1842543523.881.1515748452484.JavaMail.zimbra@leader.it> <91701570-0afa-5519-d897-734798294184@diff.org> Message-ID: <645279763.2858.1516210176213.JavaMail.zimbra@leader.it> ----- 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. From dakkar at thenautilus.net Tue Jan 23 09:54:46 2018 From: dakkar at thenautilus.net (Gianni Ceccarelli) Date: Tue, 23 Jan 2018 17:54:46 +0000 Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: <91701570-0afa-5519-d897-734798294184@diff.org> References: <1842543523.881.1515748452484.JavaMail.zimbra@leader.it> <91701570-0afa-5519-d897-734798294184@diff.org> Message-ID: <20180123175446.464f7088@nautilus> Butto gi? un po' di idee molto sparse (Ferruccio ? una settimana che mi pungola in canale ??) Tra l'altro, trone in canale aveva puntato a http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/ che mi sembra rilevante alla discussione. Dicevo, idee sparse. Un microservice ? un componente, che invece di essere implementato nello stesso spazio di memoria del processo che lo usa (come nel caso delle librerie), ? implementato altrove, e invece di essere usato tramite chiamata a funzione, ? usato tramite richieste di rete. Per cui abbiamo sostituito poche istruzioni macchina (metti gli argomenti nello stack, chiama la funzione, pesca il risultato) con una marea di codice (serializzazione, discovery, protocollo di RPC, gestione errori transienti, retry con ritardi variabili, gestione errori persistenti, gestione asincrona). Ah, e sto supponendo che non ci sia stato nel microservizio! Altrimenti ci dobbiamo preoccupare anche della gestione distribuita delle transazioni. Auguri. E se siete di quelli a cui piace tanto quando il compilatore o il linker vi fanno notare che avete passato gli argomenti sbagliati a una funzione? preparatevi a montare test di integrazione per (forse) trovare gli errori equivalenti. Quasi mi scordavo: autenticazione! Non vorrete mica che chiunque possa chiamare i vostri servizietti, eh! Quindi? HTTP/2, TLS e PKI mi sembra sia la soluzione pi? semplice. Fate voi. E, ?a va sans dire, se non state molto attenti vi trovate con 15 servizi che vanno aggiornati tutti assieme. E a quel punto tanto vale mettere tutto nello stesso monolite perch? vi risparmia un sacco di problemi. -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 Jabba the Hutt: This bounty hunter is my kind of scum: fearless and inventive. From cosimo+perl at streppone.it Tue Jan 23 13:28:01 2018 From: cosimo+perl at streppone.it (Cosimo Streppone) Date: Tue, 23 Jan 2018 22:28:01 +0100 Subject: [Italia-pm] Microservizi e disintegrazione Message-ID: <1516742881.41242.1245731952.5B1D4EF9@webmail.messagingengine.com> {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 From nonsolosoft at diff.org Tue Jan 30 15:12:48 2018 From: nonsolosoft at diff.org (Ferruccio Zamuner) Date: Wed, 31 Jan 2018 00:12:48 +0100 Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: <1516742881.41242.1245731952.5B1D4EF9@webmail.messagingengine.com> References: <1516742881.41242.1245731952.5B1D4EF9@webmail.messagingengine.com> Message-ID: 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