Well-Architected: los seis pilares

Dos aplicaciones pueden hacer lo mismo y ser muy distintas por dentro. Una aguanta la caída de una zona, se despliega sin sustos y cuesta lo justo. La otra se cae cada mes y nadie sabe por qué la factura subió. La diferencia casi nunca es el servicio que eligieron: es cómo lo diseñaron.

El AWS Well-Architected Framework es la guía de AWS para diseñar y revisar cargas de trabajo en la nube. Reúne años de experiencia en preguntas y buenas prácticas, organizadas en seis pilares.

Los seis pilares

1. 1

   Excelencia operativa

   Operar y monitorear sistemas, y mejorar los procesos de forma continua. Ejemplo: desplegar con una pipeline en cambios pequeños y reversibles, tener alarmas en CloudWatch y escribir un análisis después de cada incidente.
2. 2

   Seguridad

   Proteger datos, sistemas y activos. Ejemplo: dar a cada rol de IAM solo los permisos que necesita, cifrar los datos en reposo y en tránsito, y registrar toda actividad con CloudTrail.
3. 3

   Fiabilidad

   Que la carga de trabajo cumpla su función de forma correcta y constante, y se recupere sola de las fallas. Ejemplo: base de datos Multi-AZ, instancias en varias zonas detrás de un balanceador y respaldos que se prueban.
4. 4

   Eficiencia del rendimiento

   Usar los recursos de cómputo de forma eficiente y mantener esa eficiencia cuando la demanda cambia. Ejemplo: elegir el tipo de instancia adecuado, usar Lambda para tráfico irregular o CloudFront para acercar el contenido a usuarios lejanos.
5. 5

   Optimización de costos

   Entregar valor al menor costo posible. Ejemplo: ajustar el tamaño de las instancias, usar Savings Plans para la carga estable, apagar ambientes de prueba de noche y etiquetar recursos para saber quién gasta qué.
6. 6

   Sostenibilidad

   Reducir el impacto ambiental de tus cargas de trabajo. Ejemplo: maximizar el uso de cada servidor en vez de tener muchos a medias, borrar datos que nadie usa y preferir servicios administrados que comparten infraestructura.

Cómo distinguir un pilar de otro

Los pilares se tocan entre sí, y el examen aprovecha justo esos bordes. Busca la palabra que delata la intención de la pregunta:

• Fiabilidad vs. rendimiento: fiabilidad pregunta «¿sigue funcionando si algo falla?». Rendimiento pregunta «¿responde rápido y con el recurso adecuado?».
• Excelencia operativa vs. fiabilidad: la primera habla de personas y procesos (runbooks, despliegues, revisiones después de incidentes). La segunda, de la arquitectura que aguanta fallas.
• Costos vs. sostenibilidad: a menudo coinciden (apagar lo que no se usa ahorra dinero y energía). Si el caso menciona dinero, es costos. Si menciona impacto ambiental o huella de carbono, es sostenibilidad.

Principios generales de diseño

Además de los pilares, el framework propone principios que aplican a todo diseño en la nube:

1. 1

   Deja de adivinar la capacidad

   Escala según la demanda en vez de comprar para el peor caso.
2. 2

   Prueba a escala de producción

   Crea un ambiente igual a producción para probar y bórralo al terminar.
3. 3

   Automatiza para poder experimentar

   Si crear un ambiente es barato y repetible, probar un cambio de arquitectura también lo es.
4. 4

   Permite que la arquitectura evolucione

   Lo que diseñaste el primer día no tiene que quedarse igual. La nube facilita cambiarlo.
5. 5

   Decide con datos

   Mide cómo se comporta tu sistema y usa esas métricas para elegir, no la intuición.
6. 6

   Mejora con simulacros (game days)

   Simula fallas y eventos reales para ver cómo responden el sistema y el equipo.

Cada pilar tiene además sus propios principios. Algunos que vale la pena recordar: en seguridad, aplicar seguridad en todas las capas y mantener a las personas lejos de los datos; en fiabilidad, recuperarse automáticamente de fallas y escalar horizontalmente; en costos, adoptar un modelo de consumo. La lección Alta disponibilidad y tolerancia a fallas aplica varios de ellos.

La Well-Architected Tool

• 

  AWS Well-Architected Tool

  El ingeniero que revisa contra la norma

  Un servicio en la consola de AWS, sin costo adicional, para revisar una carga de trabajo contra las buenas prácticas del framework.

1. 1

   Define la carga de trabajo

   Le das un nombre, el ambiente (producción o preproducción) y las regiones donde corre.
2. 2

   Elige los lentes

   El lente del Well-Architected Framework viene por defecto. Puedes sumar lentes especializados, como el de serverless, o crear los tuyos.
3. 3

   Responde las preguntas de cada pilar

   Preguntas como «¿cómo respaldas tus datos?», con buenas prácticas para marcar.
4. 4

   Revisa los riesgos

   La herramienta marca riesgos altos y medios, con enlaces a guías para resolverlos.
5. 5

   Sigue el plan de mejora

   Guarda hitos (milestones) para comparar el estado de la carga de trabajo con el tiempo.