<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">El 27 de abril de 2017, 13:28, lasizoillo <span dir="ltr"><<a href="mailto:lasizoillo@gmail.com" target="_blank">lasizoillo@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Buenas,<br>
<br>
Siento ser así, pero creo que te voy a plantear más dudas de las que<br>
te voy a resolver. Pero de todas formas te las vas a acabar<br>
encontrando, así que al lío.<br>
<br>
El día 26 de abril de 2017, 21:24, Luciano Andino<br>
<<a href="mailto:lucianoandino.ar@gmail.com">lucianoandino.ar@gmail.com</a>> escribió:<br>
<span class="">> Buenas, este es mi primer email a la lista. Les consulto: Tengo que<br>
> desarrollar una aplicación del tipo "Hotel" (clientes, habitaciones,<br>
> reservas, etc) pero utilizando microservicios. A detallar:<br>
><br>
> * Un frontend del tipo API REST oauth2 (logueandose con la cuanta de gmail<br>
> por ejemplo), que interactue con el backend de hotel (utilizando<br>
> microservicios).<br>
<br>
</span>Aparte de los que te comenta yamila, tienes otros frameworks como Falcon o Sanic<br>
<a href="https://falconframework.org/" rel="noreferrer" target="_blank">https://falconframework.org/</a><br>
<a href="https://github.com/channelcat/sanic" rel="noreferrer" target="_blank">https://github.com/channelcat/<wbr>sanic</a><br>
<br>
Estos que te comento te pueden dar un rendimiento mayor a costa de<br>
menor estabilidad y que muchas cosas que te las vas a tener que hacer<br>
tu. Como tu problema es ya bastante complejo, tira por los que te ha<br>
recomendado yamila y no mires un solo benchmark hasta que tengas el<br>
problema resuelto ;-) Django y Flask son dos buenas opciones.<br>
<span class=""><br>
><br>
> * El backend estará encapsulado en docker, porque a efectos de<br>
> geolocalización del usuario web, el frontend se comunicará con el backend<br>
> más cercano a través del UUID. Con esto quiero decir que habría más de un<br>
> backend. (Sistema distribuido)<br>
<br>
</span>A este párrafo no le he encontrado el sentido. Docker permite<br>
contenedores de forma sencilla, lo cual es útil para montar un entorno<br>
de desarrollo o un sistema distribuido. Hay otras formas de hacer<br>
sistemas distribuidos. Pero bueno, aceptemos que tenemos docker en el<br>
sistema y que necesitas saber que instancia se va a encargar de hacer<br>
el trabajo.<br>
<br>
Docker tiene un demonio que se encarga de manejar los contendores y<br>
una serie de comandos que se comunican mediante api rests con el para<br>
que le digas como hacerlo. Docker compose está hecho en python, puedes<br>
ver su código. Y tienes librerias para comunicar con ese api:<br>
<a href="https://github.com/docker/docker-py" rel="noreferrer" target="_blank">https://github.com/docker/<wbr>docker-py</a><br>
<br>
Con eso puedes resolver el levantar y dar de baja instancias, descagar<br>
imágenes del registry, ...<br>
<br>
También hay opciones como docker registrator (si no quieres hacerlo<br>
tu) que atiende a los eventos de docker para ver que instancias están<br>
levantadas. Luego guarda la información en un etc o un consul y así<br>
tienes un punto con la información de qué backends hay levantados para<br>
tirarles las peticiones geolocalizadas esas que necesitas:<br>
<a href="https://github.com/gliderlabs/registrator" rel="noreferrer" target="_blank">https://github.com/gliderlabs/<wbr>registrator</a><br>
<a href="https://github.com/jplana/python-etcd" rel="noreferrer" target="_blank">https://github.com/jplana/<wbr>python-etcd</a><br>
<a href="https://github.com/cablehead/python-consul" rel="noreferrer" target="_blank">https://github.com/cablehead/<wbr>python-consul</a><br>
<br>
Pero vamos, esto es solo una opción para hacer las llamadas. Hay otras<br>
aproximaciones, más a lo service bus, que en vez de centralizar quién<br>
puede atender peticiones, lo que centraliza son las peticiones en si a<br>
través de una cola de mensajes. Puedes echarle un ojo a nameko, que<br>
aunque creo que no cubre tus necesidades de routing geolocalizado<br>
puede darte una idea:<br>
<a href="https://github.com/nameko/nameko" rel="noreferrer" target="_blank">https://github.com/nameko/<wbr>nameko</a><br>
<a href="https://www.rabbitmq.com/tutorials/tutorial-four-python.html" rel="noreferrer" target="_blank">https://www.rabbitmq.com/<wbr>tutorials/tutorial-four-<wbr>python.html</a><br>
<a href="https://www.rabbitmq.com/tutorials/tutorial-five-python.html" rel="noreferrer" target="_blank">https://www.rabbitmq.com/<wbr>tutorials/tutorial-five-<wbr>python.html</a><br>
<br>
Otra aproximación es que cuando se levantan los backends se den de<br>
alta en un dns y mediante views en los servidores DNS se resuelva el<br>
tema de la geolocalización. Aunque hay gente que no le gusta que eso<br>
se haga:<br>
<a href="http://queue.acm.org/detail.cfm?id=1647302" rel="noreferrer" target="_blank">http://queue.acm.org/detail.<wbr>cfm?id=1647302</a><br>
<br>
Por lo que cuentas una solución registrator, consul y código para ver<br>
a dónde atacar me suena mejor. Pero como siempre todo depende de los<br>
detalles.<br>
<span class=""><br>
><br>
> * Debo ser capaz desde un perfil de administrador, podér agregar instancias<br>
> backend, dar de baja, etc.<br>
><br>
<br>
</span>Eso como te decía yamila suena a scheduler. Puedes tirar del api de<br>
docker y hacerte el tuyo o tratar de usar uno de los 200 que hay (he<br>
dicho 200 como estimación, podrían ser más o menos). Otra opción es<br>
tirar por un sistema de PaaS (plataform as a service) que aparte de<br>
donde y como levantar las instancias suelen ayudar en su construcción,<br>
marchas atrás, ...<br>
<br>
Levantar instancias de código es trivial, pero ¿qué piensas hacer con los datos?<br>
<br>
Datos y sistemas distribuidos es un auténtico marrón:<br>
<a href="https://es.wikipedia.org/wiki/Teorema_CAP" rel="noreferrer" target="_blank">https://es.wikipedia.org/wiki/<wbr>Teorema_CAP</a><br>
<br>
Si cada instancia tiene sus propios datos no distribuidos te quitas<br>
una gran complejidad. Bieeeen. Se te va a complicar el hacer los<br>
backups. Oooooo. Pero cada backend va a tener los datos más cerca lo<br>
que implica menos latencias. Bieeeen, Pero las tareas de<br>
administración (cambio de esquema, creación de índices, ...) se<br>
multiplican por cada particionado de datos. Oooooo.<br>
<br>
Elijas la solución final que elijas, piensa en que dejas un marrón a<br>
un pobre administrador de sistemas que tiene familia. Piensa en ellos<br>
y echale un ojo a 12Factor para que no tenga que acabar siguiendo los<br>
12 pasos de aa.<br>
<a href="https://12factor.net/es/" rel="noreferrer" target="_blank">https://12factor.net/es/</a><br>
<br>
Esas son unas pocas buenas prácticas que te ayudarán con los sistemas<br>
distribuidos. Algo tan tonto como inyectar la configuración por<br>
variables de entorno te permite ejecutar la misma imagen de docker en<br>
desarrollo, preproducción y en cada uno de las instancias distribuidas<br>
de producción.<br>
<span class=""><br>
<br>
> Cuando digo "tipo Hotel", es porque tomé una variante similar, en mi caso<br>
> sería "alquiler de bicicletas de persona a persona", el usuario puede<br>
> reservar bicicletas (hacer uso) de otro usuario registrado en el sitio.<br>
><br>
> Cuento con conocimientos (no tantos) de Flask y como aplicación monolítica<br>
> me queda claro cómo hacerla, pero llevándola a microservicios, el tema de la<br>
> comunicación entre los servicios y cómo dividir la base de datos, me está<br>
> dando problemas de sólo pensar. Docker también es nuevo para mí.<br>
><br>
<br>
</span>Con calma, pasito a pasito. Son muchas cosas pero una por una no son<br>
tan difíciles:<br>
- Dockeriza una de tus aplicaciones monolíticas: base de datos por un<br>
lado, servidor smtp por otro, tu código por otro. Muchas imágenes ya<br>
están creadas, solo hace falta hacer un "docker run ...." ;-)<br>
- Haz un docker composer y levanta tu entorno de desarrollo con un solo comando,<br>
- Sonrie orgulloso<br>
- Juguetea con los comandos de docker-composer para crear más<br>
instancias de un servicio y otro.<br>
- Juguetea con el api python de docker<br>
- Hazte alguna prueba de concepto rápida: registro de backends en<br>
consul, que tal un rabbitmq y si tiro este contenedor como se comporta<br>
la plataforma. Pruebas de concepto muy simples y chabacanas para<br>
quedarte con la sensación. Si vas a perder más de uno o dos días te<br>
estás complicando la vida.<br>
- Respira hondo y pon en orden todo lo que has aprendido.<br>
- Profundiza en alguna de las pruebas de concepto. Plantea por aquí<br>
(como configuro el dbrouter de django para que ataque al master para<br>
escrituras y a varios slaves para consulta) o por otros foros (alguna<br>
receta para montar un cluster de mongo con replica sets en<br>
docker-composer) dudas específicas que te irán surgiendo.<br>
- Haz el proyecto<br>
- Profit ;-)<br>
<span class="im HOEnZb"><br></span></blockquote><div>lasizoillo, gracias por tu respuesta, todo lo que me comentas me servirá. Mientras avanzo iré<br>releyendo tu respuesta. Te voy a hacer caso sobre dockerizar una aplicación monolítica y ver qué me permite<br></div><div style="background-color:transparent">hacer las herramientas que mencionas. por el momento la base es un archivo de texto, pero <br></div><div>si hago dos servicios que se comuniquen entre si, los pondré a cada uno en un docker.<br><br></div><div>La única manera es ir a paso a paso como decís. Cuando tenga dudas puntuales, volveré a preguntar.<br><br></div><div>gracias y saludos.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
> Existe un framework para este tipo de desarrollo o bien un ejemplo? Es para<br>
> la Universidad.<br>
><br>
> Muchas gracias,<br>
><br>
> --<br>
> Luciano Andino<br>
> Ing. en Sistemas de Información<br>
> UTN FRSF<br>
> BMSTU<br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> Python-es mailing list<br>
> <a href="mailto:Python-es@python.org">Python-es@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-es" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-es</a><br>
><br>
______________________________<wbr>_________________<br>
Python-es mailing list<br>
<a href="mailto:Python-es@python.org">Python-es@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-es" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-es</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Luciano Andino<br>Ing. en Sistemas de Información<br></div><div>UTN FRSF<br>BMSTU<br><br></div><br></div></div></div></div>
</div></div>