search
top

¿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.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

13 Respuestas to “¿Qué es eso de los microservicios?”

  1. Fran dice:

    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?

    • martdominguez dice:

      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.

  2. William dice:

    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. Alfredo dice:

    muy buenla la explicacion acerca de los micro-servicios

  4. Istvan Alan dice:

    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. Rafael dice:

    Muy claro. Y que pasa con respecto al tema performance? Los tiempos de consumir http? Saludos, excelente articulo

  6. ronald dice:

    Excelente post, tengo una duda, si son distintos microservicios cada uno de ellos tendra su propia autenticacion?

  7. Isidro dice:

    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,

  8. Victor Aguayo dice:

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

  9. Alvaro Andrés Rodríguez Scelza dice:

    Se agradece el aporte.

  10. Oscar Angel Ramírez dice:

    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.

Trackbacks/Pingbacks

  1. #024 - El mundo de los Microservicios con Nacho Rodriguez - […] Microservicios de Javier Garzás […]
  2. ¿Qué framework de .NET elegir para aplicaciones en servidor? | Velneo - […] estés creando un sistema orientado a microservicios compuesto de varios microservicios independientes, dinámicamente escalables, de estado o sin […]

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top