Feature Flags en Arquitectura MACH: Releases Controlados y Experimentacion Continua

Los Feature Flags, también conocidos como Feature Toggles o Feature Gates, son una práctica de ingeniería que tiene un gran impacto en la velocidad y seguridad del ciclo de desarrollo en arquitecturas MACH. Permiten desacoplar el despliegue de código del lanzamiento de funcionalidades, lo que significa que el código puede estar disponible en producción pero desactivado para todos los usuarios.

Esto permite activar la función de forma progresiva y controlada sin requerir un nuevo despliegue. En una arquitectura MACH, donde los microservicios se despliegan de forma independiente varias veces al día, los Feature Flags son un mecanismo que permite a los equipos avanzar con confianza, realizar experimentos A/B y hacer rollbacks instantáneos cuando algo sale mal.

Martin Fowler ha clasificado los Feature Flags en cuatro tipos basados en su duración y propósito. En el contexto de MACH, cada tipo tiene un caso de uso específico.

1. Release Flags (Lanzamiento Controlado): Son el tipo más común y permiten desplegar código nuevo en producción con la funcionalidad desactivada. La funcionalidad se activa progresivamente, primero para el equipo interno, luego para un 5%, 25% y finalmente para todos los usuarios. Si se detectan errores o degradación de performance en ningún punto, el flag se desactiva instantáneamente.

2. Experiment Flags (A/B Testing): Similar a los Release Flags, pero diseñados para experimentos estadísticamente validos. La asignación de usuarios a cada variante debe ser estable y determinista para garantizar la validez estadística del experimento. Esto se logra mediante una función de hash del user_id y experiment_id, lo que garantiza asignaciones consistentes y uniformes.

3. Ops Flags (Flags Operacionales): Son flags de larga duración que controlan el comportamiento del sistema en situaciones operacionales específicas. Pueden activar el modo de mantenimiento, desactivar temporalmente sistemas de recomendaciones en caso de mantenimiento de la base de datos de ML o activar rate limiting más agresivo durante eventos de alto tráfico como Black Friday o Cyber Monday. Estos flags son críticos para la resiliencia de la plataforma.

4. Permission Flags (Flags de Permiso): Controlan el acceso a funcionalidades basadas en atributos del usuario o del tenant, como el plan de suscripción, segmento geográfico o participación en un programa beta. Son de larga duración y están estrechamente ligados al modelo de negocio. Por ejemplo, solo los tenants en plan Enterprise pueden acceder a un modulo de reportes avanzados con exportación a BigQuery.

En una arquitectura MACH, la plataforma de Feature Flags debe ser un servicio centralizado consultado por todos los microservicios. Las opciones principales son plataformas SaaS como LaunchDarkly, Split.io y Flagsmith, que ofrecen dashboards avanzados de gestión y capacidades de targeting, pero con el inconveniente del costo y dependencia de un servicio externo.

Open-source alternatives como Unleash y Flipt pueden ser hosteados en el propio cluster de Kubernetes, ofreciendo las capacidades básicas de feature flags sin el costo de las plataformas SaaS.

Sin importar la plataforma elegida, el patrón de implementación es el mismo: el SDK del Feature Flag se inicializa al arrancar el microservicio, descarga los flags del servidor de configuración y mantiene una cache local en memoria que se actualiza periódicamente o a través de webhooks. Las evaluaciones de flags son siempre locales, con una latencia sub-microsegundo utilizando esta cache, sin llamadas remotas en cada request.

La evaluación de un flag consiste en un lookup de diccionario y una evaluación muy rápida, menor a 1 microsegundo en la mayoría de las implementaciones.