<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-09-30 10:01 GMT+02:00 Marco Beri <span dir="ltr"><<a href="mailto:marcoberi@gmail.com" target="_blank">marcoberi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <span dir="ltr"><<a href="mailto:riccardo.magliocchetti@gmail.com" target="_blank">riccardo.magliocchetti@gmail.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><span>Il 28/09/2015 21:43, Marco Paolini ha scritto:</span></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
Uso python. Ultimamente stiamo mettendo su una architettura microservice che<br>
prevede API gateway piccolissimo in node che fa il dispatch, dietro ci sono i<br>
microservice python. Abbiamo copiato un po' da qua<br>
<a href="https://www.nginx.com/blog/introduction-to-microservices/" rel="noreferrer" target="_blank">https://www.nginx.com/blog/introduction-to-microservices/</a><br>
</span></blockquote>
<br>
link interessante grazie</span></blockquote><div><br></div><div>Uno dei rovesci dell'architettura a microservices che trovo davvero duro da digerire è questo:</div><div> <br></div><div><i>"Business transactions that update multiple business entities are fairly common. These kinds of transactions are trivial to implement in a monolithic application because there is a single database. In a microservices-based application, however, you need to update multiple databases owned by different services. Using distributed transactions is usually not an option, and not only because of the CAP theorem. They simply are not supported by many of today’s highly scalable NoSQL databases and messaging brokers."</i></div><div><br></div><div>La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario (ma ammetto di essere ignorante in questo approccio, per questo chiedo un parere qui):</div><div><i><br></i></div><div><i>"You end up having to use an eventual consistency based approach, which is more challenging for developers."</i></div></div></div></div></blockquote><div><br></div><div>Marco, hai centrato perfettamente il nodo della questione.</div><div><br></div><div>In una app monolitica puoi fare:</div><div><br></div><div>def purchase_product(product_id, payment_id):</div><div>  with transaction.atomic():<br></div><div>    product = Product.objects.select_for_update().get(pk=prod_id)</div><div>    if product.status != 'available':</div><div>      raise ProductNotAvaliable()</div><div>    product.status = 'purchased'</div><div>    product.save()</div><div>    Payment.objects.create(product=product, payment_id=payment_id)</div><div><br></div><div>sfruttando alla grande le funzionalità del db relazionale per sincronizzare l'accesso ai dati e per garantire l'integrità e la consistenza.</div><div><br></div><div>Se product e Payment fossero in due microservice differenti, dovremmo creare una transazione distrubita (XA) e gestire il fallimento a livello applicativo. Molto + codice, molto + difficile da testare.</div><div><br></div><div>L'approccio che propongo, e sul quale sto sperimentando da un po', si basa su un core monolitico django e *alcuni* microservice periferici che stanno dietro ad un "frontend application tier" (scusate il nome) in nodejs che permette l'isomorfismo di parte della app e con API graphql. Tutti questi componenti girano in container docker. Ultimamente stiamo usando trhift per la comunicazione interna tra questi "microservice". Stiamo scopiazzando un po' da facebook ;)</div><div><br></div><div>In generale nella maggior parte dei progetti in cui lavoro alla fine non ci saranno mai sopra più di una decina di sviluppatori, quindi l'architettura monolitica se ben incapsulata va benissimo. I microservice a noi servono per gestire un po' meglio la scalabilità e il ciclo di vita dei singoli componenti e poer poterli scrivere in linguaggi diversi in alcuni casi.</div><div><br></div><div>Marco</div></div></div></div>