¿Cómo conseguir eficiencia y optimización de costes con AWS Well-Architected Framework?

Continuamos con este viaje por el AWS Well-Architected Framework. En las entradas anteriores hemos conocido de qué se compone el framework, su filosofía de aplicación y analizamos los tres primeros pilares de aplicación: excelencia operacional, seguridad y confiabilidad.

Para seguir con nuestro análisis, en esta entrada descubriremos otros dos pilares: eficiencia en el rendimiento y optimización de costes. ¿Cuáles son sus principios de diseño, las prácticas recomendadas y las listas de comprobación para incluir en nuestro proceso de revisión? ¡Vamos allá!

Eficiencia en el rendimiento

La eficiencia en el rendimiento abarca la selección de los recursos informáticos más adecuados para cumplir con los requisitos del sistema tanto en el diseño inicial como a medida que la demanda cambia y la tecnología evoluciona.

El AWS Well-Architected plantea cinco principios de diseño para conseguir la eficiencia en el rendimiento:

• Democratizar las tecnologías avanzadas.
• Proporcionar conexiones de baja latencia.
• Utilizar arquitecturas sin servidor.
• Experimentar con frecuencia.
• Considerar los patrones de uso de los usuarios.

A continuación, nos enumera las prácticas recomendadas para conseguir la adecuación de nuestros diseños y el mantenimiento a lo largo de su ciclo de vida. Estas recomendaciones se organizan en torno a fases que podemos incorporar a nuestra metodología de trabajo.

Selección

Los productos y/o cargas de trabajo que despleguemos en la nube precisan de un diseño concreto y específico para dotarlas del rendimiento más eficiente posible. Casi con toda probabilidad, si tratamos de enfrentar siempre con el mismo enfoque requerimientos distintos obtendremos rendimientos alejados de los mejores resultados.

El framework nos propone algunas áreas donde tomar decisiones acordes a los requerimientos concretos de la solución que estemos diseñando. Entre ellos, se encuentran la computación, el almacenamiento, las bases de datos o el planteamiento de red. No es una lista exhaustiva, pues encontramos otro tipo de servicios que pueden ser necesarios para nuestra solución. Lo importante es hacer hincapié en que la selección debe ser un ejercicio de información para optar por la mejor opción.

A modo de ejemplo, en la computación encontramos tres enfoques típicos: máquinas virtuales, contenedores o funciones. Su elección dependerá de nuestra necesidad concreta y del contexto de uso. Aunque generalmente es una buena aproximación tender hacia una capa serverless (funciones o contenedores), esto no siempre será posible y aun cuando sea posible no sería ideal. Por ejemplo, en este último caso encontramos procesos intensivos de datos donde se precisa un control determinado de localidad de datos que es complicado asegurar en entorno serverless.

Otro ejemplo ilustrativo tiene que ver con la elección de base de datos para nuestra solución. Durante un tiempo fue habitual forzar a las bases de datos relacionales para modelar información y patrones de acceso para las que no están optimizadas. Contamos con distintos tipos de bases de datos (relacionales, documentos, clave-valor, serie temporal) cada una de ellas indicada para un grupo de problemas. De ahí que sea inexcusable el análisis de cuál se adecua más a nuestros requerimientos.

Revisión

Como ya mencionamos en el análisis de otro de los pilares del framework, nuestra solución no permanece estática en el tiempo. Nos enfrentamos tanto a cambios de la demanda como a la evolución de la propia tecnología.

Debemos evaluar de manera continua nuestros servicios para tener en cuenta todos estos cambios y mantener nuestras soluciones ‘en forma’.

Es común encontrar arquitecturas que presentaban un rendimiento adecuado en los inicios, pero que se van degradando paulatinamente. Generalmente en estos casos nos encontramos con que no ha existido un proceso de revisión que actúe cuando sea necesario.

El framework menciona en este apartado la aplicación del ciclo de Deming (planificación, ejecución, verificación y ajuste). Aunque no profundizaremos en este aspecto, mencionar que este tipo de mecanismo de revisión se encuentra en normas de calidad como la ISO 9001.

Monitorización

Este aspecto también se ha tratado en otros apartados del framework y en este pilar vuelve a ponerse de manifiesto la necesidad de una monitorización activa de nuestras soluciones.

Nuestro objetivo, también en el caso de la monitorización del rendimiento, es detectar cualquier problema antes de que afecte a los usuarios o clientes de nuestros servicios. Esto no es posible si no habilitan junto con la monitorización, los mecanismos de alerta y respuesta automática para mitigar los problemas o avisarnos para intervenir de forma proactiva.

Es necesario que este apartado forme parte del diseño de nuestra arquitectura como un requisito no funcional de relevancia que tendrá impacto en la experiencia última de nuestros usuarios.

Soluciones de compromiso

A la hora de diseñar nuestras soluciones nos encontraremos con elementos que son incompatibles entre sí o, al menos, entre los cuales deberemos tomar decisiones de equilibrio.

El mejor ejemplo nos lo encontramos en las bases de datos distribuidas. En estos casos si queremos el rendimiento más rápido, debemos asumir que sacrificaremos la consistencia durante un periodo corto de tiempo y, por tanto, en algún momento recibamos los llamados "datos sucios".

En otras ocasiones el rendimiento puede que penalice los recursos, ya que necesitaremos más memoria para disponer de los datos en medios de acceso inmediato. En estos casos no hay recetas generales y serán los requerimientos de nuestra arquitectura, los que marquen qué es lo adecuado en nuestro contexto y, por tanto, la decisión última a tomar.

Lo importante, y lo que el framework incluye como un enfoque sistemático, es que debemos ser conscientes de las implicaciones de nuestras decisiones y cómo pueden impactar en ciertas dimensiones de nuestra solución en aras de mejorar su rendimiento.

Como en todos los pilares que hemos analizado, en esta ocasión también se nos sugiere qué elementos de comprobación en forma de pregunta podemos incluir en nuestra metodología de diseño de arquitecturas:

1. ¿Cómo selecciona la mejor arquitectura de rendimiento?
2. ¿Cómo selecciona una solución de computación?
3. ¿Cómo selecciona una solución de almacenamiento?
4. ¿Cómo selecciona una solución de base de datos?
5. ¿Cómo configura su solución de red?
6. ¿Cómo desarrolla su carga de trabajo para aprovechar los nuevos lanzamientos?
7. ¿Cómo monitorea sus recursos para garantizar que estén rindiendo?
8. ¿Cómo utiliza las soluciones de compromiso para mejorar el rendimiento?

Optimización de costes

La optimización de costes trata la búsqueda de soluciones que cumpliendo todos los requerimientos funcionales como no funcionales planteados, lo haga al menor coste posible.

Bajo el prisma del AWS Well-Architected Framework la optimización de costes se apoya en los siguientes principios de diseño:

• Implementar una administración financiera explícita de la nube.
• Adoptar un modelo de consumo apropiado.
• Medir la eficiencia de la solución.
• Dejar de gastar dinero en tareas complejas que no aportan diferenciación.
• Analizar y asignar de forma precisa los costes.

Para conseguirlos, como es habitual en cada uno de los pilares del framework, disponemos de unas prácticas recomendadas que revisan aspectos de nuestros procesos y soluciones.

Administración financiera de la nube

En los principios generales de framework ya dejamos plasmado cómo la filosofía del AWS Well-Architected apuesta por la máxima autonomía de los equipos que les permita innovar más rápido.

Esta autonomía se sustenta, por un lado, en la concienciación de los equipos sobre los gastos en los que incurren; y, por otro, en la adecuación de los procesos de la organización para evitar que sucedan costes imprevistos.

La formación será un punto de atención en ambos aspectos para que los equipos de una parte y el área financiera de la otra, dispongan de los mecanismos necesarios para conocer los costes y mantener sus presupuestos.

En otras dimensiones del framework ya hacíamos hincapié en la importancia de la monitorización proactiva para gestionar con anticipación. Esto se aplica igualmente a los costes donde contamos con herramientas para automatizar alertas cuando haya desviaciones del presupuesto o nos alejemos de nuestro objetivo financiero.

Concienciación sobre los gastos y el uso

Los servicios en la nube y su utilización por parte de la organización introduce una nueva forma de pensar sobre los gastos.

Si veníamos de un modelo de despliegue sobre nuestro propio datacenter, generalmente el equipo era ajeno a los costes que eso podía generar a la compañía. Las atribuciones precisas a un producto o servicio, aunque posibles, eran complejas. ¿Qué parte de la compra de un servidor compartido debería atribuirse a mi servicio?

En la nube disponemos de mecanismos para etiquetar, asignar, clasificar y revisar los costes por lo que esta nueva fuente de información debe introducirse como un requerimiento no funcional más de nuestra solución.

Esta capacidad para poder asignar costes y que estos sean conocidos por los equipos del producto generalmente lleva a hacer un uso responsable de la infraestructura, a elegir cuidadosamente los servicios a utilizar, y dentro de ellos, cuál será el tallaje más adecuado.

Buscar la rentabilidad de los recursos

Adecuar los recursos de infraestructura a la naturaleza de la carga de trabajo que se vaya a desplegar en la nube es fundamental a la hora de ahorrar costes.

Existen una serie de aspectos para mantener los costes a raya que pueden verificarse en el diseño de todas la soluciones. En ellos encontramos:

• Uso de servicios administrados frente a los que desplegamos en instancias virtuales.
• Manejar las instancias de cómputo para que estén operativas solo cuando sea necesario.
• Aprovechar los descuentos que ofrece la reserva de instancias si conocemos que nuestra solución hará uso de un número determinado de ellas.
• Descubrir cargas de trabajo y/o procesos de cálculo que puedan realizar bajo instancias spot.
• Analizar de forma explícita los costes en los que se puede incurrir por la transferencia de datos.

Disponer de los recursos basándonos en la demanda

La elasticidad de la nube, es decir, la capacidad de dotar la infraestructura subyacente de nuestra solución basándose en el uso real que se esté llevando a cabo por parte de los usuarios, es otro mecanismo del que disponemos para contener los costes.

Eliminamos la necesidad de sobre-aprovisionar pensando en el peor caso y manteniendo una baja utilización de la infraestructura la mayor parte del tiempo. En su lugar deberemos poner en práctica los mecanismos para escalar cuando sea necesario. Para estar preparados y eliminar el impacto transitorio mientras se añaden nuevas instancias a nuestra infraestructura, podemos analizar patrones de demanda con los que anticipar estos escalados.

Así mismo, el framework también nos invita a analizar partes de nuestras soluciones que puedan encajar en un procesamiento asíncrono o por lotes, ya que esto permite contener el número de instancias necesarias o utilizar instancias spot como se mencionó en el apartado anterior.

Optimización continua

Si nuestra solución no responde a una fotografía estática en el tiempo y sus necesidades y demandas evolucionan, los servicios de nuestro proveedor cloud también evolucionan para responder a estos cambios.

Es una práctica fundamental revisar nuestras decisiones de arquitectura para analizar si existen nuevos servicios o características que pongan sobre la mesa otras opciones más rentables. Muchas veces dispondremos de este tipo de variantes cuya introducción no supone un cambio disruptivo en nuestra solución y resultan rentables aun teniendo en cuenta el coste de la nueva implementación.

La relación de elementos de comprobación que podemos incluir en nuestras revisiones para analizar nuestra optimización de costes son los siguientes:

1. ¿Cómo implementa la administración financiera en la nube?
2. ¿Cómo controla el uso?
3. ¿Cómo monitorea el uso y los costos?
4. ¿Cómo retira los recursos que ya no se están utilizando?
5. ¿Cómo evalúa los costos al momento de elegir los servicios?
6. ¿Cómo cumple con los objetivos de costos cuando selecciona un tipo, un tamaño y un número de recursos?
7. ¿Cómo emplea los modelos de precios para reducir el costo?
8. ¿Cómo planea los cargos por transferencia de datos?
9. ¿Cómo administra los recursos basándose en la oferta y demanda?
10. ¿Cómo evalúa los nuevos servicios?

Una herramienta que todo arquitecto cloud debería conocer

El objetivo de esta serie de post es poner en valor una herramienta valiosísima para todos los que de una manera u otra participamos en la definición de soluciones en la nube.

El AWS Well-Architected Framework aglutina, organiza y sintetiza la experiencia y buenas prácticas tanto de AWS como proveedor, como de la multitud de clientes con los que trabaja.

Aunque la propuesta está auspiciada y liderada por AWS su aplicación es totalmente agnóstica, ya que todo lo mencionado en este framework puede aplicarse cuando se diseñan arquitecturas bajo Azure o Google Cloud Platform. De ahí que sea imprescindible para cualquier arquitecto independientemente de su especialización.

El AWS Well-Architected no solo ha proporcionado un enfoque general al diseño de arquitecturas, sino que disponemos de documentación para casos de uso más específicos. Por ejemplo, podemos encontrar documentación sobre aplicación específica para arquitecturas de análisis de datos, IoT o la industria del videojuego.

Esperamos que nuestro análisis haya servido para que conozcáis más en profundidad qué os puede aportar el uso de este framework y despierte vuestra curiosidad para seguir indagando. Y, seguid pendientes de nuestro blog, ¡aún queda la última entrega de la serie!