Elegir entre Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda y AWS Batch es una decisión sobre dónde se ejecuta el código y quién asume la responsabilidad de las operaciones. En este curso, desarrollamos un marco de trabajo replicable que vincula los requisitos de la carga de trabajo con el comportamiento de escalado, los límites de fallo, la responsabilidad operativa y los factores que determinan el costo total. Evitaremos basarnos en un enfoque de simple catálogo de servicios; en su lugar, justificaremos cada elección mediante restricciones y evidencias.
Definamos primero el eje de responsabilidad, ya que explica la mayoría de las compensaciones y decisiones de compromiso. La responsabilidad operativa se refiere a quién aplica parches al sistema operativo, gestiona la capacidad y ejecuta el programador (scheduler) que asigna las tareas a los recursos de cómputo.
En Amazon EC2, operamos máquinas virtuales, por lo que elegimos la AMI, la estrategia de aplicación de parches y el enfoque de escalado. En Amazon ECS o Amazon EKS, operamos un orquestador que programa contenedores, y aún debemos decidir qué proporciona la capacidad subyacente. En AWS Fargate, la capa de capacidad para contenedores es gestionada por AWS, por lo que nos centramos en las definiciones de tareas y el escalado de servicios en lugar de en flotas de nodos. En AWS Lambda, AWS se encarga de la infraestructura de cómputo y del escalado, mientras que nosotros nos centramos en el código de la función y en su modelo de invocación. En AWS Batch, AWS gestiona la puesta en cola y la programación de trabajos por lotes, y puede asignar dichos trabajos a recursos de ECS, EKS, Fargate o EC2.
Analicemos a grandes rasgos cómo cambia la responsabilidad entre estas opciones.
Podemos abordar la selección de recursos de cómputo como un ejercicio de ajuste a restricciones, en lugar de un debate sobre preferencias. El modelo de ejecución se refiere a si la tarea se ejecuta como un servicio de larga duración, una función activada por eventos o un trabajo en cola con un inicio y un fin definidos.
El patrón de tráfico suele ser la primera restricción crítica. El tráfico con picos y largos periodos de inactividad tiende a favorecer los modelos basados en peticiones individuales, mientras que el tráfico constante favorece la capacidad siempre activa, donde la tasa de utilización se mantiene elevada.
La duración y el estado reducen rápidamente las opciones disponibles. AWS Lambda tiene un tiempo de espera máximo (timeout) que actualmente es de 900 segundos; por ello, las tareas de mayor duración suelen trasladarse a contenedores o a procesamiento por lotes (batch). Las cargas de trabajo con estado (stateful) —que mantienen un estado local o requieren una configuración especializada del host— suelen adaptarse mejor a Amazon EC2 o a contenedores ejecutados sobre capacidad de EC2.
La sensibilidad a la latencia también tiene implicaciones operativas. En los flujos de petición-respuesta, debemos considerar el riesgo de arranque en frío (cold start), la ubicación en la red y la rapidez con la que la plataforma puede añadir capacidad en paralelo. En los flujos asíncronos, nos interesan el crecimiento de la cola de trabajo pendiente (backlog), el comportamiento ante reintentos y la forma en que se aíslan y reintentan las operaciones fallidas.
Visualicemos cómo estas tarjetas de requisitos se corresponden con las restricciones de cómputo.