Tabla de contenidos
¿Es el servidor monolítico el futuro? ¿Son los monolitos the next big thing? ¿Por qué razones puede tener sentido pasar de los innovadores microservicios al sistema monolítico de toda la vida?
Estas preguntas pueden sonar a broma, pero no lo son. Ya sabemos que en el mundo IT, como en la moda textil, hay ciclos. Pero, como veremos a través de una experiencia de la plataforma de streaming Prime Video, más que de ciclos, hay que hablar de las tallas y de las costuras que, en términos de servidores, mejor se ajustan a una necesidad empresarial y tecnológica.
Arquitectura de microservicios serverless: no para todo el mundo
Un caso de estudio difundido por Prime Video (Amazon) demuestra que la arquitectura de microservicios serverless no siempre es la mejor opción, incluso para Amazon, el gigante IT pionero y abanderado de los microservicios. Es decir, que la arquitectura orientada a servicios, en su versión microservicios, no siempre es óptima en términos de eficiencia de procesos, costes operativos y escalabilidad. Así que muchísimas veces puede tener todo el sentido adoptar (o regresar a) la arquitectura tradicional, el monolito.
La arquitectura orientada a servicios subdivide una aplicación en muchas partes pequeñas, ejecuta cada una de estas partes como su propia aplicación, y luego hace posible que esa constelación de partes haga el trabajo para el que habías diseñado la aplicación.
Adopción del sistema monolítico en Prime Video con ahorros del 90%
El equipo de Análisis de Calidad de Vídeo (VQA) de Prime Video monitoriza a través de una aplicación la calidad de audio y vídeo de sus streams. En caso de detectar fallos perceptibles por el usuario (corrupción de bloques, problemas de sincronización de audio/vídeo), estos procesos de inspección desencadenan las acciones de reparación pertinentes. Amazon ofrece hoy más de 30.000 streams (películas y otros archivos de vídeo) en su plataforma de streaming.
A través de un post, Marcin Kolny, ingeniero de software de este equipo humano, ha explicado los problemas con los servidores de la mencionada herramienta de monitorización de los streams. Así, ha compartido la mala experiencia con los microservicios —de los que la matriz Amazon ha sido precursora—, y ha descrito el camino que han seguido hacia una efectiva solución de servidores de monolito.
Gracias a este cambio de arquitectura, Prime Video ha conseguido las siguientes mejoras:
- Reducción del 90% de los costes operativos de la infraestructura de servidores del equipo de VQA de Prime Video.
- Garantía de ahorros de costes futuros gracias a los planes de ahorro de Amazon EC2 (la solución de servidores actual está en Amazon EC2 y Amazon ECS).
- Mayor capacidad de escalabilidad, que va a permitir que este equipo de calidad de Prime Video pueda gestionar e inspeccionar todos los streams (películas, capítulos de series, etc) a disposición de los clientes/espectadores. Hasta ahora, Prime Video daba prioridad a los archivos de vídeo con más visualizaciones, lo que iba en detrimento de la experiencia de usuario de quienes consumen contenidos audiovisuales más minoritarios en la plataforma.
- Mayor simplicidad y eficiencia del flujo de trabajo de la herramienta del equipo de calidad de Prime Video.
Lecciones del mundo del streaming para toda la industria IT
Las lecciones que se pueden extraer de este testimonio no son exclusivas del mundo del streaming, sino que se pueden aplicar a todo el sector tecnológico. Hace ya años que hay un debate sobre los riesgos —económicos y técnicos— de tomar decisiones sobre servidores más por modas, por hype o por seguidismo de lo que las grandes empresas de éxito hacen, que por necesidades reales de los proyectos.
Marcin Kolny lo resume así: «Los microservicios y los componentes serverless son herramientas que funcionan a gran escala, pero la decisión de utilizarlos en lugar de monolitos debe tomarse caso por caso».
Prime Video: arquitectura inicial con componentes distribuidos y servicios serverless
¿Cómo era la solución inicial de la herramienta para revisar la calidad de audio y vídeo de los streams? Se trataba de un sistema de componentes distribuidos orquestados por servicios serverless (AWS Step Functions o AWS Lambda) para así conseguir unos tiempos de implementación más rápidos.
La arquitectura inicial de la solución se basaba en microservicios, que se encargaban de ejecutar diferentes pasos del proceso de análisis global de los streams. Todo ello, sobre un stack de infraestructura de servidores serverless.
Estos microservicios…
- Dividían los streams de audio/vídeo en fotogramas de vídeo o búferes de audio descifrados.
- Detectaban defectos en los streams, a través del análisis con algoritmos machine-learning de fotogramas y búferes de audio.
Luces de alarma con los microservicios de Prime Video: altos costes y cuellos de botella
La teoría decía que iban a poder escalar cada componente del servicio de forma independiente. Pero el diseño nunca se hizo pensando en un funcionamiento a gran escala. De modo que, cuando se incorporaron más streams a la aplicación, detectaron tres problemas:
- Costes. ¡Aumentaron los costes! «Ejecutar la infraestructura a gran escala resultaba muy caro». Las operaciones con una factura más alta eran la orquestación del flujo de trabajo y el paso de los datos entre los componentes distribuidos.
- Cuellos de botella. «Cuellos de botella que nos impedían supervisar miles de streams». La arquitectura inicial solo pudo soportar un 5% de la carga prevista.
- Escalabilidad. Los componentes de Amazon Web Services eran un obstáculo para la escalabilidad.
Sin prejuicios y con una actitud analítica, tomaron distancia con la solución entonces existente para revisar la arquitectura. El objetivo era bajar costes y suprimir los cuellos de botella.
De microservicios distribuidos a una aplicación monolito
El equipo de calidad de Prime Video concluyó que el sistema distribuido era un mal enfoque, así que trasladaron todos los componentes a un único proceso.
Los beneficios inmediatos de este cambio de modelo fueron:
- «Mantener la transferencia de datos dentro de la memoria del proceso, lo que a su vez simplificó la lógica de orquestación».
- «Como compilamos todas las operaciones en un único proceso, pudimos recurrir para el despliegue a las instancias escalables Amazon Elastic Compute Cloud (Amazon EC2) y Amazon Elastic Container Service (Amazon ECS)».
Conceptualmente, la arquitectura era la misma. Así que los componentes —conversión de streams, detectores, orquestación— eran los mismos. Gracias a ello, se reutilizó mucho código a la hora de migrar hacia el nuevo sistema de servidores.
La aplicación monolito actual para analizar la calidad de los streams de Prime Video ha permitido reducir costes, acabar con los cuellos de botella y facilitar la escalabilidad. Además, ahora el equipo de calidad de la plataforma de streaming puede monitorizar todos los streams, y no solo los que tienen más visualizaciones. La calidad global y la experiencia de usuario han mejorado.
La «locura» de los microservicios
Este cambio de Prime Video desde microservicios a monolito ha dado que hablar en la comunidad IT.
David Heinemeier Hansson, creador del framework Ruby on Rails y empresario tecnológico, ha analizado la decisión de Prime Video en un artículo de su blog. En el post califica de «locura» al mal uso que muchas empresas están haciendo de los microservicios. Para este emprendedor, la «locura» se hace muy evidente con el límite en torno al 5% de la carga prevista en la arquitectura original de la aplicación de análisis de streams de Prime Video.
Según Heinemeier Hansson, «[…] en la práctica, los microservicios son quizás el mayor canto de sirena para complicar de forma innecesaria tu sistema. Y serverless lo que hace es empeorar aún más las cosas».
Para él, la arquitectura orientada a servicios tiene sentido para las escalas de trabajo de empresas muy grandes. Con equipos con miles de programadores, la labor de desarrollo puede ser así más eficiente. Para las grandes corporaciones puede ser bueno que cada servicio pueda ser su propio equipo, con su propio timeline, staff de desarrolladores, y objetivos.
«Pero, como ocurre con muchas buenas ideas, este patrón se volvió tóxico en cuanto se adoptó fuera de su contexto original, y causó estragos en cuanto se introdujo en el interior de arquitecturas de aplicación única. Así es como llegamos a los microservicios».
En su opinión, «los microservicios son una arquitectura zombi, desde muchos puntos de vista».
En términos generales, este emprendedor cree que los equipos de desarrollo cohesionados, no demasiado grandes, trabajan mejor con el monolito que con una «arquitectura orientada a micro-servicios».
