¿Cómo realizar una revisión de Well-Architected Framework? – Parte 1

Por Lechu Matias Siri y Edwin Romero

¿Está bien diseñada mi carga de trabajo? ¿Mi equipo sigue las mejores prácticas de la nube? ¿Cómo implementan otros clientes la solución X? ¿Cuál es la mejor manera de configurar el servicio Y?

Estos son ejemplos de preguntas que solemos recibir de nuestros clientes que quieren validar si su arquitectura está alineada con las prácticas recomendadas de AWS. Las respuestas a estas preguntas varían en función del tipo de dominio tecnológico en el que opere el cliente, pero en general, existen principios de diseño que, de ser implementados por los clientes siguen, es probable que los sistemas que construyan ofrezcan su funcionalidad tal y como se espera. Estos principios de diseño y prácticas recomendadas son la parte central del Marco de buena arquitectura (AWS Well-Architected Framework) y abarcan seis pilares: Excelencia operativa, Seguridad, Fiabilidad, Eficiencia de rendimiento, Optimización de costos y Sostenibilidad.

En AWS, existen prácticas recomendadas para todo, y llevar a cabo una revisión del Well-Architected Framework (WA Review) para su carga de trabajo no es una excepción. Un WA Review puede ser un gran compromiso de tiempo, dependiendo de múltiples factores como la experiencia del equipo, la complejidad de la carga de trabajo, los pilares a revisar y otros factores que se discutirán más adelante. Ser consciente de estas mejores prácticas es clave para garantizar que el tiempo que su equipo invierte en la revisión dará el resultado esperado de identificar los riesgos de arquitectura y abordarlos. En esta serie de blogs de 3 partes, compartiremos algunas de las lecciones que hemos aprendido tras realizar muchos WAFR con clientes. En la primera parte, mostramos cómo prepararse para una revisión. El segundo blog trata sobre cómo ejecutarla, y el tercero sobre cómo identificar los riesgos de arquitectura y crear planes para remediarlos.

Antes de empezar, ¿qué es un Well-Architected Review?

Construir un sistema tecnológico no es diferente de construir cualquier otro producto. Hay prácticas y códigos que deben seguirse al construir un producto para garantizar que se ajusta a las normas del sector. Sin embargo, no basta con tener prácticas establecidas. También debe implementar mecanismos para garantizar que sus equipos conocen estas prácticas y las siguen.

El proceso coherente de aprendizaje de las prácticas recomendadas de AWS, la medición de la arquitectura con respecto a estas prácticas recomendadas, la identificación de los riesgos de la arquitectura y la creación de un plan de mejora para abordarlos es lo que denominamos AWS Well Architected Framework Review (WA Review).

Figura 1 – Ciclo del Well-Architected Framework Review

¿Cuál es el objetivo del WA Review? ¿Por qué tendría que hacerlo?

El objetivo principal del WA Review es mejorar la arquitectura de sus sistemas para que puedan satisfacer mejor las necesidades de la empresa. El proceso de mejora de la arquitectura comienza con la revisión de la arquitectura actual y su comparación con las mejores prácticas. Esto se realiza respondiendo las preguntas de revisión. Un conjunto de preguntas para cada pilar. Las preguntas validan si una práctica recomendada específica está implementada en su arquitectura o no. Basándose en sus respuestas, y con la ayuda de la herramienta AWS Well-Architected Tool (WA Tool), usted identifica las áreas de la arquitectura que representan riesgos altos, medios o bajos – Más sobre esto más adelante -. El siguiente paso es comenzar a trabajar en la resolución de los riesgos en un enfoque basado en prioridades mediante la identificación del mayor impacto de estos riesgos. A continuación, se crea un plan de mejora para abordarlos. Repasaremos los detalles de cada uno de estos pasos en este post y en los siguientes de la serie.

Fases de un WA Review

Hay tres fases para un WA Review: preparar, revisar y mejorar. En las siguientes secciones, profundizaremos en cada fase y le brindaremos algunas de las mejores prácticas para aprovecharlo al máximo.

Figura 2 – Fases del Well-Architected Framework Review

Preparar

La preparación para el WA Review, en promedio, comienza aproximadamente 3 semanas antes de la fecha de revisión real. Esto depende de factores como el tiempo para formar el equipo de revisión, definir cuántos pilares a revisar o establecer la prioridad dada por la organización para completar la revisión. Durante esta fase, usted decide qué equipo invitar a la sesión de revisión, la carga de trabajo a revisar y el formato de la sesión de revisión. También debe recopilar los datos necesarios sobre la arquitectura para ayudarlo a responder las preguntas de revisión.

A continuación, profundicemos en cada uno.

1 – Definir una carga de trabajo

El primer paso para prepararse para un WA Review es identificar la carga de trabajo que desea revisar. Una carga de trabajo es un conjunto de componentes (tecnología, personas, procesos) que aporta valor empresarial a su organización. Es el nivel de negocio y tecnología sobre el que se comunican los líderes. Por ejemplo, un sitio web donde sus clientes realizan y rastrean pedidos, junto con la infraestructura y los procesos que respaldan su back-end, es una carga de trabajo.

2- Definir al equipo principal (patrocinadores)

Un componente clave para un WA Review exitoso es involucrar a las personas adecuadas desde el principio.

Después de identificar una carga de trabajo a revisar, es necesario identificar a sus propietarios. A veces los llamamos patrocinadores. El patrocinador de una carga de trabajo es una persona (o equipo) que es, en última instancia, responsable del éxito (o fracaso) de la carga de trabajo. Esta persona debe tener el nivel adecuado de autoridad para influir y tomar medidas para abordar los riesgos identificados en la arquitectura como resultado de las revisiones. Algunas acciones de ejemplo podrían ser cambiar las prioridades de los equipos, contratar a un tercero o cualquier otra cosa.

También es necesario identificar un patrocinador para cada pilar. Dependiendo de la estructura y el tamaño de su organización, es posible que tenga una persona responsable de varios pilares, varios equipos responsables de un pilar o una combinación de ambos. El objetivo aquí es garantizar que tenga a la persona adecuada para responder las preguntas de revisión de cada pilar, y, posteriormente, abordar cualquier riesgo identificado en ese pilar como parte del plan de tratamiento.

Es posible que también necesite invitar a personas de diferentes equipos para obtener una visión más holística del pilar que se va a revisar. Por ejemplo, para revisar el pilar Fiabilidad, es posible que deba incluir a los expertos en la materia (SMEs) en: bases de datos, redes, seguridad y operaciones. Para revisar el pilar de Excelencia Operativa, es posible que deba incluir arquitectos empresariales y desarrollo de aplicaciones, o negocios/finanzas, etc.

3- Decidir sobre los pilares y lentes

Lo ideal es obtener una visión integral de la carga de trabajo desde la perspectiva de los seis pilares. Sin embargo, puede haber situaciones en las que necesite centrarse sólo en pilares específicos. Por ejemplo, es posible que haya cambiado sus prácticas de seguridad y quiera asegurarse de seguir cumpliendo con las mejores prácticas. En este caso, puede optar por revisar únicamente el pilar de Seguridad.

También se recomienda seguir el orden de los pilares tal como se enumeran en el Marco de buena arquitectura (AWS Well-Architected Framework). Comenzar con el Pilar de Excelencia Operacional y terminar con el Pilar de Sostenibilidad. Sin embargo, la prioridad de su organización puede ser diferente. En esta fase, también debe decidir el orden de revisión de los pilares.

Una cosa más que debe decidir es si desea utilizar Enfoques del AWS Well-Architected Framework. Los enfoques amplían la orientación ofrecida por Well-Architected a industrias y dominios tecnológicos específicos. Por ejemplo, si su carga de trabajo utiliza principalmente la tecnología Sin Servidor (Serverless), es posible que deba revisarla con el Enfoque Sin Servidor. Si ejecuta una carga de trabajo de análisis de datos, es posible que deba incluir el Enfoque de análisis de datos en su revisión. Etcétera. Consulta la lista de lentes disponibles aquí.

4- Decida sobre el formato de la sesión

Dependiendo de los pilares seleccionados y la disponibilidad de los equipos, debe decidir el formato de la sesión de revisión. Sus opciones incluyen un día completo para seis pilares o varias sesiones en varios días para pilares seleccionados. Normalmente es más difícil programar una revisión de un día completo, pero es la más valiosa, porque todas las partes interesadas se reúnen para discutir las mejores prácticas. Por lo general, este formato es el que más ayuda a descubrir oportunidades de mejora. Tener varias sesiones es una buena opción si tiene equipos distribuidos geográficamente o equipos más grandes y es difícil reunirlos al mismo tiempo. Este enfoque es más fácil de mantener, pero puede requerir que usted tenga que hacer un poco de trabajo adicional para actualizar a diferentes equipos sobre diferentes hitos.

La comunicación entre los equipos durante la revisión es clave porque ayuda a responder las preguntas y descubrir problemas de manera colectiva. Por ese motivo, se recomienda realizar el WA Review como una sesión en vivo, no de forma asincrónica, haciendo que los equipos respondan las preguntas en la WA Tool y las compartan más tarde.

5- Recoger los datos necesarios para la revisión

Antes de realizar la sesión de revisión, se recomienda que recopile detalles sobre la carga de trabajo que está revisando. Por ejemplo, consulte los diagramas o documentos de arquitectura que describan y expliquen cada uno de los componentes principales del sistema, su back-end y los principales procesos y equipos responsables de operarlo.

Para cargas de trabajo más complejas, puede aprovechar la comprobación de evaluaciones automáticas de AWS Trusted Advisor, de las mejores prácticas en optimización de costos, rendimiento, tolerancia a fallas de seguridad y límites de servicio. Puede habilitar Trusted Advisor y hacer que verifique todas las cuentas de su AWS Organizations. Más detalles aquí. Luego puede utilizar las acciones recomendadas por Trusted Advisor para comprender mejor su cumplimiento de algunas de las mejores prácticas e incorporar estos detalles en su revisión y también más adelante al desarrollar planes de tratamiento. A continuación se muestra un ejemplo sobre AWS Trusted Advisor habilita generación de informes sobre recomendaciones de prácticas recomendadas en varias cuentas con AWS Organizations.

En resúmen

En este blog post, profundizamos en la primera fase de la revisión del AWS Well-Architected Framework, la fase de preparación. Compartimos con ustedes algunos de los pasos y lecciones que aprendimos al realizar revisiones con los clientes. Estas recomendaciones ayudarán a que su revisión sea más fluida y le ayudarán a aprovechar al máximo el tiempo de cada participante. Los pasos incluyen definir las cargas de trabajo a revisar, definir los equipos centrales y patrocinadores adecuados, seleccionar los pilares y formato de sesiones y, por último, recopilar los datos que necesita con anticipación. Estos pasos lo prepararán para la fecha de revisión. Profundizaremos en eso en las parte 2 y parte 3 de esta serie de blog posts.

Acerca de los autores

Matias “Lechu” Siri es un Well-Architected Solutions Architect que colabora con socios y clientes de diversas industrias para diseñar e implementar cargas de trabajo seguras, resilientes y costo-eficientes basadas en las mejores prácticas del AWS Well-Architected Framework.

Edwin Arturo Romero González es un Solutions Architect quien ama ayudar a los clientes, compartir las mejores prácticas y capacitarlos en la arquitectura e implementación de soluciones. Fuera del trabajo, le encanta pasar tiempo con su novia y aprender sobre diferentes culturas.