¿Qué es eso de los microservicios?

No sé si habrás oído hablar del término “microservicio”, o de que una aplicación sigue una arquitectura de microservicios. Tanto si lo conoces pero no sabes realmente lo que es, como si no lo habías oído nunca, este es tu post. Microservicios es un tema muy actual y es muy probable que cada vez más escuches hablar de ello.

¿Qué son los microservicios?

Una “arquitectura de microservicios” es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno ejecutándose de forma autónoma y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus API.
Normalmente hay un número mínimo de servicios que gestionan cosas comunes para los demás (como el acceso a base de datos), pero cada microservicio es pequeño y corresponde a un área de negocio de la aplicación.
Además cada uno es independiente y su código debe poder ser desplegado sin afectar a los demás. Incluso cada uno de ellos puede escribirse en un lenguaje de programación diferente, ya que solo exponen la API (una interfaz común, a la que le da igual el lenguaje de programación en la que el microservicio esté programado por debajo) al resto de microservicios.
No hay reglas sobre qué tamaño tiene que tener cada microservicio, ni sobre cómo dividir la aplicación en microservicios, pero algunos autores como Jon Eaves caracterizan un microservicio como algo que a nivel de código podría ser reescrito en dos semanas.

Comparando el enfoque “monolítico” con el de microservicios

Para que realmente entiendas lo que estamos haciendo con los microservicios, voy a poner un ejemplo muy simple. Imagina que queremos realizar una aplicación web, tipo Amazon, pero más sencilla. Los usuarios entran por nuestra web, ven los productos que tenemos en venta, y cuando compran un artículo, gestionamos el envío del producto a su domicilio.
1 – Visión monolítica
Una primera idea de cómo afrontar esta aplicación sería la siguiente arquitectura monolítica:
monolithic
Podemos acceder a la página web de la tienda, realizar compras, etc., gracias a un servidor, una máquina que está ejecutando el código de la aplicación, en forma de archivo war, que eventualmente se conecta a una base de datos para recuperar información.
Cuando un usuario compre un producto vía web, mostremos los productos disponibles, etc., la aplicación responderá de una forma u otra, según la hayamos programado, pero el código de las distintas lógicas de negocio (inventario, pagos, envíos) aunque puede estar separado en distintos módulos del código, finalmente se empaqueta en un único archivo ejecutable. Por eso la llamo arquitectura monolítica.
Si hago un cambio en el módulo de pagos, tendré que subir a producción de nuevo todo el código, incluido los módulos de inventario y envíos, a pesar de no haberlos cambiado.
Además, para escalar la aplicación (por ejemplo dar servicio a muchos usuarios) tendré que ir ejecutando copias de mi aplicación bajo balanceadores de carga, que vayan redireccionando a los usuarios hacia un sitio u otro, en función de si el sistema está muy saturado. En este caso, tendré que replicar toda la aplicación, aunque solo sea el módulo de pagos el que concentre la sobrecarga.
Pero por otra parte, si mi aplicación no es muy compleja, la subida será sencilla y fácil de gestionar, ya que en este caso hablamos de un único archivo ejecutable.
2 – Visión de microservicios
 microservices
 
En vez de tener un único ejecutable, cada componente es un ejecutable por si mismo, y los servicios se comunican entre sí a través de llamadas.
En este caso también tenemos un microservicio que implementa la interfaz web con la que interactúan los usuarios y cierta lógica por debajo para llamar al microservicio de pagos, inventario y envíos cuando sea necesario.
Como beneficios con respecto al anterior enfoque tenemos que:
– Cada microservicio se puede desplegar de forma independiente: un cambio en el módulo de inventario, no afectará a los demás, solo tendremos que subir ese módulo.
– Es fácil de entender, ya que la lógica de negocio está bien separada.
– Facilita la gestión de equipos multifuncionales y autónomos. Por sí mismo, cada microservicio es mutlifuncional: tiene una parte de base de datos, de backend, etc., además de ser independiente de los demás. Podemos formar equipos multifuncionales que se encarguen de varios microservicios, escalando el proceso de desarrollo de forma más sencilla (recuerda el post de la ley de Conway, tu arquitectura es reflejo de la organización de tu equipo y al revés, y puede llegar a facilitar o dificultar la gestión técnica).
– Es más fácil de escalar a nivel de software, ya que en lugar de replicar toda la aplicación y gestionarlo con balanceadores, replicaremos los microservicios que tengan más carga.

Retos y consejos

Una arquitectura de microservicios puede parecer muy beneficiosa, pero como todo, tiene sus pros y contras. Como cualquier arquitectura software.
Además, está muy extendida la idea de que solo con microservicios se puede llegar al despliegue continuo o a la entrega continua, pero esto no es así. Empresas como Facebook tienen despliegue continuo sin tener una arquitectura de microservicios.
Lo que hay que tener en cuenta es que los microservicios introducen complejidad, que hay que gestionar. Hay que hacer un gran esfuerzo en despliegues automáticos (si tienes 300 microservicios no puedes estar desplegando cada uno de ellos a mano), monitorización (si falla uno, no puedes ir mirando uno a uno a ver qué pasa), gestionar fallos, consistencia de datos, estrategia de pruebas y más factores que introducen los sistemas distribuidos.
Como dice Martin Fowler: “hay formas conocidas de gestionar todo esto, pero es esfuerzo extra, y nadie que conozco en desarrollo software parece tener muchísimo tiempo libre.”
Por otra parte, yo diría que si tu software es muy simple, no te metieras en un enfoque de microservicios. En cambio, si ya se vuelve muy complejo de gestionar y vale la pena invertir esfuerzo en ello, adelante. Empresas muy grandes lo han hecho.
Puede que haya gente que desarrolle una aplicación nueva utilizando microservicios, pero el enfoque que más me he encontrado es de empresas que han visto que gestionar su software como “monolito” es tan complejo, que han empezado a separar la aplicación en microservicios o a gestionar desarrollos nuevos de esa manera.
En este caso, si aconsejaría evolucionar la arquitectura hacia microservicios, pero poco a poco, manteniendo una parte monolítica, combinada con ciertos microservicios separados (las zonas más urgentes de la aplicación que necesitan ser desacopladas). Para hacer esto, por ejemplo, podemos utilizar la técnica de Branch By Abstraction, entre otras estrategias.
Pero no lo olvides, analiza la situación, no quieras implantar microservicios porque sea lo “que se lleva ahora”. Hay muchos tipos de arquitecturas y soluciones, la cuestión está en ver qué es lo que más nos conviene en cada momento.

29 comentarios en “¿Qué es eso de los microservicios?”

  1. Muy interesante el artículo, además se ve que está de moda porque esta misma semana estuve hablando con un colega sobre esto mismo. Sin embargo se me presenta una duda. ¿Si por ejemplo necesito escalar el módulo de inventario y hago 3 réplicas del mismo, entonces tendré que poner un balanceador delante que reparta las pèticiones no?

    1. No necesariamente, aunque sería lo ideal para que no quede del lado del cliente la complejidad de elegir a cual de los 3 apuntarles.
      Digo no necesariamente, porque un microservicio debería realizar operaciones sin estado, por lo tanto una operación en cualquiera de los 3 sería equivalente.
      Otro tema, que no estoy seguro, es que la persistencia sea un microservicio separado. Un microservicio se debe encargar el mismo de la persistencia.
      saludos.

      1. José Luis Alavez

        Bueno, no olvides tampoco que existe el patrón de balanceo de carga del lado del cliente. En algunas arquitecturas es el cliente el que se encarga de balancear hacia todas las instancias que están desplegadas.

  2. Según la ley de Conway, ¿sería correcto pensar lo siguiente?: «Necesitaría una Holocracia (en la gestión) de mis equipos para llegar a una Holocracia en las arquitecturas de mis aplicaciones».

  3. Pingback: #024 - El mundo de los Microservicios con Nacho Rodriguez

  4. Lo que no veo en tu post como vas a manejar el control de compromiso en los microservios para temas trasnacionales o ¿sólo sirve para consultas?. Por otro lado existen los ws-at que actualmente desacopla cualquier negocio monolitico y lo implementa los servidores de ampliaciones como jboss, Órale, ibm y otros. En que se diferencia?. Es más de lo mismo o es una mejora.

  5. Pingback: ¿Qué framework de .NET elegir para aplicaciones en servidor? | Velneo

      1. También puedes usar Azure Active Directory (o cualquier otro equivalente) para gestionar la identidad a través de todos los módulos, es mucho más fácil pero el JSON Web Token lo puedes implementar tu y así no tienes que pagar un servicio, dependerá de tus prioridades.

  6. Hola,
    Muchas gracias por aclarar lo de los Microservicios.
    Yo he trabajado con arquitecturas de Micrositios y Portlets, creyendo que era algo similar.
    Ahora lo entiendo y creo que actualmente a través de las arquitecturas SOAP REST, permite fácilmente este tipo de arquitecturas, y creo que implícitamente ya se hace uso de Microservicios, porque todas las llamadas son vía Restful.
    Sin embargo, cómo bien dice Istvan Alan, el tema transaccional no me queda nada claro y es de vital importancia.
    Gracias. Un saludo,

  7. Buen post, entiendo mas ed Microservicios, pero me queda una duda, cual es la diferencia entre una arquitectura de microservicios y una Arquitectura SOA?

  8. Oscar Angel Ramírez

    Muy buena información.
    Los microservicios a mi parecer son un extracto de la aqrquitectura orientada a servicios, mas concretamente a los servicios tipo entidad y de negocio con una composición más atomica. En mi experiencia personal he visto bastantes proyectos y sistemas donde se han realizado servicios los cuales ofrecen poca reusabilid, composición o no estan orientados a un area de negocio especifico. Para realizar este tipo de arquitectura primero se tiene que hacer un analisis de los procesos que existen en el negocio para posteriormente abstraer partes primordiales de un proceso como servicios que brindan funcionalidad no solo al proceso en cuestión, si no tambien a otros. En este analisis hay que reconocer servicios de entidad, de negocio y de utilidad primordialmente, cada uno de estos orientados a dominio(es decir, enfocados a su area de negocio). No se debe de realizar servicios por hacer servicios.

  9. Hola, estoy queriendo hacer un trabajo final de grado (tesis) sobre microservicios. Tengo mi aplicacion monolitica (es sobre gestion de turnos) y la idea es pasarla a una arquitectura de microservicios. Por ejemplo seguir un patron de diseño para que ahora la aplicacion se divida en algunos servicios. Que me recomiendan? Es una teisi que se debe terminar en un año y no se si me dara el tiempo.

    1. «Pero no lo olvides, analiza la situación, no quieras implantar microservicios porque sea lo “que se lleva ahora”. Hay muchos tipos de arquitecturas y soluciones, la cuestión está en ver qué es lo que más nos conviene en cada momento.» Tendría que saber de tu app para poder decirte si en mi opinión te interesa una arq de microservicios. Si quieres usar microservicios si o si, para mostrarlos en tu tesis intenta pensar en funcionalidades independiente en tu aplicación y separalas en diferentes servicios (proyectos, aplicaciones en un Web Server, Dlls, etc)

  10. Buen día, me encuentro revisando qué son los microservicios pues soy reclutadora de TI y mi cliente me levantó una vacante al respecto, si bien entiendo que son y para qué sirven, me gustaría saber que herramientas o que lenguajes debe saber alguien que maneje microservicios.

    1. Buen día, la arquitectura de microservicios no es dependiente de una tecnología de programación o de un lenguaje concreto. Puedes construir una casa por módulos , de cemento, de ladrillo, de madera,.. y todas estarían basadas en una arquitectura de módulos. En esa vacante te han debido dar más información sobre las tecnologías a utilizar, sino lo que quieren es un consulor tecnológico, no un técnico (quieren alguien que sepa los pros y los contras de cada tecnología y que tenga criterio para decidir cuál adoptar). Hoy en día se asociado mucho la arquitectura de microservicios a Cloud, ya que en Cloud la arquitectura es normalmente de Microservicios. Por ponerte un ejemplo, puedes realizar una solución con arquitectura de microservicios con .Net y desplegarla en Azure comodamente. Pero opciones hay, ¿decenas de miles ya?

  11. buenos dias, disculpa Javier estoy interesado en el tema, me gustaria saber si tienes tiempo para dictarme una clases de programación de microservicios. Gracias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba