Los microservicios son un tipo de arquitectura de software para diseñar aplicaciones y, además, un enfoque organizativo.

La aplicación se divide según sus funciones principales. Se crea con componentes independientes que ejecutan cada proceso de la aplicación. Cada componente se denomina, funciona y se implementa de manera independiente al resto. Los servicios son lo más atómicos posibles y se crean de acuerdo con las capacidades empresariales.

El desarrollo de este tipo de arquitectura surgió como parte de la progresión ágil, es decir, con el auge de la adopción de la metodología de trabajo ágil a partir de la publicación del manifiesto ágil.

Esta metodología llevó a la popularización de la integración continua en la industria del software (CI), lo cual solucionaba el problema de la lenta integración de código, pero reveló problemas con la implementación ya que seguía siendo muy lenta y por ende ineficaz para esta nueva forma de trabajo. Por ello, se aborda la práctica de entrega continua (CD) que define un proceso de implementación para llevar los cambios a la puesta en producción los más rápido posible.

Todo esto llevó a que, con el tiempo, las organizaciones que implementaban esta metodología se dieran cuenta de que la arquitectura monolítica de sus aplicativos no era la más adecuada para trabajar. Así descubrieron que dividir sus aplicaciones monolíticas en servicios mas pequeños y centrados en el negocio era mucho más eficiente para la metodología de entrega ágil. A nivel organizativo, también produjo un cambio en la estructura de los equipos de desarrollo.

 

Características de construcción

Si bien no existe un estándar, hay ciertas características:

  • Organizado en torno a las capacidades de negocio: los equipos de trabajo son multifuncionales, cada equipo es responsable de construir y operar cada producto.
  • Las aplicaciones basadas en microservicios tienen como objetivo ser lo más desacopladas y cohesivas posibles: tienen su propia lógica de dominio y actúan más como filtros: reciben una solicitud, aplican la lógica según corresponda y producen una respuesta.
  • Gobierno de datos descentralizado: en una estructura que se basa en múltiples servicios colaborativos, permitiendo utilizar diferentes lenguajes de programación y tecnologías dentro de cada servicio. De esta forma se puede elegir la herramienta adecuada para cada tipo de trabajo en lugar de tener una estandarizada.
  • Gestión de datos descentralizada: cada microservicio maneja su propia base de datos independiente del resto. Los microservicios prefieren permitir que cada servicio administre su propia base de datos, ya sea en diferentes instancias de la misma tecnología de base de datos o en sistemas de base de datos distintos. Este enfoque es llamado persistencia políglota.
  • Diseño para el fracaso: los servicios deben diseñarse para que puedan tolerar la falla de los servicios. Cualquier llamada de servicio podría fallar debido a un problema de indisponibilidad del proveedor, nuestro servicio debería responder siempre y de la manera más agradable posible. El monitoreo es vital para detectar rápidamente un mal funcionamiento y que pueda solucionarse cuanto antes.
  • Diseño evolutivo: los servicios se deben diseñar para que sean lo más tolerables posible a los cambios y tratando que su evolución no afecte a sus consumidores. Además, deben incorporar la capacidad de reemplazabilidad, es decir, la noción de reemplazo independiente de cualquier servicio sin afectar al resto.

 

Donde utilizarlos

  • Aplicaciones para entornos de negocio de una alta velocidad de cambio o actualización.
  • Aplicaciones complejas que necesitan gran escalabilidad.
  • Aplicaciones con dominios complejos.

 

Donde NO utilizarlos:

  • Aplicaciones pequeñas que sabemos que no crecerán demasiado.
  • En entornos donde tengamos bien acotado el contexto o dominio: no conocemos bien el proceso de negocio.
  • Sistemas donde para llegar desde un punto A a un punto C depende de que siempre se ejecute el punto B, ya que mientras no pase B no se puede continuar con la operación y solo incrementaría la complejidad de la aplicación sin ningún valor agregado.

 

Necesidades

  • Un sistema de configuración única.
  • Un balanceador de carga.
  • Una herramienta para centralización de logs: en una aplicación monolítica, todo el circuito es fácil de seguir.

Ventajas y Beneficios

  • Agilidad: los microservicios se implementan de forma independiente, por eso resulta más fácil administrar las correcciones de errores y el control de versiones. Se puede actualizar un servicio sin volver a implementar toda la aplicación y revertir una actualización si algo falla.
  • Equipos pequeños y centrados: un microservicio debe ser lo suficientemente pequeño como para que un solo equipo de trabajo lo pueda compilar, probar e implementar. Los equipos pequeños favorecen la agilidad. Los equipos grandes suelen ser menos productivos, porque la comunicación es más lenta, aumenta la sobrecarga de administración y la agilidad disminuye.
  • Base de código pequeña: como no se comparte el código ni la base de datos, la arquitectura de microservicios minimiza las dependencias de código y resulta más fácil agregar nuevas funcionalidades. Por el contrario, en las aplicaciones monolíticas las dependencias del código terminan siendo enormes, por lo que, para agregar una nueva funcionalidad se debe modificar demasiado el código.
  • Aislamiento de errores: si un microservicio individual no está disponible, no interrumpe la función de toda la aplicación.
  • Escalabilidad: los servicios se pueden escalar de forma independiente, lo que permite escalar horizontalmente los subsistemas que requieren más recursos, sin tener que escalar horizontalmente toda la aplicación.
  • Aislamiento de los datos: al verse afectado solo un microservicio, es mucho más fácil realizar actualizaciones del esquema de datos. En una aplicación monolítica, las actualizaciones pueden ser muy complicadas, ya que las distintas partes de la aplicación pueden tocar los mismos datos, por lo que realizar modificaciones en el esquema de datos resulta peligroso.

Los microservicios no son:

  • Una arquitectura que pueda reemplazar cualquier tipo de arquitectura.
  • Un patrón de diseño
  • No corrigen problemas existentes. Por ejemplo, si se tiene un monolito con problemas en el diseño, implementación o código y es pasado a microservicios, solamente se dividirá ese gran problema en pequeños problemas.

 

Si querés profundizar en el tema para ayudar a tu empresa a entrar en el mundo de los microservicios, en CDA tenemos las respuestas a tus inquietudes y necesidades.