AWS Well-Architected Framework: excelencia operativa, seguridad y confiabilidad.

En la entrada anterior de esta serie que estamos realizando sobre el AWS Well-Architected Framework revisamos qué filosofía de trabajo subyace en la aplicación del marco, cómo nos propone la descentralización del conocimiento para dotar de autonomía a los equipos, cuáles son los principios generales de diseño y cómo podemos integrar el proceso de revisión en nuestra forma de trabajo.

Hoy comenzaremos a analizar en profundidad los seis pilares fundamentales sobre los que se apoyan la construcción de soluciones de calidad y que se alinean con las mejores prácticas tanto desde el punto de vista de la arquitectura como de las operaciones. Estos pilares son:

• Excelencia Operacional.
• Seguridad.
• Confiabilidad.
• Eficacia del Rendimiento.
• Optimización de Costes.
• Sostenibilidad.

Para todos ellos el AWS Well-Architected Framework recoge una serie de principios de diseño, prácticas recomendadas y listas de comprobación (en forma de preguntas) que deberemos incluir en nuestro proceso de revisión (como vimos en la segunda parte de nuestra serie).

En este post profundizaremos en los tres primeros pilares para analizar qué principios de diseño, prácticas recomendadas y preguntas se recogen en cada uno de ellos.

1 Excelencia Operativa

La excelencia operativa se define como la capacidad para desarrollar y ejecutar cargas de trabajo de manera eficaz, obtener información acerca de las operaciones y la mejora continua de procesos y procedimientos que favorezcan el negocio.

Según el AWS Well-Architected Framework la excelencia operativa se sustenta en cinco principios de diseño:

• Realizar operaciones como código.
• Realizar cambios reversibles, pequeños y frecuentes.
• Mejorar los procedimientos operativos con frecuencia.
• Anticipar los errores.
• Aprender de todos los errores operativos.

La excelencia operativa puede implementarse con prácticas recomendadas en las siguientes áreas:

Organización

Los equipos involucrados en el desarrollo y operaciones de nuestras soluciones deben disponer de unas prioridades claras que se revisen con regularidad, ya que estas pueden ir variando según las necesidades.

Se debe realizar una gestión explícita de los riesgos y amenazas para el negocio que se incluyan en un registro de riesgos. A veces, existen intereses y objetivos contrapuestos. Las prioridades de negocio junto con las amenazas y riesgos nos ayudan a tomar decisiones sobre qué prevalece.

Los equipos deben entender cuál es su contribución a los resultados empresariales y al éxito de otros equipos. Tener un propósito claro ayuda a mantener la motivación y el foco.

Cuando se coordinan distintos equipos deben potenciarse la adopción de acuerdos entre los mismos así como definir de quién es la responsabilidad y tiene la autoridad para tomar decisiones en los distintos ámbitos de dependencia.

Preparación

El diseño de nuestras soluciones debe incluir su comportamiento esperado. Lo ideal es que este se defina de manera cuantitativa lo que nos permitirá definir métricas que sirvan para monitorizar su estado y su rendimiento.

El diseño de nuestra solución debería primar las aproximaciones que permitan cambios aun cuando ya hayan sido puestas a disposición de los usuarios (producción). Se persigue que sean soluciones refactorizables y que puedan ser modificadas para mejorar su calidad o corregir errores.

Estos cambios deberían ser reversibles, pequeños y frecuentes en aras de minimizar el impacto si el resultado no es el esperado.

Operación

El éxito de nuestras soluciones dependerá de si es útil para conseguir resultados de nuestra organización y nuestros clientes.

Gracias a que hemos definido el resultado esperado en base a métricas, podemos usar estos cálculos para determinar si nuestra carga de trabajo funciona de manera correcta.

La monitorización activa de nuestras soluciones nos permitirá identificar cuándo los resultados están en peligro y habilitar respuestas efectivas. Toda alerta en respuesta a un evento debe estar asociada a un proceso que ejecutar y un propietario identificado de forma específica.

Las métricas no solo sirven para evaluar el funcionamiento correcto de nuestras soluciones, sino para identificar áreas de mejoras que puedan ser abordadas en sucesivas iteraciones.

Evolución

Las soluciones desplegadas deben ser sometidas a mejoras graduales y continuas. Muchos de los aspectos a mejorar pueden provenir de las operaciones realizadas en el área anterior, otras pueden provenir del feedback de los usuarios finales.

Dentro de la evolución de nuestra solución es de especial importancia analizar los incidentes que afectan de una u otra manera a la experiencia de uso de los usuarios para priorizar acciones correctivas y prevenir que se repitan.

La mejora continua de nuestra solución debe formar parte explícita de su ciclo de vida, incluyendo bucles de retroalimentación que den lugar a aprendizajes que sean compartidos con todos los equipos de la organización (no solo del dueño de la solución).

Como ya hemos comentado, cada pilar del AWS Well-Architected Framework incluye una serie de preguntas que nos ayudan a sistematizar la revisión. Estas preguntas funcionan a modo de lista de comprobación y nos ayudan a asegurar que no dejamos ningún punto importante fuera del paraguas de nuestro diseño.

Aunque no se menciona en el framework, es interesante acompañar este proceso de revisión con un registro de decisiones de arquitectura que forme parte del diseño. Así en el futuro contaremos con una memoria de por qué se tomaron ciertas decisiones que pasado el tiempo no nos parecerán tan obvias.

Las preguntas que conciernen a la excelencia operativa son las siguientes:

1. ¿Cómo determina cuáles son sus prioridades?
2. ¿Cómo estructura su organización de manera que respalde los resultados empresariales?
3. ¿Cómo respalda su cultura organizativa los resultados empresariales?
4. ¿Cómo diseña su carga de trabajo de manera que pueda comprender su estado?
5. ¿Cómo reduce los defectos, facilita la corrección y mejora el flujo en la producción?
6. ¿Cómo mitiga los riesgos de implementación?
7. ¿Cómo sabe que está listo para dar respaldo a una carga de trabajo?
8. ¿Cómo comprende el estado de su carga de trabajo?
9. ¿Cómo comprende el estado de sus operaciones?
10. ¿Cómo administra los eventos de carga de trabajo y operaciones?
11. ¿Cómo impulsa el progreso de las operaciones?

2 Seguridad

La seguridad abarca la capacidad para proteger los datos, sistemas y activos aprovechando todos los mecanismos proporcionados por las tecnologías de la nube.

Para el AWS Well-Architected la seguridad se puede vertebrar a partir de los siguientes principios de diseño:

• Implementando una base de identidad sólida.
• Facilitando la trazabilidad.
• Aplicando la seguridad en todos los niveles de la solución.
• Automatizando las prácticas recomendadas de seguridad.
• Protegiendo los datos tanto en tránsito como en reposo.
• Eliminado o reduciendo todo lo posible el acceso directo a los datos.
• Estando preparado para potenciales eventos de seguridad.

Las prácticas recomendadas relacionadas con la seguridad recogidas en el marco están categorizadas en las siguientes áreas:

Seguridad

Los procesos de seguridad, pruebas y validaciones deben estar automatizados para reducir la posibilidad de errores accidentales. De esta manera también se consigue escalar la aplicación del modelo de seguridad cuando se alcanza un gran número de soluciones desplegadas.

La seguridad debe formar parte del ciclo de mejora continua de la solución por lo que es recomendable mantenerse al día de las recomendaciones del sector. Si la seguridad del activo es crítica, disponemos de servicios para activar la respuesta ante eventos de seguridad aplicando la inteligencia artificial.

Si no se ha realizado un diseño específico mientras se abordaba la adopción de la nube, es importante tener en cuenta la recomendación de que las cargas de trabajo estén distribuidas en distintas cuentas según su función, requisitos de conformidad o confidencialidad de los datos.

Gestión de identidad y accesos

La gestión de la identidad y accesos es un aspecto que suele definirse de manera global cuando se plantea la adopción de un proveedor de servicios en la nube.

En este sentido, cuando ya se acomete el diseño de una solución o carga de trabajo concreta, se cuenta con un diseño de cuentas, usuarios, roles y políticas que se aplicarán en todos los casos y que deben tenerse en cuenta en este diseño particular.

Por otro lado, se debe garantizar que las credenciales no se comparten entre usuarios o sistemas, se utiliza el enfoque del mínimo privilegio posible y las llamadas al API de AWS utilizan credenciales temporales y con privilegios limitados.

Detección

La detección abarca tanto la aproximación a la identificación activa de amenazas que se produzcan sobre nuestros sistemas como los controles para garantizar que se cumplen con las prácticas y políticas acordadas en materia de seguridad.

No podemos olvidar que, aparte de la exigencia interna en materia de seguridad, debemos constatar si estamos sujetos a obligaciones legales debido a la sensibilidad de la información que gestionamos o la criticidad del servicio que ofrecemos.

Acorde a los requisitos y obligaciones debemos plantear las necesidades de detección y almacenamiento de los registros de seguridad. Estos últimos nos permitirán realizar análisis forenses si se materializa algún incidente de seguridad.

Protección de la infraestructura

La protección de la infraestructura se puede abordar desde el enfoque de la defensa en profundidad, activando los elementos de seguridad de los componentes de nuestra solución dependiendo de nuestras obligaciones organizativas o normativas.

La defensa en profundidad disponible en las soluciones en la nube abarca, sin ánimo de ser exhaustivos, los elementos de identidad, conexiones privadas, filtrado de red, monitoreo de puntos de entrada y salida, monitorio del estado de la infraestructura, bastionado de los servicios o controles de acceso en las aplicaciones.

Protección de los datos

Este punto está especialmente orientado al cumplimiento de las obligaciones legales en cuanto al tratamiento de los datos y a la prevención de la pérdida de información.

Para poder tomar decisiones de arquitectura deberá realizarse previamente una clasificación de los datos en función del nivel de confidencialidad, políticas de acceso, retención y actualización.

La solución responderá a los requisitos anteriores activando las políticas de backup, redundancia, cifrado y control de acceso adecuados.

Respuesta ante incidentes

Incluso con controles preventivos y de detección extremadamente sólidos, la organización debe implementar procesos para responder al potencial impacto de los incidentes de seguridad y mitigarlos.

Idealmente, los eventos de seguridad deberían procesarse automáticamente para tomar las contramedidas iniciales mientras el equipo de seguridad determina la mejor manera de actuar.

Las soluciones deben disponer de mecanismos probados que permitan la intervención rápida de los equipos de seguridad, aíslen las instancias afectadas y realicen la captura de datos y estados que permitan el análisis forense de los incidentes.

La lista de preguntas que conforman la lista de comprobación y que debemos incluir en el proceso de revisión cuando abordemos la seguridad son las siguientes:

1. ¿Cómo opera su carga de trabajo de manera segura?
2. ¿Cómo administra las identidades para las personas y las máquinas?
3. ¿Cómo administra los permisos para las personas y las máquinas?
4. ¿Cómo detecta e investiga eventos de seguridad?
5. ¿Cómo protege los recursos de su red?
6. ¿Cómo protege los recursos informáticos?
7. ¿Cómo clasifica los datos?
8. ¿Cómo protege sus datos en reposo?
9. ¿Cómo protege sus datos en tránsito?
10. ¿Cómo se anticipa, responde y recupera de los incidentes?

3 Confiabilidad

La confiabilidad de una solución desplegada en la nube significa que realizará sus funciones previstas de manera correcta y sostenida de a lo largo del tiempo. Esto no solo significa que esté disponible acorde a los requisitos que tenga definidos (SLA), sino que lo hará respondiendo de forma adecuada y con un rendimiento satisfactorio.

Nuestros servicios desplegados no son una fotografía estática, sino que están sometidos a un ciclo de vida completo que les llevará a acometer diversos cambios, ya sea para disponer de nuevas funcionalidades o para operar de forma conveniente. En cualquier caso, la confiabilidad también se encarga de que la introducción de estos cambios no merme ninguno de los parámetros de disponibilidad y rendimiento.

El AWS Well-Architected identifica los siguientes principios de diseño para conseguir arquitecturas confiables:

• Recuperarse de los errores automáticamente.
• Procedimientos de recuperación definidos y probados.
• Servicios desplegados en escalado horizontal.
• Capacidad definida de forma empírica.
• Administración de los cambios relacionados con la automatización.

Estos principios se materializan en las siguientes prácticas recomendadas organizadas por áreas:

Bases

En pilares anteriores ya mencionamos que algunos aspectos concernientes al diseño de nuestras soluciones tienen que ver con planteamientos generales de nuestra adopción en la nube. Por ejemplo, es el caso de la gestión de identidad y accesos del pilar de seguridad que suele definirse a nivel general para todas las soluciones en lugar de hacerlo una por una.

En el caso de la confiabilidad, también existen elementos que son comunes a muchas de nuestras soluciones. Entre ellos se encuentran las políticas de cuotas para provisionar el uso y número de recursos o la topología de red.

Ya sea de forma general o específica se debe tener en cuenta que disponemos de los recursos suficientes y necesarios para que nuestra solución escale de forma adecuada. Un caso típico lo tenemos con las funciones de AWS Lambda. Si llegamos a un número de conexiones concurrentes puede que sea necesario solicitar un incremento del límite a AWS para que no se rechacen peticiones.

De la misma manera la topología de red debe estar reparada para soportar distintas zonas de disponibilidad, incluso si es requisito para cumplir un SLA exigente, disponer de un despliegue multi-región.

Arquitecturas de las cargas de trabajo

Las arquitecturas de soluciones en la nube no dejan de ser una arquitectura de sistemas distribuidos. Por ello, el foco sobre el que se dirigen nuestras actuaciones para mantener la disponibilidad y rendimiento del conjunto, se centra en la interacción y comunicación de estos elementos.

Nuestras soluciones deben estar preparadas para soportar pérdidas de las comunicaciones o incrementos de la latencia entre componentes individuales. Si se da esta circunstancia lo fundamental es que el mal funcionamiento de las comunicaciones o de algún componente en concreto, no dé al traste con el sistema entero.

Existen patrones conocidos para conseguir este tipo de comportamiento como circuit breaker, timeouts, retries, rate-limiting. También es posible mejorar la resiliencia en este aspecto aproximándonos a arquitecturas desacopladas basadas en eventos que acompañen a las basadas en petición/respuesta.

En cualquier caso la consecución de una arquitectura confiable necesitará de la coordinación de todos los equipos involucrados en el desarrollo, ya que algunos de estos patrones podrán implementarse en la infraestructura, otros en la capa de comunicaciones (service mesh) y otros tendrán que hacerlo en la propia aplicación.

Administración de los cambios

Como mencionamos en los principios de diseño, raramente nuestra solución será un elemento estático que queda inalterado una vez se ha puesto en producción.

Entendemos por cambio toda aquella modificación en los elementos que componen nuestra solución y el estado de los mismos. Estos cambios irán desde la adición/disminución de recursos por picos de demanda, aplicación de parches de seguridad o implementación de nuevas características.

Los cambios son la causa raíz de la aparición de problemas que degradan el desempeño de nuestra solución. Ya sea por la introducción de deuda técnica o porque no se planifica adecuadamente el impacto de los mismos.

La automatización en la aplicación de los cambios junto con la monitorización del rendimiento tras la aplicación del mismo nos ofrece la posibilidad de deshacer el despliegue si observamos un comportamiento anómalo o inesperado.

Disponer de distintas réplicas de nuestra solución (escalado horizontal) también nos posibilita la aplicación progresiva en cada una de las réplicas para detectar problemas en los cambios antes de que se apliquen al conjunto del sistema.

Administración de los errores

Debemos dar por hecho que en algún momento nuestra solución sufrirá errores de distinta naturaleza. Lo que la hará sobresalir en materia de confiabilidad es la forma en la que sea capaz de responder a los mismos manteniendo sus niveles de disponibilidad y rendimiento o afectándolos lo mínimo posible.

La automatización será la base de una respuesta rápida ante la aparición de errores y la que nos podrá en disposición de conseguir que estos no sean detectados en última instancia por nuestros usuarios. Para responder y lanzar estas automatizaciones deberemos de disponer un sistema de monitorización adecuado (pilar de excelencia operativa) que será sobre el que se programe la respuesta automática cuando se detecte algún evento de riesgo o degradación de servicio.

En algunas ocasiones el manejo de los errores llevará aparejado la restauración completa de alguna de las réplicas por lo que es fundamental contar con una política explícita copia de seguridad de los datos.

Si nuestra solución sufre un error tan crítico que lleva a la perdida del servicio, deberemos haber definido cuál es nuestro objetivo de tiempo de recuperación (RTO) y cuánta pérdida de datos sería asimible (RPO). En base a ellos desarrollaremos una estrategia de recuperación ante desastres que los garantice.

Los mecanismos de recuperación ante errores deben probarse y asegurar que están disponibles para cuando se necesiten. A veces nos encontramos, sobre todo con las políticas de recuperación ante desastres, que solo se han materializado sobre el papel. Finalmente, cuando son necesarias, o bien hay elementos que no funcionan o el personal no es lo suficientemente eficaz a la hora de ejecutar el procedimiento porque no lo ha ensayado nunca.

Las preguntas que conforman la lista de comprobación para el pilar de confiabilidad son las siguientes:

1. ¿Cómo administra las cuotas y las restricciones de servicio?
2. ¿Cómo planifica la topología de la red?
3. ¿Cómo diseña su arquitectura de servicios para cargas de trabajo?
4. ¿Cómo diseña las interacciones en un sistema distribuido para evitar los errores?
5. ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar los errores?
6. ¿Cómo supervisa los recursos de las cargas de trabajo?
7. ¿Cómo diseña la carga de trabajo para que se adapte a los cambios en la demanda?
8. ¿Cómo implementa los cambios?
9. ¿Cómo realiza una copia de seguridad de los datos?
10. ¿Cómo usa el aislamiento de errores para proteger su carga de trabajo?
11. ¿Cómo diseña su carga de trabajo para que soporte los errores de los componentes?
12. ¿Cómo pone a prueba la confiabilidad?
13. ¿Cómo planifica la recuperación de desastres (DR)?

Repaso de los tres primeros pilares

En esta entrada de blog hemos revisado en profundidad los tres primeros pilares del AWS Well-Architected Framework. Con esta visión pormenorizada ya estamos en disposición de empezar a aplicarlos dentro de nuestra metodología de diseño. En el próximo post haremos lo propio con los últimos tres pilares para terminar nuestro análisis de este marco de trabajo. ¡Os esperamos!