Esta semana se hizo viral un artículo en el que el equipo de Amazon Prime Video hablaba sobre cómo redujeron el coste de su infraestructura un 90% al mover su arquitectura serverless basada en microservicios a una arquitectura monolítica.
El artículo generó muchísimo debate en internet incluyendo réplicas de DHH y de Kelsey Hightower conocido por la defensa de los monolitos y microservicios respetivamente.
Como es un tema en el que he podido tener cierta exposición, quería aprovechar la oportunidad para, una vez leído el artículo, aportar mi granito de arena a la discusión.
Empezar rápido y buscar fallos
Una de las ventajas que menciona el artículo es que pudieron crear el proyecto de manera rápida y reducir el plazo de lanzamiento (o time-to-market) usando la Lambda y Step functions.
Poder crear y lanzar algo de manera rápida es fundamental para saber, lo antes posible, cuanto nos estamos equivocando (porque siempre hay algo en lo que podemos mejorar). En el caso del equipo de Prime Video, descubrieron límites de escalabilidad de los servicios y que el coste era demasiado elevado.
Optimizar para coste
Cuando tenemos una arquitectura de microservicios, siempre vamos a tener un paso de mensajes que puede ser una llamada directa a un servicio o una cola de mensajes. Mientras más servicios, más mensajes, y este tráfico tiene un coste económico pero también de tiempo.
El equipo de Prime Video, además, estaba trabajando con ficheros binarios, en este caso imágenes. El procesamiento de estas imágenes requería almacenar y leer de S3, lo que implica además un coste de escritura y lectura.
Mover los microservicios a un monolito permite hacer los procesos en memoria, optimizando para coste y acelerando los procesos, ya que parte de ese tráfico de red desaparece.
Consolidar es más fácil si las responsabilidades están claras
Una de las ventajas que se menciona es que a la hora de consolidar el sistema en un monolito, la arquitectura prácticamente no sufró cambios ya que los componentes eran los mismos.
Cuando tenemos un sistema separado en diferentes componentes, si la separación de responsabilidades es correcta, traerlos a un monolito trae como resultado una reutilización de muchas partes del código.
La clave es correcta separación de responsabilidades tanto para microservicios como para monolitos, un microservicio no va a arreglar un monolito lleno de código espagueti, y un monolito no va a arreglar una infraestructura problemática.
Predictibilidad
Un punto que no se menciona en el artículo y una ventaja de sistemas serverless, es su uso cuando el tráfico es muy variable, y la facilidad para escalar puntualmente.
Cuando se tiene un flujo de tráfico predecible y constante, los sistemas serverless son más costosos y se pueden utilizar productos como instancias reservadas, que permiten una mayor reducción de costes.
Todo tiene su momento
2014 vio el lanzamiento de AWS Lambda, Kubernetes y la explosión del mundo serverless y microservicios. Desde entonces a lo largo de las redes hemos visto argumentos a favor y en contra de ambos sistemas.
Si algo ha demostrado el artículo y sus réplicas, es que hay espacio para arquitectura orientada a servicios y hay espacio para monolitos siempre que las consideremos como parte de nuestra caja de herramientas. Tendremos escenarios con poca predictibilidad y necesidad de validar rápidamente, y tendremos escenarios con alta predictibilidad y necesidad de ahorrar costes.
Nuestro objetivo como desarrolladores de software es crear soluciones que satisfagan las necesidades de los usuarios de nuestros sistemas. Las necesidades pueden cambiar con el tiempo, y tenemos que estar dispuestos a adaptarnos, aunque eso implique aprender nuevas técnicas, o volver a poner en práctica algunas que creíamos haber olvidado.
rlbisbe @ dev 