ho veramente bisogno del multi-master?

sono appena stati pubblicati i video del'ultimo pycon

e c'è anche quello di Gabriele Bartolini

vorrei concentrarmi su un argomento che emerge nei primi minuti

un partecipante riferisce che avrebbe lasciato Postgres per passare ad un db con multi-master

risposta di Gabriele: "...ma ti serve davvero il multi-master"?

ecco, mi sono fatto la stessa domanda...

a me pare che in effetti il multi-master sia auspicato come panacea di tutti i mali senza rendersi conto che ci sarà un trade off da accettare, sempre e comunque

in fondo il CAP theorem è sempre lì a ricordarcelo: un corollario del CAP theorem è che in caso di partitioning o tieni la consistency o tieni l'availability, non c'è scampo

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

parla di container e di orchestration, ma non solo

interessante, per esempio, questa cosa che dice:

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 ... ma non sono per niente banali! hanno ricadute da gestire perfino a livello business

che un ATM mi permetta di prelevare soldi che non mi appartengono o che Amazon mi lasci ordinare beni che non esistono più... beh, è 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

non è uno scherzo, no?

ripetiamo un attimo la domanda... ma ci serve davvero il multi-master?

Notiziario online

Vorrei mettere online un sitarello per uso poco più che personale.
E' una sorta di piccolo CMS molto specializzato.
Alcuni amici dovrebbero poter indicare appuntamenti ed avvisi, poi io (o chi per me) periodicamente, ogni due settimane circa, scarica queste informazioni ed impagina un piccolo "notiziario" cartaceo che verrà stampato in qualche centinaio di copie e distribuito nei dintorni.
Si tratta di un piccolo servizio di utilità per la comunità del luogo.
La prima fase del notiziario, che potremmo chiamare di "raccolta dati", avviene al momento via email: tutti mi spediscono le notizie e poi io impagino un file Libre Office.
Vista la mole relativamente ridotta di notizie, appuntamenti ed avvisi, il tutto potrebbe proseguire tranquillamente secondo la modalità email.
Tuttavia il mio lato "nerd" vorrebbe divertirsi a fare un sitarello dove le persone, chiamiamoli "inviati speciali", dopo debito login, possano caricare le notizie al posto di inviarmele via email.
Il vantaggio è che eventuali correzioni, adeguamenti etc. gli "inviati" le possono fare direttamente sul sito senza bisogno dello scambio di email e contro-email.
Fatta la premessa per l'inquadramento del problema vorrei parlare delle soluzioni tecniche per implementare il "sito del notiziario".
Ma prima di questo serve un ulteriore precisazione.
Va chiarito che, dato che la mia attività di "impaginatore di bollettini" è svolta a livello volontario ed amatoriale, anche la realizzazione di questo sito procederà in modo hobbistico senza scadenze e senza calendari.
Scadenze e calendari ne ho già abbastanza nella mia vita professionale per cui almeno questa cosa avverrà, come si dice, "senza fretta".
Questo significa anche che potrò permettermi di adottare alcune soluzioni tecniche che saranno più o meno un overkill per il problema in oggetto.
Detto questo, veniamo a noi...
Con cosa vogliamo fare il nostro bel super-sito?
Ecco lo stack: ubuntu, nginx, python, django, uwsgi
Per il deploy/provisioning: ansible
Vagrant per il test in locale e, probabilmente, Digital Ocean per il deploy vero e proprio.
Vi interessa come procede la cosa? Allora, arrivederci alla prossima!
Stay tuned!