Patrones de arquitectura de aplicaciones en AWS

Implementación de aplicaciones en AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Conoce a tu instructor

Instructor del curso, Dunieski Otano, AWS Solutions Architect, con unos diez años de experiencia en la nube

Por qué importa la arquitectura adecuada

Diagrama de decisión en tema claro donde una elección de arquitectura se ramifica en tres factores: acoplamiento, estado y comunicación, sobre un icono pequeño de balanza para los trade-offs

La arquitectura son trade-offs, no una única respuesta correcta
- Tres preguntas guían cada elección:
  - ¿Qué tan estrechamente están acoplados los componentes?
  - ¿Dónde vive el estado?
  - ¿La comunicación es síncrona o asíncrona?
- Ajusta el patrón a la carga de trabajo, no a la moda

La cascada del viernes por la noche

Una API de pagos lenta bloquea todo el checkout
Todos los servicios esperaban de forma síncrona
La solución es de arquitectura, no una API más rápida

Comparación lado a lado de servicios fuertemente acoplados que se estancan frente a servicios desacoplados por una cola de mensajes

Cómo la arquitectura decide el despliegue

Diagrama que compara una arquitectura frágil y fuertemente acoplada donde un fallo se propaga a todos los servicios frente a un diseño resiliente donde una cola amortigua el fallo y el resto sigue atendiendo

El patrón elegido define cómo la app escala y falla
- Un diseño fuertemente acoplado se rompe con carga
El patrón adecuado hace el despliegue predecible
- Mismo código, comportamiento en producción muy distinto

Patrones de arquitectura esenciales

Monolítica: una unidad desplegable, fácil para empezar
Microservicios: servicios independientes, desplegados por separado
Orientada a eventos: componentes reaccionan a eventos, no a llamadas directas
- Fanout es un subpatrón orientado a eventos: un evento llega a muchos consumidores

Tres patrones de arquitectura lado a lado: monolítica como un único bloque apilado, microservicios como servicios independientes desplegables, y orientada a eventos con un bus de eventos; fanout aparece como subpatrón publicando un evento a muchos consumidores

Con estado vs sin estado

Sin estado (stateless): no se guarda info del cliente entre peticiones
- Cualquier instancia puede atender cualquier petición
Con estado (stateful): la instancia recuerda interacciones previas
La ausencia de estado permite escalar horizontalmente
- Lleva el estado compartido a DynamoDB o ElastiCache

Instancia sin estado a la izquierda que puede recibir cualquier petición frente a una instancia con estado a la derecha vinculada a una sesión de cliente

Acoplamiento fuerte vs débil

Acoplamiento fuerte con el llamador bloqueado esperando a un servicio lento frente a acoplamiento débil con una cola SQS que amortigua mensajes para que el productor siga trabajando

Acoplamiento fuerte: el llamador espera la respuesta del llamado
Un servicio lento atasca toda la cadena
Acoplamiento débil: una cola de Amazon SQS entre servicios
El productor sigue trabajando aunque el consumidor esté caído

Síncrono vs asíncrono

Síncrono: el llamador se bloquea y espera el resultado
Úsalo cuando el llamador necesita la respuesta ahora
Asíncrono: el llamador delega el trabajo y vuelve
Úsalo para tareas lentas, irregulares o no urgentes

Llamada síncrona con el llamador bloqueado hasta recibir respuesta a la izquierda frente a delegación asíncrona que devuelve de inmediato con proceso en segundo plano a la derecha

Patrones de resiliencia para llamadas a terceros

Reintentos con backoff exponencial: espera más entre intentos
Cortacircuitos: deja de llamar a un servicio en fallo por un tiempo
Cola de mensajes muertos: aparca mensajes que siguen fallando
Combínalos; reintentar «a lo loco» empeora las caídas

Tres patrones de resiliencia: curva de reintentos con backoff exponencial, cortacircuitos que detiene llamadas a un servicio en fallo, y cola de mensajes muertos que captura mensajes tras agotar reintentos

¡Vamos a practicar!

Implementación de aplicaciones en AWS