¿Qué es un Microservicio?

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.

001

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.

003

Una vez definidos los contextos y aislados un grupo de servicios de otros podemos  publicar la funcionalidad de estos a través de REST.

005

Una vez que tenemos nuestros servicios agrupados de esta forma les convertiremos en aplicaciones independientes .

006

Estas aplicaciones se pueden desplegar en un contenedor de forma totalmente independiente:

007

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.

008

Otros artículos relacionados: Servicios REST , Utilizando JAX-RS

 

About Cecilio Álvarez Caules

Cecilio Álvarez Caules Sun Certified Enterprise Architech (J2EE/JEE).

15 Responses to ¿Qué es un Microservicio?

  1. Carles 23 enero, 2015 at 12:30 #

    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.

    • Cecilio Álvarez Caules 23 enero, 2015 at 12:36 #

      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 🙁

    • Cecilio Álvarez Caules 23 enero, 2015 at 12:49 #

      Pero recordemos también que un MicroServicio tiene que ser lo más independiente posible

  2. hoterix 23 enero, 2015 at 16:19 #

    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

    • Cecilio Álvarez Caules 24 enero, 2015 at 13:05 #

      Es una arquitectura en la cual el tema de cluster y escalabilidad será clave 🙂

    • Ivan Venor Garcia 12 diciembre, 2016 at 7:36 #

      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.

  3. lankor 26 enero, 2016 at 1:33 #

    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?

    • Cecilio Álvarez Caules 28 enero, 2016 at 16:41 #

      Deberas tener un MicroServicio que gestione la seguridad , pero todo esto es empezando 🙂 hay que ver como evoluciona todo

    • Ivan Venor Garcia 12 diciembre, 2016 at 7:43 #

      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.

  4. Mauro 12 julio, 2016 at 19:15 #

    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!

    • Cecilio Álvarez Caules 20 julio, 2016 at 7:42 #

      JSF no esta orientado a eso en principio. Tendrías que separar lo que es la parte JSF del resto

  5. Carlos 27 septiembre, 2016 at 1:52 #

    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?

    • Cecilio Álvarez Caules 27 septiembre, 2016 at 7:06 #

      Ademas a día de hoy se desplegarían independientes completamente a través de soluciones tipo docker 🙂

Trackbacks/Pingbacks

  1. Introducción a VertX - Arquitectura Java - 8 enero, 2016

    […] artículos relacionados: MicroServicios , Java […]

  2. Introducción a RxJava y sus observables - Arquitectura Java - 12 febrero, 2016

    […] Otros artículos relacionados: Iterator , MicroServicios […]

Deja un comentario