Todos desarrollamos hoy aplicaciones que contienen una capa de servicios. De hecho la mayor parte de las veces detrás solemos tener una capa DAO o algo similar en las que los servicios se apoyan.
MicroServicios
¿Qué relación hay entre un Servicio y un MicroServicio? . Normalmente cuando trabajamos con servicios siempre hay varios servicios que comparten un mismo contexto. Por ejemplo puede haber varios servicios para gestionar las nóminas y otro conjunto de servicios para gestionar por ejemplo los proveedores.
Una vez definidos los contextos y aislados un grupo de servicios de otros podemos publicar la funcionalidad de estos a través de REST.
Una vez que tenemos nuestros servicios agrupados de esta forma les convertiremos en aplicaciones independientes .
Estas aplicaciones se pueden desplegar en un contenedor de forma totalmente independiente:
MicroServicios y ventajas
Al ser cada microservicio independiente tenemos varias ventajas. Primero es más fácil para los desarrolladores hacerse con ellos ya que son relativamente “pequeños” y fáciles de abordar. Segundo si un microservicio falla no afecta a los demás ya que son totalmente independientes. Por otro lado facilita el despliegue ya que no tenemos que desglegar aplicaciones gigantescas sino “microservicios” de tal forma que si solo tenemos que actualizar uno de ellos pues solo redesplegamos este. Por otro lado y una de las cosas más importantes podemos acceder a estos microservicios desde todo tipo de dispositivo ya que los tenemos publicados vía REST o algún tipo de RPC.
Otros artículos relacionados: Servicios REST , Utilizando JAX-RS
No tienes en cuenta la transaccionalidad que puede darse entre los distintos microservicios, ni la necesidad de hacer rollback si alguno de ellos falla, que fallarán, ni la necesidad de comunicar los distintos microservicios mediante algun broker de mensajes para paliar la sincronicidad propia de los servicios REST que impide escalar de manera natural dichos microservicios.
Tienes razón , faltan cosas . espero en los próximos meses tener tiempo para generar más contenidos de microservicios 🙂 . Un saludo
Actualmente estoy en el proceso de digerir el libro “Microservices patterns”, de Chris Richardson, libro que te recomiendo. Actualmente se está terminando de escribir, creo que va por el capitulo 8 de 10, yo por el capitulo 5, pero se puede leer ya como livebook en Manning. Muy recomendable, te introduce en como manejar dicha transaccionalidad distribuida usando el concepto lógico de sagas como un conjunto de eventos que ocurren en las distintas máquinas gestionadas como si fuesen una maquina de estados distribuidas de manera que solo se avanza al siguiente estado cuando se resuelve la transacción ACID localmente y se ha insertado el siguiente evento en el broker de mensajes, solo entonces, el orquestador central decide el siguiente estado o el coreógrafo. Personalmente entiendo mejor las figura del orquestador mas que la del coreógrafo, pero creo que todavía me falta terminar el libro, luego volverlo a releer y después jugar programando los distintos componentes que pueden aparecer en una arquitectura distribuida orientada a microservicios. Es mucho mas complicado que simplemente diseñar distintos componentes REST con spring boot, dokerizarlos y ponerlos detrás de kubernetes o Marathon/DCOS para que escalen de manera natural. Un ejemplo, imagínate que tienes 3 contenedores del mismo servicio, con la misma lógica y cada uno con una base de datos en local idéntica, el proxy te asigna uno de los 3 contenedores para trabajar, haces la transacción local y el orquestador decide el siguiente paso, elige otro contenedor que contenga la siguiente lógica de negocio y actualiza la transacción acid local y asi hasta que llegas a una transacción en un contenedor Cn que falla. Que ocurre aquí, que tienes que hacer rollback en todas las transacciones anteriores que han ocurrido en los distintos contenedores, algo ya de por si complejo, pero imagina que todas las transacciones han ido bien y tienes todos esos contenedores con esas bd coherentes entre si, pero tienes las otras instancias de los mismo servicios idénticos escalados inconsistentes en datos con respecto al anterior ejemplo. Que hacemos aqui? Me imagino que sería necesario que el orquestador enviara la misma secuencia de comandos a los distintos servicios escalados para que cuando el proxy elija que actúe uno de estos, tenga las mismas opciones de poner actuar correctamente pues tendría los mismos datos replicados sin inconsistencias.
Esta claro que es una arquitectura compleja y que supone grandes retos
Estamos buscando devs que manejen este tema y sean muy buenos en Java para que se unan a nuestro equipo de Rappi 😉 espero no spamiar esta gran discución con ofertas de empleo, pero este es un tema relacionado y estamos buscando personas muy buenas cómo el autor y algunos de los que han comentado.
Gracias.
Soy programadorm y domino la tecnolgía JEE, como framework web utilicé Primefaces y como IDE Netbeans. En fin, me interesa tu propuesta y si me envías tu dirección te puedo enviar mi CV.
mateo.escobar@rappi.com
Hola muy interesante tu descripción quería aprovechar para mencionar que tengo un canal donde estoy subiendo como hacer microservicios, les comparto el link por si desean darle una mirada:
https://www.youtube.com/user/xazpentx
Muchas gracias por el aporte 🙂
Osea si entiendo bien solo tengo que hacer digamos varios servicios en respuestas JSON(por ejemplo) y consumirlos como REST?, el conjunto de todos los servicios se hace un microservicio?. Eso es todo?
Ademas a día de hoy se desplegarían independientes completamente a través de soluciones tipo docker 🙂
Cecilio, muy bueno el post!
Te cuento que estoy trabajando sobre una arquitectura en capas(3), con tecnologías como Jsf, Spring, e Hibernate.
Tendrás algún ejemplo de como implementar microservicios sobre una arquitectura así? Gracias!
JSF no esta orientado a eso en principio. Tendrías que separar lo que es la parte JSF del resto
Tengo una gran duda con respecto a los microservicios, una aplicación monolítica la podías construir por módulos y tener cada módulo en un jar, agregabas tus jar a tu classpath y agregabas Spring Security y listo, tenias una aplicación web con cierto grado de seguridad (autenticación y autorización).
¿Cómo se maneja este tema en una arquitectura de microservicios? Entiendo que mi aplicación web (Front End) podria seguir bajo el esquema planteado con anterioridad, con la única diferencia de que no tendría que integrar varios jar ya que la funcionalidad que estos brindaban está ahora en un microservicio. Pero ¿cómo garantizo que los microservicios estén solo disponibles para las personas correctas, con las credenciales correctas?
Deberas tener un MicroServicio que gestione la seguridad , pero todo esto es empezando 🙂 hay que ver como evoluciona todo
Funciona de la misma forma, mira tu aplicación web (el front) no debería llamar directamente a cada uno de los microservicios, más bien, tu aplicación web (el front) debe consumir digamos un proxy en su propio backend, es decir un servicio interno el cual funcione como proxy a un Gateway el cual es un microservicio que a su vez, sabe a que microservicio llamar. Un ejemplo en palabras vanas seria, tu front, llama a un api interna en tu aplicación llamada /miServicio y esta uri estará protegida con spring security. Esta uri /miServicio, llamara a un gateway por ejemplo /gateway/servicioX el cual será responsable de llamar al servicio esperado por ejemplo /microservicioA/ejecutarServicio. La aplicación front nunca sabe donde esta o en que puerto se ejecuta /microservicioA/ejecutarServicio puesto que los microservicios pueden ser arrancados o finalizados y escalados en cualquier momento. En otras palabras, te dejo mi comentario, una arquitectura de microservicos es para construir apis que den forma o ayuden a construir otras aplicaciones, en otras palabras, mediante arquitecturas de microservicios tu crearás todos los servicios necesarios para que una aplicacionX pueda funcionar, delegando toda la lógica de negocio en los microservicios que estan ocultos de la aplicación consumidora gracias al gateway el cual es el responsable de saber en donde esta cada microservicio y tu aplicación solo debe saber donde esta ese gateway.
Lo que a mi me complica de los microservicios es la interdependencia, por ej si un microservicio es usado por 10 app web distintas y este microservio se cae, las 10 app no podran funcionar full.
En cambio si cada una de ellas tiene este mismo servicio como parte de la aplicación, entonces si una se cae, solo ella se cae.
Eso me tiene un poco indeciso acerca de este enfoque.
Pongo como ejemplo un microservicio de Login usado por distintas web. Al final si se cae, muchas web pueden quedar sin servicio y en vez de ser independientes, se vuelven dependientes
Es una arquitectura en la cual el tema de cluster y escalabilidad será clave 🙂
En la práctica lo que comentas no sucede, si un microservicio se cae, en teoría deberías mantener más de uno desplegado, es decir tener varias instancias del mismo microservicio activo, es decir, escalado, y los clientes o consumidores de ese microservicio deben implementar un balanceador de carga el cual es el encargado de dirigir las peticiones al microservicio más sano o más disponible con el fin de que ninguno caiga, sin embargo, si uno cae, estarán activos otros microservicios que darán soporte a tu aplicación. no tiene sentido que implementes una arquitectura de microservicios desplegando un único microservicio de cada tipo, este tipo de arqutiectura es para evitar la baja disponibilidad que te da un fallo en una gran aplicación monolitica que, cuando se cae, se cae completa.
Como bien dices, una gran ventaja es el despliegue. Podemos desplegar nuevas versiones sin tener que reiniciar ni reempaquetar otras aplicaciones que consuman estos microservicios. Pero hay que ir con cuidado a la hora de reiniciar servidores, puede que una aplicación se despliegue antes que un microservicio y se queje de que no está disponible.
Si esas cosas vamos a tener que valorarlas ya que por ahora los standares que yo recuerde no tienen nada para decidir ordenes de despliegue 🙁
Pero recordemos también que un MicroServicio tiene que ser lo más independiente posible