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

[Carlo Miron]

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.

>> Probabilmente è vero che l'architettura a
>> microservizi è da adottare quando ulteriori evoluzioni o scale up di
>> software monolitico diventano troppo
>> complesse/costose/rischiose/wathever.
>
> Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che
> hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)

non è sempre vero. se hai solo problemi evolutivi, succederà che il
costo evolutivo diventerà insopportabile ed il sistema stagnerà finché
qualcuno non propone una alternativa più economica. se invece devi
anche scalare (per esempio, per adattare il tuo sistema nazionale ad
un nuovo mercato), allora se il costo complessivo di riscrittura è
inferiore a quello evolutivo, riscrivere conviene
(ipotizzando che la riscrittura abbassi la complessità/migliori le
prestazioni/etc di ordini di grandezza)

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
| <miron a python.it> wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|                                            --Carlo Miron :