En este muy recomendable artículo del equipo de ingeniería de Uber, se muestran algunas experiencias bastante valiosas dada la trayectoria de la compañía en la implantación de este tipo de arquitectura. Una experiencia que si bien ha sido positiva por las ventajas que ofrece el uso de este paradigma de diseño, también ha traído algunos problemas… problemas que les han llevado a evolucionar la arquitectura a lo que ellos llaman DOMA (Domain-oriented Microservice Architecture).

La T.I. de Uber ha crecido hasta tener más de 2.200 microservicios críticos. Microservicios que se fueron implementado a partir de 2012-2013 debido a los problemas que presentaban dos grandes monolitos que tenían en ese momento. Los problemas que querían resolver con esta nueva aproximación eran estos:

  1. Riesgo de indisponibilidad
  2. Despliegues caros y con riesgo
  3. Poca separación de responsabilidades, al tener un gran base de código.
  4. Dificultad para que los equipos trabajen de forma autónoma e independiente

Sin embargo, a pesar de los beneficios del uso de microservicios, con el crecimiento tan tremendo que ha experimentado la compañía, pasando de cientos a miles de ingenieros, la cosa se complicó bastante. La complejidad del sistema creación en el mismo orden o más que el número de miembros del equipo, reportando que “los ingenieros tenían que trabajar a través de 50 servicios de 12 equipos diferente para investigar la causa raíz de un problema”.

¿Cuál es el cambio que trajo la aplicación de DOMA en Uber?

Los cuatro cambios más importantes, tal como se citan en el artículo, fueron los siguientes:

  1. En lugar de orientarse a tener microservicios separados, se orientaron a tener una colección de microservicios relacionados, es decir, en dominios de negocio.
  2. A su vez, crearon conjuntos de dominios a los que llamaron layers. Esta capa a la que pertenece el dominio nos dice que dependencias puede tener los microservicios de dentro de ese dominio. A esto lo llamaron layer design.
  3. Proporcionan interfaces bien definidos para los dominios que se tratan como un punto único de acceso a la colección, un especie de fachada o puerta de entrada, a la que han llamado gateways.
  4. Por último, establecieron que cada dominio debe ser agnóstico respecto a otros dominos. Esto quiere decir que un dominio no debe tener lógica relacionada con otro dominio en su código o modelos de datos.

Con esto lo que han pretendido es simplificar la arquitectura, tomando como «unidad» de cara a la compresión del sistema al dominio en lugar de al microservicio concreto.

Cómo se implementa

Dominios (domains)

Representa una colección de uno o m´s microservicios relacionados funcionalmente. No hay una regla sobre el tamaño de los dominios. Según Uber un dominio puede tener decenas de servicios y otro dominio un único microservicio.

Layer Design

Responde a la cuestión ¿qué servicio puede llamar a qué otro servicio?. Se puede ver este diseño de capas como una gestión de dependencias a escala de toda la organización.

Además, nos da una idea sobre cómo es el área de afectación de un fallo y de las dependencias de un dominio.

Según la figura, se puede pensar en las capas de arriba como experiencias de usuario específicas (ponen el ejemplo de las funcionalidades para el móvil), y las de abajo como funcionalidad de negocio generales.

¿Y qué capas se han definido en Uber? son estas.

  1. Infraestructura, como lo referido al almacenamiento y al networking. Potencialmente cualquier equipo puede usarlas.
  2. Negocio. Con la funcionalidad que se puede usar como organización, no es específica de un categoría de productos particulares o de una línea de negocio.
  3. Producto. Con la funcionalidad relacionada con un producto específico o línea de negocio, pero es independiente de la aplicación móvil, por ejemplo.
  4. Presentación. Características directamente relacionadas con el usuario
  5. Edge. Expone los servicios de manera segura al mundo exterior.

Gateways

Se refieren a este concepto exclusivamente como un punto único de entrada en la colección de los microservicios que hay en el dominio.

Los gateways proporcionan varias ventajas, entre ellas facilitar las futuras migraciones, descubrimiento de los servicios y la reducción de la complejidad del sistema.

Extensiones

Se refiere a un mecanismo para extender los dominios, proporcionando un mecanismo para extender la funcionalidad de un servicio sin cambiar la implementación actual del servicio y sin impactar en su fiabilidad.

Las extensiones puede ser de tipo lógica o de datos.

Extensiones lógicas

Se utiliza para extender la lógica de un servicio a modo de plugin, basado en un interfaz del servicio del tipo que existe en lenguajes orientados a objetos como Java.

Extensiones de datos

Proporcionan un mecanismo para añadir datos a un interfaz sin afectar a los modelos de datos del core del sistema.

Conclusión

Creo que merece la pena, al menos, tener en cuenta lo que han hecho en Uber para escalar el software de la compañía dada su experiencia en la arquitectura de microservicios donde han sido verdaderos pioneros. No es lo mismo hacer una aplicación pequeña con uno o dos dominios que implementar el core de la compañía.