Telecom Argentina
Una plataforma OTT que funcionaba todos los días del año, menos los que de verdad importaban.
Stack
- Microservicios
- Event-driven architecture
- Sistemas distribuidos
- AWS
- Migración cloud
- Streaming OTT
Problema
La plataforma de streaming OTT corría on-premises y aguantaba bien la carga ordinaria. La carga ordinaria no era el problema. La peor hora de la plataforma y su hora más valiosa eran la misma: un partido de fútbol importante, donde todos los suscriptores del país llegan dentro del mismo minuto y se quedan noventa. La latencia subía justo cuando la audiencia era más grande y menos indulgente, y los cuellos de botella eran estructurales: un origen y una capa de entrega que no podían escalarse de forma independiente, dimensionados para un promedio que al negocio no le importaba.
Enfoque
Esto fue un trabajo de consultoría y preventa, así que hice una evaluación de punta a punta en vez de empezar por una propuesta: la arquitectura de la plataforma, el ciclo de vida de entrega de software y los flujos críticos de negocio alrededor de los eventos en vivo. Leer el pipeline de entrega importaba tanto como leer la topología: una plataforma que no puede desplegar un arreglo durante el partido tiene un problema de entrega disfrazado de arquitectura. La recomendación fue una migración cloud-native a AWS con microservicios distribuidos y patrones event-driven, secuenciada para que lo que carga el tráfico en vivo se moviera primero y el resto siguiera por evidencia.
El compromiso
Las ganas en la sala eran de rehacerlo: una plataforma limpia, diseñada para el pico, migrada de una sola vez. Argumenté en contra, y el argumento me costó algo de entusiasmo ajeno. Un corte de golpe habría apostado a una hipótesis la fecha de entrega de un sistema cuyo propósito entero es un calendario fijo de eventos en vivo. La migración por fases es más lenta, y significa convivir con dos plataformas y una costura de integración más tiempo del que nadie quiere. También significa que la temporada no depende de que la reescritura aterrice.
Impacto
Evaluación aprobada · siguiente fase de la transformación financiada
- Evaluación arquitectónica de la plataforma OTT on-premises entregada de punta a punta — topología, ciclo de entrega y los flujos críticos de negocio en eventos en vivo
- Cuellos de botella de escalabilidad, latencia y operación en la entrega de contenido en vivo identificados y rastreados hasta sus causas estructurales
- Estrategia de modernización cloud-native diseñada — de on-premises a AWS, microservicios distribuidos, patrones event-driven
- Patrones arquitectónicos propuestos para reducir la latencia de streaming de punta a punta bajo tráfico concurrente masivo
- Visión arquitectónica y roadmap presentados a los stakeholders del cliente, asegurando la aprobación de la siguiente fase — una evaluación de consultoría y preventa, no una plataforma que yo haya construido después
Lo que aprendí
El entregable acá fue una decisión, no un sistema. Me tomó un tiempo poder decirlo sin pedir disculpas. Esto fue consultoría y preventa: entregué la evaluación, la arquitectura y el roadmap, y los dejé en sus manos — el desarrollo que vino después no fue mío. Una evaluación que termina en un roadmap aprobado hizo todo su trabajo: lo que importa es acertar dónde se rompe la plataforma y ser honesto sobre lo que cuesta arreglarla. También aprendí a mirar el proceso de release antes que el diagrama de arquitectura. El diagrama te dice cómo se pretendía que el sistema funcionara. El proceso de release te dice cómo funciona de verdad.