Hace casi ya dos meses que Amazon publicó en su blog sobre los problemas que tuvieron con una herramienta cuya función era monitorear cada transmisión de video (vista por sus clientes). Eventualmente la arquitectura utilizada les generó problemas de escalabilidad y costos, la fuente del problema residía en la arquitectura de microservicio basada en funciones orquestadas por AWS Step Functions.
Esto se connvirtió en una penuria debido a que generaba cuellos de botella y altos costos por la manera en que funcionan estos microservicios de funciones dado que estas son almacenadas en un repositorio y son llamadas y ejecutadas bajo demanda (aquí la raíz del problema).
La justificación del uso de este tipo de funciones es que a diferencia de la arquitectura tradicional estas no están encendidas el 100% del tiempo en el servidor si no que se despliegan según la demanda pero en realidad lo que esto hace es, a mi parecer, más desperdicio de recursos ya que estos programas simples se tienen que obtener de la fuente, desplegar y destruir una vez lleven a cabo su cometido y esto por cada solicitud que exista; en teoría suena bonito pero en la práctica se ve más como un esquema de enriquecimiento para los proveedores de este tipo de servicios y es que a la larga es realmente más costoso (tanto más que mismo Amazon disitió de esta arquitectura) que resultaría mucho más práctico y barato utilizar hasta un VPS de 5 USD en el cual se alojarían todas las funcionalidades que se requieran por una empresa a forma de API (y redimiensionar este VPS conforme la demanda crezca).
A este tipo de escenarios me refería cuando escribí Análisis versus fé ciega a los oráculos big tech del software y en breve lo que quería decir en ese artículo, a resumidas cuentas, es que el programador no debe seguir las tendencias de la industria solo por el mero hecho de que gurús o líderes de las grandes empresas lo digan, por el contrario, uno debe plantarse, analizar y estar dispuesto a contradecir a los “grandes” no por ego si no por ética ya que nuestro trabajo con nuestros empleadores debe de ser, a medida de lo posible, de la mayor calidad posible para el mayor provecho de la empresa y bajo el menor costo de mantenimiento y actualización. Este suceso en Amazon me da la razón.
Pero más allá de infraestructura Amazon decidió por un cambio total de arquitectura ¿por qué? es más fácil mantener un monolito cuya funcionalidad ya está muy clara y delimitada que mantener una serie de servicios interconctados entre sí y por llamadas de todo tipo (RPC, REST, etc), la complejidad en realidad se aumenta y lo que buscamo es precisamente la reducción de la complejidad.
La arquitectura de microservicios es totalmente válida y en lo personal me agrada, pero depende de los casos, pero cuando hablamos de sistemas cuya finalidad ya es muy clara y que a su vez depende de varias etapas de procesamiento entonces sí, un monolito pueda ser de ayuda (más aún un monolito modular).
Así lo que pasó a ser desdeñado (monolito) por los “expertos” ahora parece hacer un regreso (y no es lo único que está regresando ya que también hay un movimiento para traer el hypermedia de vuelta y me refiero al movimiento de Carson Gross con https://htmx.org/ y con el cual coincido debo añadir).
Ahora, si quieres saber de que va el artículo al que hago referencia aquí te dejo un breve resumen del mismo, pero también te recomiendo leerlo y tomar tus propias conclusiones.
El artículo titulado “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%” explica cómo Prime Video logró mejorar la escalabilidad y reducir los costos de su servicio de monitoreo de audio y video. Aquí tienes un resumen:
Prime Video desarrolló una herramienta para monitorear cada transmisión de video vista por sus clientes, con el objetivo de identificar automáticamente problemas de calidad perceptual y solucionarlos. Sin embargo, al aumentar la cantidad de transmisiones, se enfrentaron a desafíos de escalabilidad y costos.
En la versión inicial del servicio, utilizaban una arquitectura de microservicios distribuidos orquestados por AWS Step Functions. Sin embargo, esto resultaba costoso en términos de infraestructura y transferencia de datos. Para abordar estos problemas, decidieron migrar a una aplicación monolítica.
La nueva arquitectura eliminó la necesidad de almacenamiento intermedio en un bucket de Amazon S3 y permitió que la transferencia de datos se realizara en la memoria. Todos los componentes se ejecutaban dentro de un solo proceso, lo que simplificó la lógica de orquestación. Utilizaron instancias escalables de Amazon EC2 y Amazon ECS para el despliegue.
En la arquitectura inicial, la gestión de la orquestación con AWS Step Functions se convirtió en un cuello de botella y generaba altos costos por las transiciones de estado. Además, el paso de imágenes de video entre los componentes también resultaba costoso debido al alto número de llamadas al bucket de S3.
La migración a una aplicación monolítica resolvió estos problemas y permitió reducir los costos en más del 90%. Los componentes se ejecutan dentro de una sola tarea de Amazon ECS, y la compartición de datos se realiza en la memoria. Para escalar verticalmente los detectores, replicaron el servicio y parametrizaron cada copia con un subconjunto diferente de detectores. Implementaron una capa de orquestación ligera para distribuir las solicitudes de los clientes.
Estos cambios permitieron a Prime Video monitorear todas las transmisiones de video de sus clientes, mejorando la calidad y la experiencia del cliente. Además, la migración a Amazon EC2 y Amazon ECS les permitió utilizar planes de ahorro de cómputo de Amazon EC2 para reducir aún más los costos.
En resumen, Prime Video logró escalar su servicio de monitoreo de audio y video y reducir los costos al migrar de una arquitectura de microservicios distribuidos a una aplicación monolítica. Esto les permitió manejar miles de transmisiones y mejorar la calidad y experiencia del cliente, al tiempo que reducían significativamente los costos.
21 May 2023, @VictorianoGrza