Filosofía y principios generales del AWS Well-Architected Framework.

Hace unas semanas ya hablamos de AWS Well-Architected Framework y os dimos unas primeras pinceladas sobre esta herramienta. Ahora, en esta entrada seguimos analizando el AWS Well-Architected Framework y nos adentramos en su filosofía y principios generales de aplicación.

En otros artículos del blog hemos visto cómo la introducción de nuevas tecnologías en la organización raramente puede acometerse de manera aislada, sin atender a otras dimensiones igualmente importantes. Nos referimos tanto a las personas como a los procesos que acompañan a la tecnología.

Es bastante comprensible que si hablamos de tecnologías en la nube que nos posibilitan disponer de infraestructura en cuestión de minutos, cualquier proceso de solicitud de la misma que se demore horas o días está cercenando dicha ventaja y nos pone en un lugar totalmente diferente al que podíamos tener previsto cuando valoramos su uso.

Al igual que los procesos, las personas o equipos que hacen uso de las nuevas tecnologías deben estar preparados para las mismas, puesto que si no se sienten seguros y capacitados tenderán a seguir utilizando aquello en lo que se sienten competentes y los cambios tecnológicos no tendrán el impacto deseado.

Traemos a colación estas dos dimensiones porque cuando repasemos la filosofía y principios de aplicación del Well-Architected observaremos que no solo se ciñen a aspectos tecnológicos, sino que sugieren aspectos organizativos que atañen a los equipos y procesos sin los que no se terminaría de exprimir el potencial tecnológico de los servicios de la nube.

No podemos olvidar que la génesis de esta propuesta nace de las propias lecciones y funcionamiento interno de AWS y, por tanto, algunos consejos deben analizarse previamente para conocer cómo encajarían dentro de nuestra organización. Parece bastante obvio que no podemos actuar igual en una organización con decenas de equipos que en una startup compuesta por una decena de personas en conjunto.

Abundando en este sentido, si la filosofía supone un cambio sustancial en nuestra manera de trabajar sería deseable introducirla en pequeños pasos. Mejor que plantear una revolución para la que la organización no está preparada de un día para otro. Todo cambio, por pequeño que sea, suma en ese tránsito de mejora continua.

Descentralización del conocimiento

El Well-Architected Framework materializa la filosofía de que todos los equipos de desarrollo de la organización deben ser autosuficientes a la hora de plantear las arquitecturas de sus soluciones y que estas sean de calidad.

Esto se contrapone al enfoque de que es un equipo centralizado de arquitectos el que realiza estos diseños bajo demanda.

El aseguramiento de la calidad en las arquitecturas de los distintos equipos se consigue a través de herramientas como:

• Prácticas comunes.
• Acompañamiento de expertos para aumentar la competencia de los equipos.
• Mecanismos de validación y comprobación automatizados.

Estas tres herramientas, por un lado, aprovechan el conocimiento existente en la organización, y lo hacen explícito, planteando prácticas comunes fruto de la experiencia. Por otro lado, fortalecen las iniciativas de formación y capacitación gracias al acompañamiento experto. Y, por último, aseguran que no hay desviaciones en las prácticas propuestas gracias a la comprobación automatizada. Este último punto no es desdeñable, puesto que todo aquello, aunque sea de obligado cumplimiento, que no se valida de manera automatizada es candidato a desaparecer bajo las fauces de la deuda técnica.

El objetivo de estas herramientas es conseguir equipos con la capacidad de crear arquitecturas de calidad minimizando los riesgos.

Estas herramientas deben mantenerse en evolución constante incluyendo nuevas prácticas, mejorando los métodos de acompañamiento y mecanismos de validación. Estas tareas pueden correr a cargo de ese equipo de arquitectos especializados de mayor experiencia que pueden pertenecer a ese equipo central o formar una comunidad virtual sin dejar de pertenecer a cada uno de los equipos.

Esta aproximación descentralizada para la elaboración de las arquitecturas de soluciones es lo que permite escalar a la compañía, ya que ese equipo de especialistas, que serían los encargados del diseño bajo un enfoque centralizado, no son un cuello de botella.

Principios generales de diseño

La aproximación al diseño de arquitecturas cuando se trabaja sobre la nube es distinta a cuando trabajamos en entornos on-premise tanto físicos como virtualizados.

Por un lado, tenemos que los entornos en la nube son fácilmente aprovisionables a través de la automatización y disponibles en cortos espacios de tiempo. Esto nos permite probar de forma directa las arquitecturas propuestas y evaluar su desempeño acorde a nuestras necesidades. Nos evita, en parte, el establecimiento de hipótesis de rendimiento que solo se conocen una vez el sistema sea puesto en marcha.

Por otro lado, el coste de este tipo de pruebas en entornos en la nube está acotado al tiempo de uso que dediquemos a nuestras pruebas. Disponemos de recursos físicos específicos que suelen estar disponibles como parte de los servicios de la nube y que no tienen que ser comprados a propósito. Imaginemos la situación donde debiéramos evaluar el rendimiento de una optimización de procesamiento de datos que precisa de GPU en un entorno on-premise. No se podría disponer seguro de toda la potencia de cálculo de un entorno final, pues se optaría en algunos casos de comprar una pequeña partida de máquinas. Si en el peor de los casos finalmente se descarta esta aproximación, ¿qué hacemos con los recursos que hemos adquirido?

La posibilidad de realizar las validaciones con entornos definitivos nos acerca a un mejor de diseño de la solución, pues disponemos de datos reales de rendimiento en tiempo de diseño cuando aún podemos tomar decisiones de cambio minimizando el impacto de dichos cambios.

Gracias a esta flexibilidad, el framework nos invita a dejar de diseñar en base a hipótesis y hacerlo en base a certezas que nos dan las pruebas reales. Este forma de trabajar no se tiene por qué ceñir al desarrollo inicial, sino que podemos realizar pruebas reales con mejoras sobre nuestras cargas de trabajo para que estas se mantengan en un estado óptimo.

Esta manera de trabajar esconde de manera implícita que los equipos de desarrollo deben poder disponer de manera rápida y accesible a la infraestructura y servicios de la nube. Se pone de manifiesto, de nuevo, que este tipo de tecnologías suelen llevar aparejados cambios en los procesos de la organización. Si este tipo de experimentación tiene que pasar un flujo de aprobación (incluso la mera solicitud) o provisionamiento que no es inmediato, acabará por descartarse porque bloquea el flujo de diseño de los equipos.

Esto no significa que los equipos dispongan de manera libre (y descontrolada) de los entornos de la nube. Como ya vimos en los Cloud Adoption Framework podemos abordar el provisimiento de manera automatizada para garantizar que no se crea ningún problema de seguridad, o si se les da acceso a los portales de servicios, podemos crear políticas que garanticen que no se hace un uso indebido o problemático.

Proceso de revisión de las arquitecturas

El proceso de revisión debe integrarse como parte del propio flujo de diseño, de manera que sea un proceso ligero que forme parte del proceso creativo en lugar de parecerse más a una auditoría.

Hay que tener en cuenta que el ejercicio de revisión hace que entendamos de forma profunda las implicaciones del diseño y probablemente sea el momento en que se pongan de manifiesto las ventajas, inconvenientes y problemas que pueda tener nuestra arquitectura.

Si la revisión forma parte de manera natural de nuestro proceso de diseño aumenta la probabilidad de que los problemas se encuentren con anticipación cuando aún la corrección o cambio de enfoque no tienen consecuencias graves en la fecha de entrega.

Para ayudarnos en la integración del proceso de revisión en nuestro flujo de diseño, el framework nos propone una serie de preguntas y principios en cada uno de los pilares de nuestra arquitectura. Esta aproximación hace que dispongamos de una lista de comprobación que puede aplicarse a cada una de las iteraciones de la arquitectura. Es una forma de no depender de la madurez, conocimiento o circunstancias de los arquitectos en el momento de la revisión. Si los elementos de revisión están sistematizados, es más difícil que se escape alguna parte que pueda tener impacto negativo en la calidad final de la arquitectura.

Igual de importante que la ejecución de las revisiones es la orientación a la acción de sus resultados, es decir, nuestro proceso debe incluir la implentación de las correcciones necesarias o investigación de posibles soluciones. Se debe dejar constancia explícita de estas tareas para priorizarlas y hacer seguimiento de las mismas en próximas revisiones o dentro de nuestra metodología de trabajo.

La aplicación continua de las revisiones a las arquitecturas suele identificar problemas o áreas de mejora recurrentes que se dan de manera reiterada en nuestros diseños. El análisis de las causas de esta repetición nos dará lugar posibles acciones de mejora en los equipos implicados que pueden incluir la formación, charlas, elaboración de arquitecturas de referencia o mejora del propio framework de revisión (por ejemplo, incluyendo nuevos elementos de comprobación).

En esta entrada hemos visto los planteamientos comunes que pueden ser aplicados de manera general al proceso de diseño de nuestras arquitecturas. En las próximas entradas recuperaremos los pilares que sustentan una solución de calidad desplegada en la nube y profundizaremos en cada uno de ellos para conocer cómo conseguir estos buenos resultados.