Tras el blog serverless (subcapítulo 33.1), subimos un escalón de complejidad con el segundo proyecto: una API REST con contenedores. Mientras el blog era 100 % serverless, este proyecto te lleva al mundo de los contenedores (Capítulo 17) y las bases de datos relacionales (Capítulo 8), combinando ECS Fargate, RDS y un balanceador de carga (ALB). Es un patrón muy común en el mundo real para aplicaciones de backend, y consolida una parte distinta (y muy demandada) de tus conocimientos.

Una API REST es una «puerta de entrada» a la que otras aplicaciones (una web, una app móvil...) hacen peticiones para obtener o modificar datos. Por ejemplo, una API de una tienda con la que la app móvil consulta productos, crea pedidos, etc. Es el «cerebro» de backend que sirve datos y lógica a los clientes.

Este proyecto construye esa API, pero usando contenedores para ejecutarla y una base de datos relacional para los datos.

El proyecto combina tres servicios principales, cada uno con su papel:

Recuerda los contenedores (Capítulo 17): empaquetan tu aplicación con todo lo que necesita para funcionar igual en cualquier sitio. ECS con Fargate (subcapítulo 17.3) ejecuta esos contenedores sin que tengas que gestionar los servidores que hay debajo (Fargate es la opción serverless para contenedores). Aquí, tu API va dentro de un contenedor que ECS Fargate ejecuta y escala.

💡 Este proyecto te hace practicar el flujo de contenedores que vimos: empaquetar la app en una imagen Docker (subcapítulo 17.1), guardarla en ECR (subcapítulo 17.2) y ejecutarla en ECS Fargate (subcapítulo 17.3).

RDS (Capítulo 8) proporciona la base de datos relacional (gestionada por AWS) donde la API guarda y consulta los datos (productos, pedidos, usuarios...). A diferencia del blog (que usaba DynamoDB, NoSQL), aquí usamos una base de datos relacional (SQL), adecuada cuando los datos tienen relaciones estructuradas. RDS la gestiona por ti (copias, parches...).

El Application Load Balancer (ALB) (subcapítulo 13.1) reparte las peticiones entre los contenedores de tu API. Si tienes varios contenedores ejecutando la API (para aguantar más carga), el ALB distribuye el tráfico entre ellos de forma equilibrada, y comprueba su salud (recuerda los health checks, subcapítulo 13.2). Es la «puerta de entrada» que recibe a los clientes y los dirige.

Así encajan las piezas:

Los clientes llegan al ALB, que reparte sus peticiones entre los contenedores de la API (en ECS Fargate), y estos leen/escriben en la base de datos RDS. Si llega más tráfico, ECS Fargate añade más contenedores y el ALB los incluye en el reparto: escala automáticamente.

Este proyecto afianza una parte importante (y muy empleable) del libro, distinta a la del blog serverless:

⚠️ Buenas prácticas a aplicar (que has aprendido en el libro):

• Pon la base de datos en subredes privadas (Capítulo 6), no accesible desde internet directamente: solo la API debe poder hablar con ella.
• Guarda la contraseña de la base de datos en Secrets Manager (subcapítulo 23.6), nunca en el código ni en .tfvars (recuerda el subcapítulo 19.4).
• Usa Security Groups (Capítulo 6) para que solo el ALB hable con los contenedores, y solo los contenedores con la base de datos.

Ejemplo del mundo real: alguien quiere consolidar sus conocimientos de contenedores y bases de datos relacionales (distintos a los del blog serverless). Construye una API REST para una tienda: empaqueta la aplicación en una imagen Docker, la guarda en ECR, la ejecuta en ECS Fargate (varios contenedores), pone un ALB delante para repartir el tráfico, y usa RDS para los datos (productos, pedidos), con la base de datos en subredes privadas y la contraseña en Secrets Manager. Todo lo despliega con Terraform. Al construirlo, se enfrenta a retos reales —cómo conectar los contenedores con la base de datos de forma segura, cómo configurar el ALB y los health checks— y al resolverlos interioriza cómo funciona una arquitectura de contenedores de verdad. Acaba con una API real, escalable y segura, y un dominio sólido de un patrón muy demandado en el mercado.

• El proyecto de API REST con contenedores sube un escalón sobre el blog serverless, llevándote al mundo de los contenedores (Cap. 17) y las bases de datos relacionales (Cap. 8). Una API REST es la «puerta de entrada» de backend a la que otras apps hacen peticiones.
• Combina tres piezas: ECS Fargate (ejecuta la API en contenedores sin gestionar servidores, escala sola, Cap. 17), RDS (la base de datos relacional, Cap. 8) y ALB (reparte el tráfico entre los contenedores, Cap. 13).
• Arquitectura: clientes → ALB (reparte) → contenedores en ECS Fargate → RDS (datos). Escala automáticamente añadiendo contenedores.
• Consolida: contenedores (Docker/ECR/ECS, Cap. 17), RDS (Cap. 8), balanceo (Cap. 13), redes y seguridad (Caps. 6, 23), todo con Terraform.
• ⚠️ Aplica buenas prácticas: base de datos en subredes privadas, contraseña en Secrets Manager (nunca en el código), y Security Groups restrictivos.

En el siguiente subcapítulo abordaremos un proyecto del mundo de los datos: una plataforma de datos con Glue, Athena y Redshift.