La sostenibilidad bajo el AWS Well-Architected Framework.

Os doy la bienvenida a esta serie de posts donde estamos analizando el marco de trabajo del AWS Well-Architected Framework. Ya os contamos una introducción a este framework; hablamos de la excelencia operacional, seguridad y confiabilidad; repasamos la filosofía y los principios generales y nos preguntamos cómo conseguir eficiencia y optimización de costes con este framework.

Ahora, alcanzamos la última parada donde terminaremos de analizar el nuevo pilar de sostenibilidad e incluiremos una pincelada de la herramienta de seguimiento del marco que nos facilita AWS. ¡Vamos allá!

Sostenibilidad

El último pilar que veremos en este análisis es el de la sostenibilidad. Se trata de un nuevo elemento de revisión añadido al framework en diciembre del año 2021.

La sostenibilidad en el ámbito del AWS Well-Architected consiste en comprender las repercusiones medioambientales, económicas y sociales de los servicios que usemos. Incluye la cuantificación del impacto a lo largo de todo el ciclo de vida de nuestras soluciones y la aplicación de medidas para reducir estas repercusiones. Desde el punto de vista medioambiental, las áreas donde se hará más énfasis serán la eficiencia y consumo energéticos.

Para conseguir la sostenibilidad de nuestras arquitecturas cloud, nos centraremos en los siguientes principios de diseño:

• Analizar específicamente el impacto de nuestros diseños.
• Establecer objetivos de sostenibilidad.
• Maximizar el uso de la infraestructura.
• Hacer uso de servicios administrados cuando sea posible.
• Evitar la imposición de determinados dispositivos o la actualización de los mismos para usar nuestras soluciones.

Estos principios de diseño se materializan en prácticas concretas recomendadas sobre distintos aspectos de nuestra arquitectura.

Selección de regiones

Ahora disponemos de una dimensión más a evaluar cuando escojamos sobre qué regiones desplegamos nuestras soluciones. La cercanía de proyectos de energías renovables y la intensidad de la huella de carbono que generen los data center de la región se suman a la latencia o la ubicación de los datos como elementos de decisión.

Patrones de los usuarios

Como en muchos otros aspectos del framework el ajuste de los recursos que utilizamos en el despliegue de nuestras soluciones es uno de los elementos más importante que tenemos para conseguir la eficiencia, la optimización de costes y la sostenibilidad de nuestros servicios.

En este caso el framework se centra en el escalado de los recursos basándose en el uso con el objetivo de eliminar excesos de capacidad. También nos pide hacer un ejercicio de análisis para definir nuestros niveles de servicio según los objetivos empresariales de nuestros clientes. Dicho de forma sencilla, darles todo lo que necesitan, pero no más de lo que necesitan.

Con respecto a otros pilares del framework, aquí se menciona en especial el análisis del tráfico de red para que este también sea minimizado. Aunque es menos visible, la infraestructura de red también es un consumidor de energía que puede ser reducido.

Otra aproximación posible es la utilización de escritorios compartidos en la nube para tareas de uso intensivo, como el renderizado o la compilación, en lugar de darle a cada usuario una máquina potente que en gran medida estará infrautilizada.

Patrones de software y arquitectura

Nuestras soluciones no solo son infraestructura y algunas de las optimizaciones inevitablemente llevan asociadas la mejora del software que se ejecuta.

En este punto destacaríamos dos aproximaciones que nos sugiere el framework. Por un lado, dirigir nuestros esfuerzos a la optimización del software en aquellas partes que consumen más recursos (para lo que inevitablemente necesitamos medir) sacando mayor partido a nuestros esfuerzos. Por el otro, la aplicación de arquitecturas asíncronas (mensajes, eventos, lotes) donde sea posible, nos permitirá hacer un uso intensivo y sostenido de los recursos que desplegamos.

Patrones de datos

La optimización energética de los datos pasa por determinar cuándo estos pueden ser movidos a un almacenamiento de más bajo consumo o, bien, ser eliminados de forma segura.

Es necesario que sean clasificados previamente para conocer los requisitos que deben cumplir tanto desde el punto de vista de nuestra organización como desde el punto de vista legal.

La elección del tipo de almacenamiento también tiene un impacto en la eficiencia energética siendo el almacenamiento de objeto mejor que el de tipo bloque. En cuanto a estos últimos, podemos vigilar que tengan un tamaño ajustado (pueden ampliarse después) y se desconecten cuando no se utilizan.

Por último, también debemos gestionar de manera adecuada la duplicidad de datos evitando las configuraciones RAID si no son necesarias para cumplir los SLA, realizar copias de seguridad solo de los datos que tengan valor empresarial o por requisitos legales y manejar los periodos de retención adecuados de estas copias de seguridad.

Patrones de hardware

En cuanto al uso óptimo del hardware subyacente a nuestra infraestructura, el framework nos pide poner foco en tres aspectos: supervisar el lanzamiento de nuevos tipos de instancia para aprovechar sus mejoras de eficiencia energética, escoger servicios administrados por AWS frente al despliegue de máquinas virtuales y hacer uso de instancias con GPU solo durante el tiempo estrictamente necesario.

Proceso de desarrollo e implementación

Para terminar el framework también nos invita hacer un análisis de nuestro ciclo de desarrollo y despliegue y a revisar tres aspectos:

• La actualización de sistemas operativos, librerías y aplicaciones, ya que pueden ayudar a la eficiencia y rendimiento de nuestras soluciones.
• Automatizar y hacer uso de la infraestructura como código para posibilitar la construcción de entornos efímeros que se levantan solo cuando sea necesario (testing, horario laboral, demostraciones, etc.).
• Ofrecer compatibilidad con hardware más antiguo para evitar la obligación de actualizaciones de hardware a nuestros clientes siempre que sea posible.

Todos estos elementos pueden ser revisados a través de la lista de comprobación que enumera cada uno de los pilares y que este caso está compuesta de las siguientes preguntas:

1. ¿Cómo selecciona las regiones para respaldar el cumplimiento de sus objetivos de sostenibilidad?
2. ¿Cómo puede sacar partido de los patrones de comportamiento de los usuarios para respaldar sus objetivos de sostenibilidad?
3. ¿Cómo puede sacar partido de los patrones de software y arquitectura para respaldar sus objetivos de sostenibilidad?
4. ¿Cómo puede sacar partido de los patrones de uso y acceso a los datos para respaldar sus objetivos de sostenibilidad?
5. ¿Cómo respaldan sus prácticas de uso y de administración de hardware sus objetivos de sostenibilidad?
6. ¿Cómo respaldan sus procesos de desarrollo e implementación sus objetivos de sostenibilidad?

AWS Well-Architected Tool

Hasta ahora hemos realizado una aproximación eminentemente teórica al framework y hemos mencionado varias veces cómo se puede introducir en nuestra metodología de desarrollo a través de listas de comprobación cuando estemos revisando nuestras arquitecturas en la nube.

Es un buen momento para comentar que a través de la consola de administración de AWS contamos con una herramienta para poder hacer seguimiento de las recomendaciones del Well-Architected Framework a nuestras cargas de trabajo llamada AWS Well-Architected Tool.

En ella podemos dar de alta los datos de la carga de trabajo/arquitectura que queremos evaluar y un conjunto de listas de comprobación predefinidas que podemos aplicar. Entre estas listas encontramos el propio AWS Well-Architected Framework o listas más específicas aplicadas a soluciones Serverless y SaaS.

Con esta herramienta disponemos del catálogo de preguntas de revisión de cada uno de los pilares y podemos ir marcando su cumplimiento cuando realicemos las comprobaciones necesarias a lo largo del ciclo de desarrollo de nuestras arquitecturas.

Utilizar esta herramienta nos ayuda a introducir esa validación sistemática dentro de nuestra metodología de desarrollo y, por otro lado, sabiendo que se actualizará automáticamente si el framework incorpora mejoras como ocurrió en el caso del pilar de sostenibilidad.

La herramienta no solo nos ofrece una visión estática de nuestra arquitectura, sino que podemos aplicar el análisis en varias etapas de la misma y ver cómo vamos abordando la consecución de los distintos pilares del framework a través de sucesivas versiones.

Si en alguna iteración de la arquitectura no cumplimos con alguna de las recomendaciones, algo habitual mientras va madurando a lo largo del desarrollo, disponemos de un dashboard con una clasificación de riesgos que supone el no cumplimiento de las mismas.

Esto nos habilita a introducir tareas de mejora en nuestro backlog que nos permitan trabajar de forma activa para el cumplimiento de las recomendaciones del framework y que a la postre se traducirán en una arquitectura y entrega de mejor calidad.

Llegamos a puerto, pero el viaje no termina aquí

En esta serie de post hemos hecho énfasis en múltiples ocasiones en la importancia de contar con metodologías y herramientas que sistematicen el conocimiento y buenas prácticas para fortalecer nuestra manera de trabajar y obtener mejores resultados en el uso de los servicios de la nube.

Esperamos que el AWS Well-Architected Framework os haya descubierto posibilidades de mejora en vuestro trabajo diario y sea un firme candidato a formar parte de vuestra caja de herramientas cloud.

Por nuestra parte, seguro que no es la última ocasión en que hablamos de este framework y seguiremos buscando formas prácticas de ilustrar el valor que nos aporta.