[Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco De Paoli]

Il giorno 30 settembre 2015 11:27, Carlo Miron <miron a python.it> ha scritto:

> 2015-09-30 10:34 GMT+02:00 Marco Beri <marcoberi a gmail.com>:
>
> > On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron <miron a python.it> wrote:
> >> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
> >> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
> >> le complicazioni del caso.
> >
> > "The main disadvantage to this algorithm is that it cannot recover in the
> > event the network is segmented in any manner. The original 3PC algorithm
> > assumes a fail-stop model,
> > where processes fail by crashing and crashes can be accurately detected,
> and
> > does not work with network partitions or asynchronous communication:
> >
> > Brrr...
>
> Riporto un dialogo immaginario tra me e un personaggio fittizio che
> chiamerò Pelatone™ per proteggerne l'identità.
>
> me
> non c'è soluzione, al problema del partitioning
> ma nemmeno con nessuna replica master-master relazionale
> quindi è un problema comune
>
> Pelatone
> certo
> ma tu useresti un db replicato in una applicazione finanziaria per esempio?
>
> me
> se lo devo scalare sui c100k non vedo grosse alternative
>
> Pelatone
> ok
> 100.000 connessioni al secondo in una app finanziaria... uhm...
> solo la borsa mi sa
> però in quel caso lì io devo essere sicuro delle transazioni...
> come faranno?
>
> me
> evitano accuratamente che il sistema si partizioni :D
>
> Pelatone
> :D :D
> bella roba... allora è come dicevo io... non si usano
> i microservizi
> in una app finanziaria
>
> me
> ripeto, il problema del partitioning non è insito nei microservizi
> ce l'hai anche nello sharding
> solo la replica master/slave ne è immune
> ma presenta forti limiti di scalabilità, infatti
> poi non è vero che il fail-stop model è sempre la soluzione migliore
> per esempio la borsa. se la cina si isola, il sistema borsa crolla?
> no, si formano due isole indipendenti; il mercato va avanti da una
> parte senza la cina, dall'altra solo con la cina
> e poi qualche povero deficente riconcilia il casino ammano :-/
> hai indubbiamente perso consistenza. ma è la migliore quantità di
> consistenza che puoi ottenere in un sistema distribuito peer
> e non c'è nessun "non me lo posso permettere" che tenga, punto.
>

segnalo questa intervista all'inventore del "CAP theorem", Eric Brewer
https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95

parla di container, di orchestration e di "compromises on consistency"

un estratto:

That bothered me for a little while until I eventually realized that was a
fundamental tradeoff and that anyone that wants to be highly available in a
distributed system has to make some compromises on consistency. It was not
at first well received, because it implies that people who build databases
can’t promise to be up all the time, even though they do make that promise.
And it means if you want to have both you actually have to work pretty hard
to even get good compromises.

certo ci sono varie strategie di eventually consistency ...

sono spesso citati i casi di un ATM mi permette di prelevare soldi che non
mi appartengono o Amazon che mi lascia ordinare beni che non esistono
più...
è qualcosa che va gestito a vari livelli: dal livello del codice
applicativo (logica supplementare per gestire queste situazioni) su su fino
ai livelli dirigenziali dell'azienda per capire cosa è accettabile e cosa no

il caso citato da Carlo è però emblematicamente divertente nella sua
enormità: vorrei proprio vedere chi sarebbe l'autorità delegata a
ri-raccordare le quotazioni delle borse occidentali con le borse asiatiche
in caso di partitioning continentale...

ciao,
Marco
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150930/90bd82ae/attachment.html>