wave-545130_640

El término “Microservicios” es uno de esos “palabros” que se han puesto de moda en los últimos tiempos. Como muchos de estos términos, no es realmente fácil de explicar ya que es más que nada una forma de pensar o de diseñar el software. Después cada uno tendrá su propia idea de como llevar esto a la práctica.

La mejor forma de conocerlos, creo yo, es leer una serie de artículos que me gustaría dejar aquí. Lamentablemente no están en Español ¿Alguien se anima a traducirlos 😉 ?

El imprescindible

Lo primero es lo primero y en este caso esto significa que debemos empezar por el Gurú Marting Fowler. Su artículo es de obligada lectura

Microservices (Martin Fowler)

Una arquitectura de microservicios pone cada elemento de funcionalidad en un servicio separado y escala redistribuyendo estos servicios a través de los servidores, replicandolos según se vaya necesitando.

Lo bueno de este artículo, además de tratar el concepto de Microservicios, es que mucho más allá y trata de explicar lo que debería ser un equipo de desarrollo y su integración en la empresa. Y es que no sólo quiere cambiar la forma de diseñar e implementar los servicios si no que también trata de cambiar a toda la empresa estableciendo el centro de gravedad de la misma en el mismo equipo de desarrollo. Al fin y al cabo, al final, todas las empresas serán empresas de software ¿no? Y si no que se le pregunten al presidente del Banco BBVA.

La importancia de los Microservicios

Otro artículo que merece mucho la pena, de Michael Brunton, donde ofrece su propia definición de microservice y justifica el por qué de estas características:

  • Un dominio de problema pequeño
  • Construido y desplegable por sí mismo
  • Se ejecuta en su propio proceso
  • Se integra mediante interfaces bien conocidos
  • Es dueño de su base de datos o almancén de datos

Ofrece algunas claves bastante interesantes para entender estos conceptos que muchas veces se quedan a demasiado alto nivel y no se concretan. Por ejemplo, sobre la independencia de los Microservicios la define como:

La necesaria para poder sustituir un servicio construido en un lenguaje por otro hecho con un lenguaje distinto.

Como Marting Fowler. proclama que es un buen momento para empezar a implenentar servicios pero que para ello es necesario cambiar los equipos de desarrollo. Uno de estos cambios necesarios es que el equipo sea el dueño del servicio y pueda desplegarlo en producción y cambiarlo directamente sin depender de nadie más. Un concepto curioso pero un poco difícil de llevar a la práctica en una gran empresa, basada en áreas o departamentos prácticamente estanco al modo de una cadena de montaje de autómoviles.

Descomponiendo las aplicaciones para incrementar su escalabilidad y su capacidad de despliegue

En este gran artículo, aunque un poco largo, Chris Richardson hace un análisis de lo que significa una aplicación monolítica (el tipo de aplicaciones a los que estamos acostumbrados) y las ventajas que tiene respecto a este tipo de aplicaciones la orientación a microservicios (con sus ventajas y sus problemas). Uno de estos problemas típicos son las comunicaciones entre procesos, que se basan en HTTP con los problemas que ello ocasiona en cuanto al rendimiento o simplemente para localizar el endpoint del servicio al que quiero llamar. También menciona el uso de API gateway para convertir en servicios de grano grueso para su consumo por apps móviles lo que pueden ser varias decenas de servicios grano fino (independientes entre sí).

Si no conoces el concepto de Microservicio, y si ya lo conoces también, espero que te haya “picado el gusanillo” de aprender más sobre ellos con esta entrada. Ya me contarás.