Caso de estudio Netflix:
De monolítico a microservicios
Caso de estudio Prime Video:
De microservicios a monolítico
El titular en inglés que causó mucho ruido y confusión:
«Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%»
Y cuando se lee el subtitular, confunde e impacta más.
«The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.»
Abordaré el tema desde tres (3) ópticas diferentes: Técnica, estratégica y de negocio.
La tecnología
Para empezar desde el punto de vista técnico o tecnológico: ¿Qué es una aplicación monolítica?
Este modelo es el tradicional, que hoy se puede clasificar como legacy, heredado o desactualizado. Justo por eso el artículo sobre Prime Video es interesante para entrar y comprender estos términos.
La arquitectura monolítica de un software o aplicación es la de donde todo se compila o se interpreta, según sea el caso como una entidad, como una unidad autónoma e «independiente».
Funciones y procedimientos: Aunque un software o sistema monolítico es una entidad o unidad, para mejorar su estructura, hay lenguajes de programación que evolucionaron y permitieron estructurarlo mejor.
Exiten una pieza de código principal (main) que llama a módulos, funciones o procedimientos que hacian tareas más pequeñas, pero al final, todo estaba en la misma unidad.
Un avance hacia la interdependencia.
La introducción de API´s ofrecidos por los sistemas operativos en los años 90´s permitía a los programadores acceder a funciones ya hechas, llamándolas desde el programa principal.
Ejemplo: En 1993, ya MS Windows ofrecía APIs para dibujar ventanas, botones con todas sus propiedades de movimientos de ese entonces sin tenerlos que programar, solo tenías que instalar el kit para desarrolladores, saber cómo se llamaba la función y pasarle los argumentos o parámetros.
La arquitectura de microservicios sería el siguiente nivel.
«Divide y venceras» Frase utilizada por el gobernante romano Julio Cesar y por el empreador de Francia, Napoleón Bonaparte.
Esta arquitectura se implementa de manera independiente, pequeña y manejable, tiene su propia lógica de negocio, puede estar asociada a una base de datos y hace una tarea, función o proceso específico y especializado.
Ejemplo: Se puede crear un software bajo la arquitectura de microservicios que haga un pago a PayPal, recibe los datos, procesa el pago y entrega un resultado en forma de documento, que sería la factura.
La diferencia con la arquitectura monolítica, es que no está dentro de la unidad, tiene su propia vida, personalidad, lenguaje de programación y comportamiento.
Es como la función o procedimiento de un monolítico, pero separado y más interdependiente, con maneras diferentes de interconectarse con otras piezas de software que deseen de su servicio.
Caso Netflix
Es imposible hablar de microservicios sin hablar de Netflix, ¿Por qué?
Porque el primer stack de microservicios que se dio a conocer, o que alcanzó popularidad fue el stack de Netflix.
Fue adoptado por Spring (un framework de java de la empresa spring.com) como su solución para el cloud, lo llamaron: «spring-cloud-netflix» y vio la luz en 2015, el mismo año que el concepto de microservicios empezó a sonar con fuerza en España.
Descubra un poco más: Otras tecnologías alrededor del stack de «spring-cloud-netflix»: Sprint Cloud Consul (descubrimientos de microservicios), Eureka (registro de microservicios), Zuul (librería o API gateway), Ribbon (Balanceador de cargas), Docker (solución de contenedores) y Openshift3 (orquestación de contenedores)
La estrategia:
Este tema puede aburrir a los desarrolladores, a los DevOps y a otros, pero para para algunos roles tiene que ser un tema digno de analizar con cuidado.
Vale la pena acotar, que Netflix empezó con una arquitectura monolítica, pero en 2009 se vio en problemas de crecimiento, era imposible seguir el ritmo de la demanda de sus servicios de streaming.
Así que decidieron migrar su infraestructura de sus centros de datos on-premise a la cloud pública y también decidieron migrar de su arquitectura monolítica a la de microservicios.
Este caso real nos deja una lección práctica: Cuando los monolitos crecen demasiado, puede que sea el momento de migrar a microservicios.
No es una regla, ni un estándar, debe analizarse y evaluarla como parte de la estrategia, ya que no hay nada escrito y cada negocio, cada caso es diferente y particular.
El caso de Amazon Prime Video lo ejemplifica muy bien, ellos decidieron cambiar uno de sus microservicio a la arquitectura monolítica.
También dieron un giro a la aquitectura subyacente, pasaron de AWS Serverless/Lambda a EC2 y ECS
¿Qué? Leyeron bien, ¿Cuál fue la razón?
El subtitular lo explica: Mayor escalabilidad, resiliencia y reducción de costos.
Este cambio nos deja otra lección práctica: Lo último en tecnología, lo de moda, lo sofisticado no siempre es la mejor solución para un caso específico.
La solución inicial bajo la arquitectura de microservicios que se montó sobre AWS Step Functions y AWS Lambda, luego migraron a una arquitectura monolítica de un solo proceso con Amazon Elastic Compute Cloud (EC2) y Amazon Elastic Container Service (ECS) para la implementarla.
Esta decisión fue acertada estratégicamente hablando, ¿Por qué? Por que inicialmente les permitió construir el servicio rápidamente y de menor complejidad utilizando alta tecnología, además que estaba alineada con la estrategia de un MVP.
Para entender mejor el MVP de Prime Video, consulte el 2do caso de emprendimiento en el siguiente artículo:
El negocio
Lo que impulsó a re-evaluar la arquitectura fueron los costos de ejecución, seguro te suena familiar, la estrategia y la tecnología parece que siempre está asociada a una tercera variable, los costos.
Lo primero que debemos entender de los microservicios y que también se aplica a la virtualización, es que en muchos casos los costos dependen del volumen o del consumo de componentes computacionales.
Las empresas y startups necesitan validar un nuevo producto o servicio, saber si tiene demanda, si se puede masificar, y para esto es muy importante hacerlo rápido y barato, pero pensando en grande una vez validado.
Eso quiere decir que se puede contratar servicios de muy alta calidad a precios accequibles cuando nuestro servicio o producto tiene poco consumo o volumen, justo fue el caso de usar AWS Step Functions y AWS Lambda.
¿Pero qué pasa cuando el servicio se valida, es un éxito, se empieza a consumir de manera masiva rápida?
Los costos de ejecutar esa pieza de software se vuelve muy costoso, así que hay que sentarse para re-definir la estrategia, y justo eso fue lo que pasó, y eso fue justo lo que hicieron, implementar la arquitectura monolítica.
Para profundizar más: A continuación los artículos consultados para armar y filtrar la información para los colegas.
https://www.infrastructureposts.com/p/e7-thoughts-on-scaling-up-the-prime
https://www.linkedin.com/pulse/scaling-up-prime-video-audiovideo-monitoring-service-reducing-larry/
https://www.atlassian.com/es/microservices/microservices-architecture/microservices-vs-monolith
https://juanjoblog.com/2020/12/02/la-ingenieria-detras-de-netflix-parte-i/
