Introducción a AWS Well-Architected Framework.

Las arquitecturas de servicios en la nube han supuesto un cambio de paradigma con respecto al despliegue de infraestructura on-premise en nuestros centros de datos.

A lo largo de los años, los equipos encargados de introducir este tipo de servicios han visto como las lecciones aprendidas para gestionar infraestructura en máquinas físicas no servían y ha sido necesario generar nuevos modelos de operaciones ajustados para trabajar en la nube.

Por poner un ejemplo ilustrativo, son muchas las ocasiones que hemos encontrado a compañeros de infraestructura de distintas empresas pidiendo estimar la capacidad necesaria en servidores para nuevas aplicaciones con el fin de provisionar esta capacidad con antelación.

A veces, esta estimación llevaba aparejada la necesidad de comprar más equipos, lo que generaba la presión añadida de estimar correctamente para no quedarse corto ni tampoco pasarse más de la cuenta para no generar costos innecesarios.

Cuando hablamos de la infraestructura en la nube esta situación carece de sentido, ya que sobre el papel disponemos de una infraestructura escalable que podemos ajustar a demanda en cuestión de minutos.

Aunque este ejemplo toque un poco los extremos y parezca evidente que no actuaremos de la misma manera, no es extraño encontrar organizaciones que no repiensan su forma de operar y las implicaciones que no hacer este ejercicio esto supone.

Encontramos como para disponer de entornos tenemos que completar órdenes de soporte que se completan días (o semanas) después, matando de un plumazo uno de los baluartes de la agilidad cloud.

En el blog ya hemos hablado en muchas ocasiones del elemento transformador de la adopción de las tecnologías en la nube y cómo su introducción es un desafío que va más allá de lo tecnológico.

Esta fue la génesis de nuestro interés en introducir los frameworks de adopción en la nube (CAF) de los que hemos hablado largo y tendido en una serie de post sobre los CAF de los distintos proveedores cloud (AWS, GCP y Azure).

Situaciones como la descrita, con respecto al modelo de operaciones, se tratan dentro de un marco holístico que no trata solo las operaciones, sino que abarca desde la estrategia hasta la capacitación de las personas, por citar algunas otras dimensiones.

Al igual que en su momento los proveedores cloud detectaron el enorme reto que la adopción de la nube suponía para sus clientes y acudieron en auxilio dando forma a los CAF, también han detectado a lo largo de los años el desequilibrio que supone no encarar convenientemente el diseño de arquitecturas en la nube. Por ello dieron forma y pusieron a nuestra disposición los Well-Architected Frameworks.

Todos los proveedores cloud cuentan con su propio Well-Architected Framework. La propuesta de AWS, en la que nos vamos a centrar, nació en el año 2015 y ha ido enriqueciéndose a lo largo de estos años con toda la experiencia generada.

¿Qué es una arquitectura en la nube?

Hemos mencionado el desafío que supone el diseño de arquitecturas en la nube y cómo los Well-Architected Framework pueden ayudarnos a encararlo con éxito. Antes de empezar a destilar el framework, merece la pena detenerse en qué es una arquitectura en la nube.

En la ingeniería informática entendemos una arquitectura como un modelo conceptual que define los componentes, relaciones, interacciones y despliegue de nuestro sistema. Es una de las principales actividades del diseño cuyo producto suele incluir un diagrama de arquitectura.

Los diagramas de arquitectura pueden seguir distintos enfoques o modalidades. Disponemos de diagramas de arquitectura lógica cuya misión es enumerar los componentes de nuestro sistema en la nube y las interacciones entre los mismos.

Por otro lado, también suele ser habitual completar el diagrama lógico con un diagrama de arquitectura física cuyo detalle es más exhaustivo, ya que incorpora la ubicación de los componentes y su conectividad de red.

En todos los casos, los diagramas reflejan de forma implícita decisiones de diseño de arquitectura que condicionan dimensiones importantes de nuestro sistema: rendimiento, disponibilidad, seguridad y coste (solo por citar algunas de ellas).

AWS Well-architected Framework

El AWS Well-architected Framework nació con el objetivo de ayudarnos a comprender las ventajas e inconvenientes de nuestras decisiones de arquitectura. Toda decisión suele tener contrapartidas y muchas veces no se trata de eliminar dichos compromisos, sino de entender qué implicaciones tienen y qué nos permiten conseguir. En el argot de arquitectura se conoce como entender los trade-offs de nuestro diseño y hacer de ellos una elección explícita y conocida.

Por ejemplo, nuestros diseños perseguirán, o al menos deberían, reducir los costes al máximo. Sin embargo, si queremos alcanzar unas cotas importantes de disponibilidad entenderemos que ciertos componentes deberán estar replicados en distintas ubicaciones o utilizar niveles de servicio de soluciones gestionadas que nos den esta disponibilidad.

Esto llevará aparejado un incremento del coste por debajo del cual sabremos que empezaremos a penalizar la disponibilidad de nuestra aplicación. Si no contamos con el presupuesto necesario y tenemos que hacer recortes en este sentido, seremos conscientes y tomaremos una decisión informada de que asumimos un grado de riesgo en la disponibilidad por acotar el coste.

AWS Well-architected Framework nos guía para revisar nuestras arquitecturas de forma constructiva, validarla contra las mejores prácticas e identificar áreas de mejora. No se trata en ningún caso de una auditoría de nuestra arquitectura, sino de recomendaciones para evaluar de forma consistente y sistematizada nuestros diseños contra un estándar exigente de calidad.

Seguir el AWS Well-architected Framework no nos da, per se, un sello que certifique el cumplimiento de ciertas normativas (PCI-DSS, HIPAA/HITECH, GDPR, etc.) pero sin duda nos ayudará a disponer de un punto de partida más completo si necesitamos certificar alguna de ellas.

Al ser una guía eminentemente técnica el público objetivo del marco de trabajo serán los responsables técnicos de nuestra organización que pueden ir desde el CTO, los distintos arquitectos, desarrolladores o personal de operaciones.

Terminología común

En todo marco de trabajo es importante contar con una terminología común que nos permita asegurar que todo el equipo entendemos lo mismo y con los mismos matices. Antes de introducir los pilares de diseño del framework, este acuerda una serie de términos básicos que se utilizarán en el resto de documentación.

• Componente (Component): un componente es la unidad básica de tecnología y hace referencia al código, configuración y servicio de AWS que dan respuesta a un requerimiento de nuestro sistema.
• Carga de trabajo (Workload): la carga de trabajo identifica a una serie de componentes que dan servicio conjunto para satisfacer a una necesidad de negocio. Esta es la agrupación sobre la que nos comunicamos generalmente tanto con negocio como con los responsables tecnológicos.
• Hito (Milestone): los hitos se utilizan para marcar momentos significativos de nuestra arquitectura como pueden ser su ciclo de vida (diseño, implementación, prueba, despliegue productivo, revisiones, etc.)
• Cartera de tecnologías (Technology Portfolio). La cartera de tecnologías es el conjunto de cargas de trabajo que hace que nuestro negocio funcione. Si recordáis las fases que se abordan en los Cloud Adoption Framework, la confección de la cartera es una de las primeras actividades que se abordaban para poder priorizar el resto del camino. Por ello, es importante prestar atención al mantenimiento de nuestra cartera tecnológica.

Pilares del AWS Well-Architected Framework

Una vez introducidos los conceptos comunes es hora de llegar al meollo de la cuestión. Si habéis curioseado el framework seguramente sea esta parte la que más os resuene o puede que sea la que, de manera informal, abordéis a la hora de evaluar vuestras arquitecturas en la nube.

El AWS Well-Architected Framework define seis pilares fundamentales. Estos pilares son las dimensiones que deben tratarse de forma sistemática cuando se diseña una arquitectura en la nube.

Los pilares están alineados con las mejores prácticas de sistemas en la nube y nos dan acceso a distintos patrones que podemos introducir según los objetivos marcados para nuestra arquitectura.

Vamos a ver la descripción de cada uno de los pilares:

• Excelencia Operacional (Operational Excellence): la excelencia operacional abarca el desarrollo y ejecución eficiente de cargas de trabajo. Además, busca el entendimiento de las operaciones y la mejora continua de los procesos y procedimientos de la organización.
• Seguridad (Security): describe cómo aprovechar las ventajas de la computación en la nube para proteger nuestros datos, sistemas y activos.
• Confiabilidad (Reliability): la confiabilidad engloba las decisiones que hacen que las cargas de trabajo funcionen correctamente y de la forma en que se espera. Esto incluye todas las operaciones y pruebas necesarias durante la gestión completa de su ciclo de vida.
• Eficacia del Rendimiento (Performance Efficiency): la eficacia del rendimiento consiste en el uso de los recursos de manera eficiente hasta satisfacer los requerimientos dados e, igual de importante, mantener esta eficiencia a medida que cambia la demanda y evolucionan las tecnologías.
• Optimización de Costes (Cost Optimization): permite la ejecución de nuestra infraestructura al mínimo coste posible mientras sigue aportando valor a nuestro negocio.
• Sostenibilidad (Sustainability): un nuevo pilar añadido en la revisión del framework de noviembre de 2021. Dadas las circunstancias actuales, toma especial relevancia acometer las buenas prácticas bajo el paraguas de esta dimensión que persigue ejecutar nuestras cargas de trabajo reduciendo su demanda de energía y que en última instancia se transforma en la minimización de los recursos requeridos.

Siguientes pasos

El AWS Well-Architected Framework es una de las herramientas indispensables que potencia nuestras habilidades para trabajar en la nube. La experiencia real que subyace en sus patrones y buenas prácticas suma a una forma de trabajar que tardaríamos tiempo en optimizar por nuestros propios medios.

En este post hemos dado las pinceladas necesarias para conocer los conceptos básicos y los pilares sobre los que se sustenta la aplicación del framework. En próximas entradas profundizaremos en los métodos para introducir sus guías en nuestra práctica de diseño y comentaremos con detalle cada uno de los pilares del framework. Esperamos que este contenido os resulte de interés. ¡Gracias por leernos!

¿Quieres más información sobre los Well-Architected Framework de AWS?

¡Entonces no te pierdas este podcast!