Las malas decisiones a la hora de diseñar la arquitectura en la Nube, le puede costar a su empresa desde dinero hasta prestigio, y más importante comprometer su mayor activo “La Información”. Sin embargo diseñar una Buena arquitectura en AWS, no es un trabajo simple o instantáneo, es evolutivo y totalmente dependiente de los objetivos de negocio y en general la arquitectura empresarial.

¿Cual es la definición de una buena arquitectura de un sistema?

Y de aquí parte todo, pues una buena arquitectura de un sistema está directamente relacionada a los requisitos de ese sistema y a los requerimientos a nivel corporativo.

Un sistema critico, requiere de unas tecnologías, una fiabilidad, un rendimiento, una seguridad y un plan de continuidad propio de su negocio, mientras que en la misma empresa otro de sus sistemas crítico requiere de su propia definición en los mismo términos.

Entonces, lo importante es desarrollar la habilidad para diseñar y operar sistemas basados en las mejores prácticas y con un enfoque de constante evolución.

Una Buena Arquitectura en AWS

AWS en torno a este importante aspecto, ha creado una guía llamada “AWS Well-Architected” que nos ayudara comprender las ventajas y desventajas de las decisiones tomadas con relación al diseño y la operación de los sistemas en la Nube.

Nota: En adelante una carga de trabajo (workload) en AWS se refiere a un conjunto de componentes que juntos entregan el valor de negocio.

AWS Well-Architected principalmente nos provee de:

• Un conjunto de preguntas para medir sus sistemas continuamente en función de prácticas recomendadas.
• Un servicio “AWS Well-Architected Tool” que revisa y mide su arquitectura, basado en las mejores prácticas y los objetivos de negocio de las cargas de trabajo.
• Una lista de patrones arquitectónicos para ser aplicados.
• Un conjunto de laboratorios (Well-Architected Labs) con código y documentación para capacitar con experiencia práctica en la aplicación de las prácticas recomendadas.

Estas herramientas nos permiten entender, seleccionar e implementar conceptos claves, principios de diseño y mejores prácticas para sistemas seguros, fiables, eficientes y rentables, permitiendo así desarrollar esa Buena Arquitectura en AWS y que esté alineada también al requerimiento del negocio.

AWS Well-Architected está direccionado al equipo de tecnología: directores, arquitectos, desarrolladores y miembros de operaciones.

El objetivo o razón de ser del marco de trabajo Well-Architected, es evaluar las arquitecturas frente a las mejores prácticas y frente a los requerimientos esperados por el negocio, de forma que podamos identificar áreas de mejora y fallos en el estado actual de los sistemas si fuese el caso.

También es importante mencionar que AWS tiene un conjunto de socios en el mundo (Partners AWS), con conocimiento profundo de arquitectura y que apoya a los clientes en su proceso de adopción de la Nube.

Los 6 Pilares de una Buena Arquitectura en AWS

Las tecnologías pueden evolucionar y los paradigmas de diseño pueden cambiar, pero los pilares que definen una buen arquitectura en AWS se mantienen en el tiempo.

AWS Well-Architected basa su guía AWS en 6 pilares que la definen:

Al diseñar la arquitectura de nuestras cargas de trabajo, normalmente hacemos concesiones entre los pilares de una buena arquitectura, por ejemplo priorizamos la optimización de costos frente a la fiabilidad por ser ambientes de desarrollo o procesamientos no críticos. Hay otros casos en donde vamos a priorizar la fiabilidad por sobre el costo y equilibrar el rendimiento.

En AWS los pilares no negociables son la seguridad (principio de Confianza Cero en AWS) y la excelencia operacional pues representa un riesgo muy superior para cualquier negocio.

El equipo y la Arquitectura

En los esquemas tradicionales on-premises se suele tener equipos encargados de ciertas actividades y cumplen roles como: Arquitectos de Infraestructura, Arquitectos de Software, Arquitectos de Datos, Arquitectos de Redes y Arquitectos de Seguridades. Ellos representan capas en la implementación de cargas de trabajo en la empresa, y aseguran estándares y políticas que deben cumplirse.

En la actualidad el Time to Market marca la diferencia entre una empresa y otra, esto, por la velocidad con que cambia el mercado y las interacciones. Desde este punto de vista la “Agilidad Empresarial” es crítica para competir y ganar el mercado, y ha significado eliminar capas en procesos de entrega de valor e innovación, y generar equipos descentralizados y multi-disciplinarios.

Esto sin duda ha sido adoptado por AWS para convertirse en el Líder del mercado, y por lo cual recomienda a sus clientes implementar estos equipos descentralizados y multi-disciplinarios pero asegurando el cumplimiento de estándares y políticas, dado que la autonomía de los equipos puede derivar en prácticas diversas.

Para mitigar el riesgo, del no cumplimiento de estándares y políticas, AWS ha creado y recomienda crear prácticas, estándares, normas y mecanismos (a menudo automatizados) que deben aplicar sus equipos.

Las buenas intenciones nunca funcionan, se necesitan buenos mecanismos para que todo suceda.

Jeff Bezos

La implementación de las prácticas y mecanismos es una habilidad que el equipo va ganando en el tiempo y es soportada en AWS con la habilitación de una comunidad virtual de “Principal engineers” o expertos que apoyan con:

• Revisión de diseños.
• Entrenamientos.
• Conversatorios, y sesiones de Preguntas y Respuestas.
• Talleres.

En el mundo de Agilidad, esto se conoce como club o células de mejora, en donde participantes de diferentes equipos pueden asistir, de forma que se refuerza, capacita o se crea conocimientos alrededor de la implementación de prácticas y mecanismos.

Principios Generales de Diseño en AWS

Finalmente queremos mencionar los principios generales de diseño para una buena arquitectura en AWS, que nos recomiendan en la guía AWS Well-Architect:

1. Dejar de adivinar sus necesidades de capacidad, aprender primero empezando con recursos mínimos.
2. Probar sus sistemas a escala de producción, usar especificaciones reales en las pruebas. Lo que es posible en la Nube, ya que en lugar de adquirir todos los recursos como en una prueba on-premises puede aprovisionar los mismos en AWS con costos a demanda.
3. Automatizar para facilitar la experimentación arquitectónica, automatizar la provisión sus cargas de trabajo a bajo costo para crear y replicar ambientes.
4. Trabajar con arquitectura evolutiva, permitir la evolución de sus cargas de trabajo de acuerdo a la evolución de negocio para optimizar los recursos, costos y acceder progresivamente a escalamientos de diseño y recursos.
5. Impulsar arquitecturas basadas en datos, recopilar datos de las operaciones de sus cargas de trabajo constantemente de forma que nos den indicadores para mejorar los diseños y optimizar procesos y procedimientos.
6. Mejora basada en pruebas, ejecutar pruebas ocasionales a su arquitectura y sus procesos, para comprender donde hay oportunidades de mejora y omisiones que pueden costar al negocio.

Pensamientos Finales

Una Buena Arquitectura en AWS en un proceso evolutivo, en donde debemos experimentar, aprender y mejorar, tareas que afortunadamente son factibles y convenientes económicamente gracias a la estructura de Costos de AWS.

Una Arquitectura Empresarial puede involucrar, y seguramente es así siempre, más que solo la Nube; con estrategias híbridas (on-promises y Nube) o multi Nube. La clave es alinear las decisiones a la estrategia del negocio y presupuesto para luego decidir el como, pero siempre asegurando la seguridad, fiabilidad, eficiencia, rentabilidad y sostenibilidad.

El equipo es clave, y tenerlo capacitado, empoderado y asesorado le va a permitir a su organización acceder a las nuevas posibilidades de implementación de sus cargas de trabajo y a tecnologías emergentes como Machine Learning, IoT o Bigdata por una fracción del costo de soluciones on-premises y sin contratos complejos.

Esperamos que sea útil esta introducción a una Buena Arquitectura en AWS y les animamos para que dejen sus comentarios y opiniones para aprender en comunidad.