DOMA es el enfoque que tomó Uber, con 2,200 microservicios, para reducir la complejidad sin perder la flexibilidad de una MSA
-
Diseñado tomando ideas de DDD, SOA, OO, CA, etc., y adaptándolas a sistemas distribuidos a gran escala en organizaciones grandes
-
Un artículo que condensa la larga experiencia de Uber operando MSA durante bastante tiempo
Principios básicos de DOMA
-
Agrupar microservicios como colecciones por dominio
-
Crear colecciones de dominios llamadas Layer, permitiendo dependencias dentro de cada capa → Layer Design
-
Crear un Gateway que provea una interfaz limpia como punto único de entrada para cada colección
-
Cada dominio debe ser independiente de los demás. Pero como a menudo necesita incorporar lógica de otros dominios, se ofrece una arquitectura de Extension que lo soporta bien
** Implementación de Uber
- Domains
→ Conjunto de uno o más microservicios agrupados lógicamente.
→ Un dominio puede tener más de 10 servicios, o puede tener solo uno
→ Ej) búsqueda de mapas, tarifas, plataforma de matching (pasajeros y conductores) son un dominio cada uno
→ No sigue la estructura organizacional de la empresa, así que la organización relacionada con mapas en Uber está compuesta por 3 dominios, 80 microservicios y 3 gateways
- Layer Design
→ Responde a la pregunta: "¿Qué servicios pueden llamar a otros servicios?"
→ "separation of concerns at scale" o "dependency management at scale"
→ Uber lo compone en 5 Layers
→ 1. Infrastructure : funcionalidades que toda la organización puede usar. Almacenamiento, networking, etc.
→ 2. Business : funcionalidades utilizables a nivel de negocio. No se limitan a una categoría de producto específica ni a una LOB (Line Of Business) como Rides, Eats o Freight
→ 3. Product : funcionalidades relacionadas con una categoría de producto o LOB específica, pero también cosas compartidas entre varias apps como "Request a ride"
→ 4. Presentation : funcionalidades relacionadas con aplicaciones orientadas al usuario (móvil / web)
→ 5. Edge : exposición segura de los servicios de Uber hacia el exterior. También se integra con aplicaciones móviles
- Gateways
→ No es muy distinto del API Gateway de microservicios. La diferencia es que se considera un punto único de entrada (Single Entry-point) conectado al Domain
→ Como internamente se obtiene una única dependencia con el exterior, se reducen en general la migración, el descubrimiento y la complejidad del sistema
- Extensions
→ Mecanismo para extender dominios sin cambiar la implementación del servicio ni afectar su estabilidad
→ 1. Extensión de Logic : expandir la lógica del servicio usando patrones Provider o Plugin
→ 2. Extensión de Data : mecanismo para adjuntar datos arbitrarios y evitar que crezcan los datos core. Usa el tipo Any de Protobuf
→ 3. Extensión Custom : cada equipo extiende con el patrón más adecuado para su dominio
El tiempo de onboarding se redujo entre 25% y 50%
Se separaron 2,200 microservicios en 70 dominios.
En Uber se calculó que la vida media de los microservicios es de 1.5 años. Es decir, cada 1.5 años desaparece el 50% de los microservicios
Sin gateways, cada vez que esto ocurre se desata un infierno de migraciones.
En Uber se comprobó que las plataformas diseñadas con DOMA son mucho más fáciles de escalar y mantener.
Consejos prácticos para otras empresas
- Startups :
→ Son importantes preguntas como: "¿Cuándo deberíamos adoptar MSA?" y "¿Le sirve a nuestra organización?".
→ MSA tiene ventajas operativas en organizaciones con muchos ingenieros, pero también aumenta la complejidad y puede volver más difícil desarrollar funcionalidades
→ En organizaciones pequeñas, podría traer solo un aumento de complejidad arquitectónica sin beneficios operativos, e incluso mayores costos.
→ También es viable introducirlo lentamente, y si se decide avanzar hacia MSA, hay que pensarlo como un "programa distribuido a gran escala" y separar bien los microservicios entre sí.
→ Es importante que los primeros microservicios describan funciones clave del negocio y que duren mucho tiempo
- Empresas medianas :
→ Cuando la empresa se divide en varios equipos y empiezan a divergir los intereses entre plataformas, MSA se vuelve más útil
→ En esta etapa se puede empezar a considerar una estructura por capas entre microservicios, y como más servicios los usan, la gestión de dependencias se vuelve importante
→ Como todavía no hay tantos microservicios, el clustering puede no tener mucho sentido, pero pensar de forma orientada al dominio sí es útil
- Empresas grandes :
→ En organizaciones de ingeniería a gran escala, con cientos de ingenieros, microservicios y dependencias, DOMA resulta plenamente útil
→ Es fácil agruparlos en dominios con gateways, y los gateways también son útiles al refactorizar o reescribir sistemas legacy
En Uber, cada vez más equipos están adoptando DOMA gradualmente. (Dicen que unas 60 personas de todas las organizaciones de Uber participaron juntas durante 2 años para crearlo)
5 comentarios
https://eng.uber.com/microservice-architecture/
Ahora parece verse bien... pero creo que en lo que está en la máquina Wayback las imágenes se ven un poco diferentes.
Ah, ya volvió a la vida jaja. Lo dejé restaurado.
Parece que el problema era la imagen en la que se veía el nombre detallado del servicio.
Parece que borraron el artículo T.T
Vaya, sí, así parece. Por lo pronto, se puede ver en la Wayback Machine.
https://web.archive.org/web/20200803012939/…
Gracias :)