BLOG

Buscar
  • José Antonio Ces Franjo

Micro-servicios

"Divide et impera" es una frase mal atribuida a Julio César, aunque bien podría haber sido dicha por cualquier líder militar en la historia. En informática es el lema detrás de los micro-servicios, una arquitectura que tiene muchas ventajas si trabajas en entornos cloud puros o híbridos. Te ayudo a entenderlo.



La arquitectura de micro-servicios es una aproximación para el desarrollo de software que consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con el resto a través de mecanismos ligeros desarrollados en APIs. Bajo esta filosofía, cada servicio se encarga de implementar una funcionalidad completa del negocio. Cada uno de ellos es desplegado de forma independiente y puede estar programado en distintos lenguajes y usar diferentes tecnologías de almacenamiento de datos.

Cada uno de los micro-servicios que componen un sistema es desplegado de forma independiente y puede estar programado en distintos lenguajes.

Pero los micro-servicios no son algo de ahora. No son tan modernos. Aunque se haya empezado a hablar de ellos hace menos de un lustro, sus bases podríamos encontrarlas en los principios de diseño de Unix. Pero ha sido el fuerte crecimiento del uso de infraestructuras de nube pública, suficientemente distribuidas por los muchos datacenters de sus proveedores, lo que ha dado lugar a que estas arquitecturas se pongan de moda y sean la base de la mayoría de las aplicaciones de empresas. Su antítesis, el "monolito", ha caído en desgracia ;)


Arquitecturas de Empresa

Entendamos primero cuál es la arquitectura típica de un sistema empresarial. Las aplicaciones empresariales proponen recurrentemente una arquitectura que se compone de tres partes:

  1. Una interfaz de usuario desarrollada en HTML, CSS y JavaScript corriendo en un browser o navegador.

  2. Una base de datos, generalmente relacional.

  3. Un software de servidor que maneja las peticiones procedentes del navegador y que ejecuta la lógica del sistema accediendo a la base de datos.

En la figura puedes observar esta arquitectura de tres niveles.

Según los métodos tradicionales de desarrollo, cuando alguien trata de dividir las tareas relativas al diseño de una aplicación estructurada en estos tres niveles, lo habitual es tener un equipo de trabajo alrededor de la interfaz de usuario, un segundo equipo trabajando en el software del servidor, y un último equipo centrado en la estructura y los "queries" del sistema a la base de datos. El trabajo es dividido sin tener en cuenta la funcionalidad, sino la tecnología de desarrollo. Las capacidades y los conocimientos de los programadores. Como sabes python te toca el grupo dos. Ya que controlas JavaScript pásate al equipo que diseña el frontal. Y como eres muy analítico, te vas al grupo de las bases de datos. Algo así ;)

En una arquitectura de micro-servicios los equipos se compondrán en función de las distintas funciones de negocio que tenga la aplicación.

La aproximación de una arquitectura de micro-servicios es completamente diferente, ya que los equipos se compondrán en función de las distintas funciones de negocio o aplicaciones concretas que tenga el sistema. De esta forma, la funcionalidad completa de la aplicación o del sistema global se partirá en funcionalidades mínimas. Y cada una de ellas se abordará de manera aislada desde una perspectiva de arquitectura y desarrollo. Hasta el punto en que los equipos de desarrollo puedan tomar decisiones aisladas sobre el lenguaje de programación o el sistema de almacenamiento a utilizar. Equipos multidisciplinares y heterogéneos en su composición, que los harán más ricos y capaces en su interacción diaria. Por lo tanto, cada una de estas partes tendrá una arquitectura de tres niveles. Pequeños sistemas resolviendo funcionalidades completas cuya suma dará lugar al sistema global.


La Cloud como dinamizador de este tipo de arquitecturas

Pero... ¿por qué la cloud pública dinamiza este tipo de arquitecturas? ¿Qué tiene que ver que una infraestructura esté en nube pública para que los microservicios sean de mayor interés?

Es normal que sólo parte de la infraestructura de una empresa sea posible trasladarla hoy a un proveedor de nube pública.

Piénsalo un poco. En el mundo del cloud público las infraestructuras están desperdigadas. Uno no sabe exactamente donde están las cosas. Aunque se habilite un servidor y una base de datos en la infraestructura de AWS (por ejemplo), seguramente ambas máquinas estarán muy distanciadas. Esto hace que la concepción del software tenga en cuenta que las cosas no están al lado unas de otras, como sucedía cuando todo estaba en el mismo servidor. En el mismo datacenter. Por otro lado, es normal que sólo parte de la infraestructura de una empresa sea posible trasladarla hoy a un proveedor de nube pública. Otra parte no será viable. Por muchas razones que suelen tener que ver con el punto de origen que tiene la empresa.


Y estas dos particularidades, sólo emergentes en el momento en que el cloud público adquiere protagonismo, provocan que una arquitectura por la que cada pieza pueda funcionar de manera independiente en distintos entornos, dan alas a un esquema y una filosofía como la que subyace detrás de los micro-servicios.


Muchas ventajas y, cada día que pasa, menos inconvenientes

Hablemos un poco sobre las ventajas de una arquitectura como ésta. Son muchas, pero yo me centraré en dos de ellas que, en mi opinión, son las más relevantes.


La primera ventaja es que este tipo de arquitecturas están diseñadas para el fallo. Con la idea de que las cosas fallarán. Si se piensa que todo puede fallar, uno está más preparado para ese fallo. Y los micro-servicios piensan que los de "al lado" pueden fallar. Y esto no debe afectarles a ellos. Y si lo hace, el impacto debe ser mínimo. Y con esa base de trabajo se desarrollan las partes de un sistema. Y esto los hace más fuertes al fallo. Más "resilientes".

Este tipo de arquitecturas está diseñado para el fallo y para ser evolucionados en funcionalidad de manera ágil.

La segunda ventaja tiene que ver con que se trata de diseños pensados en evolucionar lo más rápido posible. Si cada parte es evolucionable por sí sola, será más sencillo abordar las evoluciones y mejoras en cada una de las partes que en todo el sistema global. Si concibo una mejora clara en una de las partes, me centro en ella. El resto del sistema no se ve afectado y, por lo tanto, no se toca.


Pero... ¿es siempre bueno desarrollar software bajo esta arquitectura? Pues yo diría que no siempre, aunque cada día más. Porque, como ya te habrás dato cuenta, las ventajas que se consiguen bajo esta filosofía son tales, siempre y cuando el proceso de identificación de los procesos aislados sea óptimo y esté bien hecho. Y este proceso es complejo y no siempre necesario. Mucho del trabajo que, tradicionalmente se hacía en momento de código, ahora debe hacerse en la fase previa. Y esto lleva mucho tiempo. Y dependiendo de la aplicación podría no ser rentable esta inversión. Si mi sistema tiene una funcionalidad muy concreta, poco sentido tiene buscar funcionalidades secundarias, porque no se encontrarán. Por ello, esta tipología de servicios puede abordarse sin problema con arquitecturas monolíticas. Aunque cada día sea más complejo encontrar este tipo de aplicaciones de funcionalidad única o simple.


Las referencias empresariales trabajan con micro-servicios

Hoy en día son muchas las empresas que desarrollan su software partiendo de esta arquitectura. Con una aproximación de negocio que soportará mejor los fallos y las evoluciones futuras. Spotify, Amazon, Netflix o eBay son algunas de las referencias más nombradas al respecto por parte de los especialistas. En Internet encontrarás sus historias que provocaron cambios muy trascendentes en su forma de hacer las cosas y que, "curiosamente", las ha colocado en la primera línea del negocio.

Spotify, Amazon, Netflix o eBay son algunas de las referencias más nombradas cuando se habla de las arquitecturas de micro-servicios.

Hasta aquí llega lo que te quería contar de esto que todavía es un misterio en muchas cabezas. Porque contra toda lógica, que un servicio sea "micro" poco tiene que ver con que sea pequeño. Más bien tiene que ver con que sea parte de algo mayor. Que es diferente ;)


Pero si te has quedado corto con lo visto, en 2014 Martin Fowler escribió un post que todavía hoy, más de cuatro años después, sigue siendo la referencia para todo aquél que quiera saber de esto. Aquí tienes el link. No te lo pierdas, porque no tiene desperdicio y, siendo justos, lo cuenta bastante mejor que yo.

0 vistas
  • LinkedIn - Círculo Negro
  • Twitter - Círculo Negro
  • Facebook - Círculo Negro

Room714 © 2019

Madrid | Spain