Capítulo 4. La analítica como pegamento secreto de las arquitecturas de microservicios
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Elias Nema
Recientemente, hemos visto un cambio importante hacia las arquitecturas de microservicios. Impulsado por las empresas de más éxito del sector, esto permitió a los equipos tener menos dependencias, moverse más rápido y escalar más fácilmente. Pero, por supuesto, también introdujo retos. La mayoría están relacionados con la naturaleza distribuida de la arquitectura y el mayor coste de la comunicación.
Se ha avanzado mucho para superar estos retos, sobre todo en los ámbitos de la observabilidad del sistema y las operaciones. El viaje en sí se trata como un problema técnico que hay que resolver. A menudo se pasa por alto la analítica como algo que no tiene relación directa con el diseño del sistema. Sin embargo, la naturaleza heterogénea de los microservicios constituye un caso perfecto para el análisis de datos.
Al fin y al cabo, así nacieron los almacenes de datos: como depósitos centrales de datos integrados procedentes de una o varias fuentes dispares. En una configuración distribuida, el papel de la plataforma analítica de toda la empresa puede ser inmenso. Veamos un ejemplo.
Imagina que tu equipo lanza una función. Realizas un experimento y observas que la función aumenta el indicador clave de rendimiento (KPI) objetivo de tu equipo. Es estupendo. ¿Deberías lanzarla para toda la base de usuarios? Claro, despliégalo, celébralo y vete a casa. Pero, ¿y si al mismo tiempo baja otro KPI de otro equipo? Esto puede ocurrir cuando canibalizas un canal o introduces cambios de comportamiento importantes en una plataforma. ¿Querrías lanzar esta función ahora?
Por supuesto, no hay una respuesta correcta a esto. Tampoco existe una plantilla de ningún tipo. Tomar una decisión requiere una planificación cuidadosa del experimento, la alineación de todo el equipo y la voluntad de hacer pequeños saltos donde sea necesario para que todo el sistema se mueva de forma óptima, no un solo componente. Disponer de datos proporciona una base común para estas decisiones, permite a las empresas hacer conjeturas fundadas y proporciona la capacidad de estimar el impacto. Sin datos, los equipos podrían caer en un círculo vicioso de tirar en direcciones diferentes, lo que daría lugar a mucho movimiento sin progreso.
Entonces, ¿en qué métricas debes pensar cuando inicies un nuevo proyecto o planifiques un experimento? Considera lo siguiente:
- Métricas de alto nivel de la empresa
- Son los más difíciles de mover, y rara vez se verán modificados por un solo experimento o característica. Es más probable que se alteren por el efecto compuesto de muchas iteraciones.
- Métricas del equipo
- Sí que quieres aumentar las métricas de tu equipo, pero el factor importante aquí es considerarlas en el contexto de formar parte de un sistema.
- Experimentos más granulares o métricas relacionadas con el proyecto
- Suelen venir a la mente cuando se diseña una función. Deben ser lo más detallados posible para que puedas medir el impacto directo y aislado.
Puede haber más métricas, dependiendo del proyecto. Sólo examinando varios niveles de detalle podrás tomar decisiones basadas en datos y tener fundamentos para comunicarlas.
Por eso, al adentrarse en la senda de los microservicios, una cultura analítica y de experimentación en toda la empresa debe ser uno de los requisitos previos, no una ocurrencia tardía. Una plataforma analítica rica puede convertirse en el pegamento que conecte elementos separados de un sistema. También te permite orquestar componentes débilmente acoplados para que se balanceen en la misma dirección.
Get 97 cosas que todo ingeniero de datos debe saber now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.