Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
La elección de la arquitectura de infraestructura no es una cuestión de superioridad técnica, sino un cálculo matemático basado en perfiles de tráfico. Un ejemplo representativo es el caso del equipo de operaciones de Amazon Prime Video, que enfrentó una "bomba de costos" tras distribuir un servicio de monitoreo de calidad de video en múltiples AWS Lambda y Step Functions. A medida que el tráfico aumentaba, los costos de transición de estado se dispararon linealmente, por lo que consolidaron la lógica en procesos en memoria dentro de nodos de computación únicos y realizaron una migración inversa a un entorno de contenedores Amazon ECS. El resultado fue una reducción del 90% en la factura total de infraestructura.
El punto de equilibrio de costos entre las funciones Serverless y los tiempos de ejecución de contenedores es claro. Si asumimos una latencia de respuesta media de 118 ms para AWS Lambda, una asignación de memoria de 1 GB, y operamos de forma constante un contenedor AWS Fargate (especificación de 2 vCPU, 4 GB de RAM) con 2 tareas para garantizar una disponibilidad mínima, el punto de equilibrio converge en aproximadamente 96 millones de solicitudes mensuales. Por debajo de este umbral, el modelo de pago por uso de Serverless es ventajoso, pero en el momento en que se supera esta línea, la relación costo-beneficio del tiempo de ejecución de contenedores Fargate, que opera con costos fijos al reservar recursos de antemano, resulta superior.
En una arquitectura de ejecución constante, es obligatorio incluir en el cálculo los costos de red, que representan el 30% de la factura, como las tarifas de NAT Gateway (0,045 USD por hora, 32,40 USD al mes por zona de disponibilidad única), las tarifas básicas de Application Load Balancer (16,20 USD al mes) y los costos de asignación de direcciones IP públicas fijas (3,60 USD al mes por tarea) para obtener un punto de equilibrio preciso.
La fórmula para determinar la migración de infraestructura mediante una hoja de cálculo es la siguiente:
![Los proveedores de la nube están cambiando RÁPIDAMENTE [RESUBIDO]](https://i.ytimg.com/vi/UVz8_JljpGQ/hqdefault.jpg)
=( (R / 1000000) * costo_base_llamada ) + ( R * D * (M / 1024) * tarifa_por_GB_segundo )=( numero_contenedores_constantes * ( (cantidad_vCPU * costo_vCPU_por_hora) + (memoria_GB * costo_memoria_por_hora) ) * 720 ) + costos_fijos_infraestructuraSi la lógica de negocio se vincula estrechamente a bibliotecas de SDK de una nube específica o a interfaces propietarias de tiempo de ejecución, la aplicación queda atrapada en dicha plataforma. Un error común es inyectar un paquete de servidor web Express.js dentro del tiempo de ejecución de AWS Lambda y envolverlo con una biblioteca adaptadora (por ejemplo, @codegenie/serverless-express) para combinarlo con eventos de API Gateway Proxy. Esta estructura desperdicia recursos de CPU de la máquina virtual FaaS al forzar la emulación de flujos de sockets virtuales y procesos de conversión de búfer en cada solicitud. Además, aumenta el tamaño de la distribución de node_modules, que es un factor que provoca arranques en frío (cold starts), bloqueando fundamentalmente la migración de plataforma.
Para evitar este riesgo de acoplamiento y reducir el tiempo de migración a otra nube en un 80%, debe adoptar la Arquitectura Hexagonal (Hexagonal Architecture) como principio de diseño para el diseño del dominio. Aísle la lógica de negocio central (el dominio) de los canales de comunicación externos como API Gateway, motores de bases de datos y colas de mensajes. Haga que el dominio dependa únicamente de las interfaces de Puertos (Ports), que son límites abstraídos, y diseñe una estructura de complementos donde los componentes de Adaptadores (Adapters) se encarguen de la tecnología de implementación específica de la infraestructura, permitiendo que sean intercambiables.
Para ampliar la portabilidad de la plataforma, puede introducir AWS Lambda Web Adapter (LWA). Se trata de un método para insertar una línea de código de capa binaria en la especificación de construcción del Dockerfile.