¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Rubén Villar 26/09/2022 Cargando comentarios…
Las arquitecturas de servicios en la nube han supuesto un cambio de paradigma con respecto al despliegue de infraestructura on-premise en nuestros centros de datos.
A lo largo de los años, los equipos encargados de introducir este tipo de servicios han visto como las lecciones aprendidas para gestionar infraestructura en máquinas físicas no servían y ha sido necesario generar nuevos modelos de operaciones ajustados para trabajar en la nube.
Por poner un ejemplo ilustrativo, son muchas las ocasiones que hemos encontrado a compañeros de infraestructura de distintas empresas pidiendo estimar la capacidad necesaria en servidores para nuevas aplicaciones con el fin de provisionar esta capacidad con antelación.
A veces, esta estimación llevaba aparejada la necesidad de comprar más equipos, lo que generaba la presión añadida de estimar correctamente para no quedarse corto ni tampoco pasarse más de la cuenta para no generar costos innecesarios.
Cuando hablamos de la infraestructura en la nube esta situación carece de sentido, ya que sobre el papel disponemos de una infraestructura escalable que podemos ajustar a demanda en cuestión de minutos.
Aunque este ejemplo toque un poco los extremos y parezca evidente que no actuaremos de la misma manera, no es extraño encontrar organizaciones que no repiensan su forma de operar y las implicaciones que no hacer este ejercicio esto supone.
Encontramos como para disponer de entornos tenemos que completar órdenes de soporte que se completan días (o semanas) después, matando de un plumazo uno de los baluartes de la agilidad cloud.
En el blog ya hemos hablado en muchas ocasiones del elemento transformador de la adopción de las tecnologías en la nube y cómo su introducción es un desafío que va más allá de lo tecnológico.
Esta fue la génesis de nuestro interés en introducir los frameworks de adopción en la nube (CAF) de los que hemos hablado largo y tendido en una serie de post sobre los CAF de los distintos proveedores cloud (AWS, GCP y Azure).
Situaciones como la descrita, con respecto al modelo de operaciones, se tratan dentro de un marco holístico que no trata solo las operaciones, sino que abarca desde la estrategia hasta la capacitación de las personas, por citar algunas otras dimensiones.
Al igual que en su momento los proveedores cloud detectaron el enorme reto que la adopción de la nube suponía para sus clientes y acudieron en auxilio dando forma a los CAF, también han detectado a lo largo de los años el desequilibrio que supone no encarar convenientemente el diseño de arquitecturas en la nube. Por ello dieron forma y pusieron a nuestra disposición los Well-Architected Frameworks.
Todos los proveedores cloud cuentan con su propio Well-Architected Framework. La propuesta de AWS, en la que nos vamos a centrar, nació en el año 2015 y ha ido enriqueciéndose a lo largo de estos años con toda la experiencia generada.
Hemos mencionado el desafío que supone el diseño de arquitecturas en la nube y cómo los Well-Architected Framework pueden ayudarnos a encararlo con éxito. Antes de empezar a destilar el framework, merece la pena detenerse en qué es una arquitectura en la nube.
En la ingeniería informática entendemos una arquitectura como un modelo conceptual que define los componentes, relaciones, interacciones y despliegue de nuestro sistema. Es una de las principales actividades del diseño cuyo producto suele incluir un diagrama de arquitectura.
Los diagramas de arquitectura pueden seguir distintos enfoques o modalidades. Disponemos de diagramas de arquitectura lógica cuya misión es enumerar los componentes de nuestro sistema en la nube y las interacciones entre los mismos.
Por otro lado, también suele ser habitual completar el diagrama lógico con un diagrama de arquitectura física cuyo detalle es más exhaustivo, ya que incorpora la ubicación de los componentes y su conectividad de red.
En todos los casos, los diagramas reflejan de forma implícita decisiones de diseño de arquitectura que condicionan dimensiones importantes de nuestro sistema: rendimiento, disponibilidad, seguridad y coste (solo por citar algunas de ellas).
El AWS Well-architected Framework nació con el objetivo de ayudarnos a comprender las ventajas e inconvenientes de nuestras decisiones de arquitectura. Toda decisión suele tener contrapartidas y muchas veces no se trata de eliminar dichos compromisos, sino de entender qué implicaciones tienen y qué nos permiten conseguir. En el argot de arquitectura se conoce como entender los trade-offs de nuestro diseño y hacer de ellos una elección explícita y conocida.
Por ejemplo, nuestros diseños perseguirán, o al menos deberían, reducir los costes al máximo. Sin embargo, si queremos alcanzar unas cotas importantes de disponibilidad entenderemos que ciertos componentes deberán estar replicados en distintas ubicaciones o utilizar niveles de servicio de soluciones gestionadas que nos den esta disponibilidad.
Esto llevará aparejado un incremento del coste por debajo del cual sabremos que empezaremos a penalizar la disponibilidad de nuestra aplicación. Si no contamos con el presupuesto necesario y tenemos que hacer recortes en este sentido, seremos conscientes y tomaremos una decisión informada de que asumimos un grado de riesgo en la disponibilidad por acotar el coste.
AWS Well-architected Framework nos guía para revisar nuestras arquitecturas de forma constructiva, validarla contra las mejores prácticas e identificar áreas de mejora. No se trata en ningún caso de una auditoría de nuestra arquitectura, sino de recomendaciones para evaluar de forma consistente y sistematizada nuestros diseños contra un estándar exigente de calidad.
Seguir el AWS Well-architected Framework no nos da, per se, un sello que certifique el cumplimiento de ciertas normativas (PCI-DSS, HIPAA/HITECH, GDPR, etc.) pero sin duda nos ayudará a disponer de un punto de partida más completo si necesitamos certificar alguna de ellas.
Al ser una guía eminentemente técnica el público objetivo del marco de trabajo serán los responsables técnicos de nuestra organización que pueden ir desde el CTO, los distintos arquitectos, desarrolladores o personal de operaciones.
En todo marco de trabajo es importante contar con una terminología común que nos permita asegurar que todo el equipo entendemos lo mismo y con los mismos matices. Antes de introducir los pilares de diseño del framework, este acuerda una serie de términos básicos que se utilizarán en el resto de documentación.
Una vez introducidos los conceptos comunes es hora de llegar al meollo de la cuestión. Si habéis curioseado el framework seguramente sea esta parte la que más os resuene o puede que sea la que, de manera informal, abordéis a la hora de evaluar vuestras arquitecturas en la nube.
El AWS Well-Architected Framework define seis pilares fundamentales. Estos pilares son las dimensiones que deben tratarse de forma sistemática cuando se diseña una arquitectura en la nube.
Los pilares están alineados con las mejores prácticas de sistemas en la nube y nos dan acceso a distintos patrones que podemos introducir según los objetivos marcados para nuestra arquitectura.
Vamos a ver la descripción de cada uno de los pilares:
El AWS Well-Architected Framework es una de las herramientas indispensables que potencia nuestras habilidades para trabajar en la nube. La experiencia real que subyace en sus patrones y buenas prácticas suma a una forma de trabajar que tardaríamos tiempo en optimizar por nuestros propios medios.
En este post hemos dado las pinceladas necesarias para conocer los conceptos básicos y los pilares sobre los que se sustenta la aplicación del framework. En próximas entradas profundizaremos en los métodos para introducir sus guías en nuestra práctica de diseño y comentaremos con detalle cada uno de los pilares del framework. Esperamos que este contenido os resulte de interés. ¡Gracias por leernos!
¡Entonces no te pierdas este podcast!
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.