De Zero a Alta disponibilidad para HTTP con Terraform y AWS

Este documento resume un proyecto práctico sobre cómo crear un sistema web que funcione sin interrupciones. El proyecto usa Terraform (una herramienta para automatizar la creación de infraestructura) y Amazon Web Services (AWS). El problema que resuelve es simple: crear y configurar manualmente todos los recursos necesarios es complicado, toma mucho tiempo y es fácil cometer errores. La solución automatiza todo este trabajo usando código de Terraform que maneja los componentes de AWS. El proyecto se basa en tres ideas principales: copiar recursos (tener múltiples servidores), repartir la carga entre los servidores y tener respaldos listos para cuando algo falle. El sistema usa un balanceador de carga de aplicaciones, grupos de destino y un grupo de autoescalado que ajusta automáticamente la cantidad de servidores según el uso de CPU. Las pruebas demostraron que el sistema funciona: detecta cuando hay mucha actividad, activa alarmas y crea más servidores automáticamente cuando es necesario.

1. Por qué es importante que los servicios siempre funcionen

Mantener un servicio funcionando casi todo el tiempo es fundamental para cualquier negocio moderno. Esto significa que el servicio debe estar disponible y ser confiable para los clientes la mayor parte del tiempo posible. Su importancia es clara: garantiza que el negocio siga operando sin interrupciones, evitando problemas que afectan los ingresos y la confianza de los clientes.

IBM lo define así:

"La alta disponibilidad es lograr que un servicio esté funcionando y sea confiable para los clientes, no necesariamente el 100% del tiempo, pero la mayor parte del tiempo posible".

2. Tres técnicas clave usadas en el proyecto

Para lograr que el servicio funcione sin interrupciones, el proyecto usó tres técnicas importantes:

• Copiar recursos: Crear varias copias de un servidor (como una instancia EC2) a partir de una plantilla. Así hay múltiples servidores idénticos listos para atender solicitudes.

• Repartir la carga: Distribuir el tráfico web entre varios servidores. El objetivo es que ningún servidor se sobrecargue y todos funcionen de manera óptima.

• Tener respaldos: Mantener un sistema de respaldo inactivo mientras el sistema principal funciona. Si el sistema principal falla, el sistema de respaldo se activa automáticamente para que el servicio no se detenga.

3. El problema: hacerlo manualmente es muy complicado

Implementar estas técnicas de forma manual presenta grandes desafíos. Hay que crear, conectar y configurar muchos recursos—un proceso que consume mucho tiempo y es fácil cometer errores.

El mayor problema surge al copiar la infraestructura en diferentes ambientes (por ejemplo, de un ambiente de prueba a otro). Este trabajo repetitivo es tedioso y no se puede escalar fácilmente.

4. La solución: automatizar todo con Terraform

Para resolver los problemas de la gestión manual, el proyecto usó un enfoque llamado Infraestructura como Código con Terraform. Esta herramienta permite automatizar la creación y gestión de toda la infraestructura usando código.

Ventajas de usar Terraform

• Fácil de leer: La sintaxis es clara e intuitiva, fácil de entender.

• Control de cambios: Terraform compara lo que tienes actualmente con lo que quieres crear. Antes de hacer cambios, muestra un plan detallado de lo que va a crear, modificar o eliminar.

• Historial de versiones: El código de Terraform se puede guardar en sistemas como Git, permitiendo trabajar en equipo, ver el historial de cambios y volver a versiones anteriores si es necesario.

• Código reutilizable: El proyecto se organizó usando módulos (como funciones) que agrupan recursos relacionados. Esto permite reutilizar código y mantener todo organizado.

5. Componentes principales del proyecto en AWS

El código de Terraform controla varios recursos importantes en AWS:

6. Cómo funciona el escalado automático

El sistema funciona mediante un ciclo automatizado de monitoreo y acción:

1. Monitoreo: Se vigila constantemente una métrica, como el uso promedio de CPU. Si supera un límite (por ejemplo, más del 40% durante 3 minutos), se activa una alarma en CloudWatch.

2. Activación de la política: La alarma envía una señal al Grupo de Autoescalado, activando la política correspondiente.

3. Acción: El Grupo de Autoescalado ajusta la cantidad de servidores. Si hay mucha carga, crea nuevos servidores a partir de la plantilla.

4. Actualización: El sistema actualiza automáticamente la lista de servidores disponibles en el Grupo de Destino. Esto permite que el Balanceador de Carga empiece a enviarles tráfico inmediatamente.

7. Resultados de la prueba práctica

Se probó que la solución funciona mediante una demostración:

• Inicio: Se empezó con una cuenta de AWS vacía.

• Despliegue: Se ejecutó el comando terraform apply, que creó toda la infraestructura automáticamente: balanceador de carga, grupo de autoescalado, grupo de destino y un servidor inicial.

• Prueba de carga: Se usó un script para generar muchas solicitudes web al balanceador, simulando mucho tráfico.

• Resultado:
  • Los gráficos de CloudWatch mostraron que el uso de CPU superó el 40%.
  • La alarma se activó correctamente.
  • El sistema creó automáticamente tres nuevos servidores para manejar la carga adicional.

La prueba confirmó que el sistema responde automáticamente a los cambios de carga, manteniendo el servicio funcionando.

8. Conclusiones importantes

• Importancia crítica: Mantener los servicios funcionando es esencial para cualquier negocio con muchos clientes.

• Valor de las pruebas: Se recomienda hacer pruebas de caos para verificar que el sistema responde bien cuando algo falla.

• Usar servicios en la nube: Proveedores como AWS ofrecen los componentes necesarios para construir sistemas robustos.

• Automatización vital: Herramientas como Terraform son indispensables para gestionar infraestructuras con más de 10 o 20 recursos, aportando automatización y consistencia.

Este documento sintetiza la arquitectura y hallazgos de un proyecto práctico enfocado en implementar un sistema de alta disponibilidad para servicios HTTP. Utiliza Terraform como herramienta de Infraestructura como Código (IaC) sobre Amazon Web Services (AWS). El problema central es la complejidad y naturaleza tediosa de crear y configurar manualmente los numerosos recursos necesarios para garantizar la resiliencia—un proceso ineficiente al replicar entornos. La solución propuesta automatiza este despliegue mediante un módulo de Terraform que orquesta los componentes de AWS. El proyecto se fundamenta en tres técnicas clave de alta disponibilidad: replicación de recursos, balanceo de carga para distribuir el tráfico y redundancia para asegurar la continuidad mediante sistemas de respaldo y procesos de failover. La arquitectura resultante utiliza un Application Load Balancer, Target Groups y—de manera central—un Auto Scaling Group configurado con políticas de escalado dinámico basadas en métricas como el uso de CPU. La demostración práctica validó que el sistema detecta aumentos de carga, dispara alarmas de CloudWatch y escala horizontalmente de forma automática, demostrando la viabilidad y eficiencia del enfoque IaC para construir infraestructuras robustas y autogestionadas.

1. El Imperativo de la Alta Disponibilidad

La alta disponibilidad (HA) se ha convertido en un pilar fundamental para las operaciones de negocio modernas. Se define como la capacidad de un servicio para estar disponible y ser confiable para los clientes la mayor cantidad de tiempo posible. Su importancia es crucial: garantiza la continuidad de los flujos de trabajo y procesos de negocio, evitando caídas que impactan negativamente los ingresos y la confianza del cliente.

Una cita de un post de IBM define el concepto así:

"La alta disponibilidad de los servicios es un concepto que trata de que un servicio que tú tengas que esté funcionando, que sea o que esté disponible y que sea fiable para clientes, no necesariamente el 100% del tiempo, pero la mayor cantidad de tiempo posible".

2. Técnicas Fundamentales Implementadas

Para lograr la alta disponibilidad en el proyecto, se aplicaron tres técnicas esenciales utilizadas comúnmente en la gestión de infraestructura para servicios HTTP.

• Replicación: Crea múltiples copias de un recurso (como una instancia EC2) a partir de una plantilla. Esto asegura que existan múltiples unidades de trabajo idénticas listas para procesar solicitudes.

• Balanceo de Carga (Load Balancing): Distribuye el tráfico de red—ya sea interno o externo—entre un conjunto de recursos o servidores backend. Su objetivo es mantener un estado operativo óptimo, evitando que un solo recurso se sobrecargue.

• Redundancia: Mantiene un sistema secundario o de respaldo (backup) que permanece inactivo mientras el sistema principal está operativo. En caso de falla del sistema primario, se activa un proceso de conmutación por error (failover), donde el sistema secundario asume las operaciones para minimizar el tiempo de inactividad (downtime).

3. El Problema: Complejidad de la Implementación Manual

La implementación manual de estas técnicas presenta desafíos significativos. Requiere crear, conectar y configurar una gran cantidad de recursos—un proceso que no solo consume tiempo sino que también es propenso a errores humanos.

El principal punto de fricción surge al replicar la infraestructura en diferentes entornos (por ejemplo, de un entorno de staging a otro). Este trabajo repetitivo se convierte en un proceso tedioso que carece de escalabilidad y consistencia.

4. La Solución: Infraestructura como Código con Terraform

Para superar los desafíos de la gestión manual, el proyecto adoptó un enfoque de Infraestructura como Código (IaC) utilizando Terraform. Esta herramienta permite automatizar el aprovisionamiento y la gestión del ciclo de vida de la infraestructura de manera declarativa.

Ventajas de Terraform en el Proyecto

• Lenguaje Legible por Humanos: Su sintaxis declarativa es intuitiva y facilita la comprensión de la infraestructura definida.

• Seguimiento de Cambios: Terraform utiliza un archivo de estado para comparar la configuración actual con la infraestructura desplegada. Antes de aplicar cambios, muestra un plan detallado de lo que se creará, modificará o eliminará, proporcionando seguridad y previsibilidad.

• Control de Versiones: El código de Terraform puede versionarse en sistemas como Git, permitiendo el trabajo colaborativo, el seguimiento del historial de cambios y la capacidad de revertir a versiones anteriores.

• Modularidad: El proyecto se estructuró usando módulos de Terraform, que actúan como funciones reutilizables agrupando recursos relacionados (ej. networking, seguridad, balanceo de carga). Esto promueve la reutilización de código y una organización lógica de la infraestructura.

5. Arquitectura del Proyecto en AWS

El módulo de Terraform desarrollado orquesta un conjunto de recursos clave en AWS para construir la arquitectura de alta disponibilidad.

6. Mecanismo de Autoescalado Dinámico: Flujo de Operación

El núcleo funcional del sistema se basa en un ciclo de retroalimentación automatizado entre el monitoreo y la acción, orquestado por varios servicios de AWS.

1. Monitoreo y Detección: Una métrica, como el promedio de uso de CPU de las instancias, es monitoreada continuamente. Si supera un umbral predefinido (ej. >40% durante 3 minutos), se activa una alarma de CloudWatch.

2. Disparo de la Política: La alarma de CloudWatch envía una señal al Auto Scaling Group, activando la política de escalado correspondiente.

3. Acción de Escalado: El Auto Scaling Group, usando sus algoritmos internos, ajusta la cantidad de instancias. En caso de alta carga, aprovisiona nuevas instancias a partir de la plantilla definida para escalar horizontalmente (scale out).

4. Actualización del Balanceador: El ASG actualiza automáticamente la lista de instancias disponibles en el Target Group. Esto informa al Application Load Balancer sobre las nuevas instancias saludables, permitiéndole comenzar a dirigirles tráfico de inmediato.

7. Resultados de la Demostración Práctica

La efectividad de la solución fue validada mediante una demostración en vivo que siguió estos pasos:

• Estado Inicial: Se partió de una cuenta de AWS sin recursos preexistentes.

• Despliegue con Terraform: Se ejecutó el comando terraform apply, que aprovisionó toda la infraestructura definida en el código: un ALB, un ASG, un Target Group y una instancia EC2 inicial (configurada como el estado deseado al inicio).

• Prueba de Estrés: Se utilizó un script para generar una carga constante de solicitudes HTTP al ALB, simulando un aumento de tráfico.

• Respuesta del Sistema:
  • Los gráficos de CloudWatch mostraron que el uso de CPU de la instancia superó el umbral del 40%.
  • La alarma de CloudWatch se disparó correctamente.
  • La política de escalado se activó, y el Auto Scaling Group creó automáticamente tres nuevas instancias para manejar la carga adicional.

La demostración confirmó que la arquitectura reacciona autónomamente a las condiciones de carga, manteniendo la disponibilidad del servicio.

8. Conclusiones y Lecciones Clave

• Criticidad de la Alta Disponibilidad: Es una práctica esencial para cualquier negocio con una base de clientes considerable, garantizando la continuidad y la confianza.

• Importancia de las Pruebas: Se recomienda realizar "pruebas del caos" (chaos testing) para predecir el comportamiento del sistema ante fallos y validar la resiliencia de la arquitectura.

• Aprovechamiento de Servicios Cloud: Los proveedores como AWS ofrecen los componentes necesarios ("building blocks") para construir sistemas de alta disponibilidad complejos.

• El Papel Vital de IaC: Herramientas como Terraform son indispensables para gestionar infraestructuras con más de 10 o 20 recursos, aportando automatización, consistencia y escalabilidad al proceso.

Anexo: Sesión de Preguntas y Respuestas

Durante la sesión final, se abordaron preguntas clave que arrojaron luz sobre aspectos adicionales de la implementación.

charla y pues ahora te cedo la palabra para que nos pueda hablar de este bonito tema.
Ya, gracias.
Gracias, gracias. Eh, buenas noches. Eh, bueno, gracias por la invitación. Eh, sí, bueno, básicamente quiero la idea de este de esta presentación es compartir un un proyecto que he estado trabajando manera de práctica eh en los últimos meses eh relacionado en parte a WS. Entonces, yo dije, bueno, vamos a llevar allá con los muchachos para que partamos y haya retroalimentación y veamos qué ideas buenas surgen, ¿no?, a partir de esta competación. Eh, ¿de qué trata? Bueno, básicamente el cículo, como lo vemos allí, eh, de cero alta disponibilidad para HTTP con Terrafor y AWS. Bien, bien. Eh, está dividido en tres partes. Eh, tenemos primero una parte introductoria donde vamos a hablar un poquito las definiciones, el problema solución, eh un poquito cómo funciona el proyecto, el módulo que se creó aquí. Eh, una demo, un videío les voy a mostrar para que veamos más o menos eh prácticamente cómo está funcionando y conclusiones con algunas lecciones. Muy bien, entonces vamos a la frase clave, ¿no? Eh, bueno, hoy en día en lo que son en lo que es ya la las industrias cómo se está moviendo. Eh, es crucial, es vital que todas las compañías eh practiquen lo que es la alta disponibilidad en sus servicios y precisamente en servicio de tipo que maneja el protocolo HTTP. Eh, esto para que le permita, ¿verdad?, que sus negocios, sus flujos de trabajo, sus procesos eh estén continuamente eh funcionando. es decir, que evitemos que hayan caídas y todo el tipo de eh de problemas. Pero okay, hablamos de alta disponibilidad. Pero, ¿qué de qué se trata esto de alta disponibilidad? Bueno, eh un concepto que vi chévere en un post de de esta empresa IBM, eh ellos mencionan que la alta disponibilidad de los servicios es un concepto que trata de eh de que un servicio que tú tengas eh que esté funcionando esté que sea o que esté disponible y que sea fiable, ¿verdad?, para clientes, eh no necesariamente el 100% del tiempo, pero la mayor cantidad de tiempo posible, porque eso le da confianza a los clientes, eh hace que tu máquina de de producto esté siempre continuamente funcionando y obviamente eso eh mantiene su su esquema de negocio activo. Para poder mantener este concepto de alta disponibilidad existen muchas técnicas, ¿verdad?, que en el mundo de la infraestructura se practican. Eh, pero para efecto de este proyecto, eh, yo voy a mencionar tres las cuales eh usé de referencia y las puse en práctica. Bien, tres técnicas que comúnmente cuando estén ustedes trabajando en este mundo de servicio HTTP van a van a estar por ahí escuchándola. La primera, eh, Tenemos replicación. Replicación simplemente se trata el concepto de que tienes un recurso, digamos, un servidor, una instancia C2, eh tienes que tener la capacidad de eh de que tú puedas replicar ese ese recurso o hacer copias a partir de una plantilla para que lo uses para cumplir ciertas necesidades. ¿Cuáles? Vamos a ver para qué nos puede servir. Una de esas necesidades pudiese ser para usarlas en lo que es un proceso de balanceo de carga. El balanceo de carga no es más que eh un mecanismo que permite distribuir tráfico, ya sea externo o interno, eh a distintas cargas o a distintos recursos que tú tengas en un backet para que esto te permita mantener un estado óptimo, ¿verdad?, del funcionamiento del servicio. Hay mucho tráfico, el balanceador de carga puede distribuir eh entre varios lobos para que eh esté en un estado aceptando. Okay, esa es otra de las técnicas. La tercera se llama redundancia. Eh, redundancia se trata de eh un mecanismo, ¿verdad? O o un proceso en donde se aplica o se practica para que cuando tú tengas eh tu sistema principal, ¿verdad?, que está funcionando, está online, siempre debes tener, sobre todo cuando son sistemas críticos, debes tener, como quien dice tu backup, es decir, un sistema que tengas allí por si acaso. Ahí tienes al un problema en el sistema principal. Entonces, si esto ocurre esto, eh activa la redundancia y eh se activa o o ocurre lo que es el switch, se llama failover. Lo van a escuchar seguramente. Ese failover es el proceso del switch cuando el primario por alguna razón x o y z eh tiene algún problema. Entonces se activa y el secundario toma ahora el mando para tratar de así esté lento, así esté digamos un poco o calentándose tarde tiempo, pero eh tienen allí como que algo seguro para que para evitar eh el la menor cantidad de down time. Okay. Entonces, tenemos esas tres técnicas. Bien, en algunos proyectos que estuve trabajando ya, sí, hace ya meses, incluso un par de años, eh me di cuenta que nada, cuando estás tratando de crear los recursos cursos para poder eh establecer estas técnicas, eh necesitas una gran cantidad de recursos, necesitas crearlo. Además necesitas hacer conexiones, configuraciones y todo ese tipo de trabajo. Eh, digamos que lo hace la primera vez, lo hace para un environment, digamos, un environment que se llame state, ¿verdad? Bien, lo cumpliste, hiciste todo, pero llegamos a los 6 meses te pidieron, mira, ha lo mismo para otro envid Entonces, tienes que volver a hacer, ya recordaste, oye, tengo que crear 20 recursos, tengo que conectarlo, quizás tengas por allí tu procedimiento, eh, notas, guías, pero allí está el problema. Se vuelve un proceso tedioso cuando quiere eh digamos replicar un trabajo que hiciste aquí, ahora aquí. Entonces, ahí está el problema y aparte para poder aplicar todo eh digamos para aplicar las técnicas que vimos. Entonces,
voy a poner la
siguiente, por favor.
No es mí
la solución para herramientas que te ayuden a, digamos, automatizar lo más que pueda ese tipo de de trabajo. Una de esas herramientas eh que se usan eh son esas herramientas de de la categoría que llamamos infraestructura como código. En este proyecto eh yo me yo elegí o me decidí a trabajar con Terrafom. Es una de estas herramientas que te cubre eh o te ayuda a cubrir esta necesidad que les mencioné ahorita. Eh tiene ciertas ventajas con respecto a otra herramientas y además te facilita ese trabajo de
de la creación de de los recursos para cumplir con las técnicas aplicación, redundancia y balanceo. Muy bien. Okay. Sí. Okay. Ya como vimos de qué trata o de qué va la cosa, vamos a ver ahora cómo funciona ese módulo que eh yo he elaborado con con Terra. Bien, aquí les muestro un diagrama de arquitectura, lo que llegó hasta ahora con los recursos, digamos, los principales. Hay unos por allí secundarios que bueno, digamos eh no para efecto de lo que es esta posición no son tan importantes, pero mayúscula
vamos a mencionar por los momentos eh los que están relacionados a las técnicas que les les mencioné
de arriba de arriba de izquierda a derecha tenemos el primero, el application ad balancer, les mencioné el concepto ahorita
eh en AWS ellos tienen ese recurso y lo que haces es eso, eh recibes tráfico externo o interno y lo enrut a un conjunto de targets, en este caso eh para el proyecto eh son instancias S2, ¿verdad? Todo minúsculo,
que eh están agrupadas en otro recurso que se llama Target Group. Este Target Group sirve eh precisamente para definir cuáles son esos recursos o instancias disponibles para que los adancer las use, ¿verdad? A su vez, ese target hace con como de pivote entre el balanceador de carga y el siguiente recurso que está a su derecha que se llama el grupo de autoescalamiento, autoescaling group. Ese para este proyecto vendría siendo el recurso más importante. ¿Por qué? Bueno, porque este recurso te permite aplicar varias eh sí, de las técnicas que mencionamos eh anteriormente. Eh, el Autocalling Group básicamente es un recurso de WS que te permite replicar ¿verdad?, en base a ciertas necesidades y no solo replicar eh digamos crear crear esas copias, sino también quitar según esas necesidades e utiliza un esquema de políticas, ¿verdad?, para poder plasmar esas necesidades que les menciono, esas condiciones. Se llaman política de escalamiento. E esto, este grupo de autoescalamiento usa perdón Este grupo de autoescalamiento tiene muchos métodos para eh cómo ustedes escalar ahí que si eh agendado. Por ejemplo, los lunes mi servicio normalmente tiene bastante tráfico, entonces le voy a exponer el lunes que me inicie eh o me cree instancia. Hay otro que es predictivo. Eh revisa ahí ciertos valores, no sé qué de la instancia. Entonces si se cumplen condiciones eh que pudiese el día jueves, eh lanza instancias el día jueves y el que yo utilicé aquí que se llama es el método eh dinámico basado en métricas. Básicamente lo que hace eh eh este método es que utiliza métricas de las instancias, eh las evalúa y si se cumplen las condiciones de la para la métrica, si se cumplen condiciones que pasen umbrales, ¿verdad? Entonces allí actúa, lanza instancia, quita instancia. Bien, entonces ese fue esa es la metodología que utilizamos aquí. Eh, sí, el resto de los componentes que ven allí de los recursos son ya algunos que ustedes han visto que si SNETs, BTC, Security Groups. Eh, vamos a continuar a darle un poquito más de profundidad a cómo funciona estas políticas de las políticas relacionadas al grupo de escalamiento. Bueno, fíjense lo siguiente. ¿Cómo funciona adentro el grupo de escalamiento con esta metodología? Resulta que nosotros políticas eh para el grupo, son como subrecursos del grupo de escalamiento, ¿no? Y le dice, "Mira, yo quiero para la métrica, por ejemplo, CPU, el CPU eh de las instancias, el promedio de de uso de CPU de las instancias, sio un umbral de, por ejemplo, 40%, entonces actúa. ¿Okay? Eso lo definimos como recursos de AWS normal, así política. Pero, ¿qué pasa? ¿Qué hace los escalamientos cuando tú crees esas políticas? crea lo que son las alarmas de Cloudwatch, lo mencionó Noemi ahorita un tipo de otro tipo de de servicio. Eh, y entonces él transforma esas políticas, eh, las transforma o en parte eh crea alarmas basados en las políticas para usarnos de generadores de venta. Viendo aquí un poquito el gráfico, en el número uno, supongamos que eh el promedio de CP en una instancia sobrepaón umbral de 40%, es decir, e ¿Está pasando algo? El número uno, el primer paso sería que alerta, ¿verdad? Genera allí unas alarmas de cloudw y eso dispara e las políticas de autoescalamiento, es decir, envía la señal al al grupo de autoescalamiento. Bien, el paso dos sería este grupo de autoescalamiento actúa utilizando ciertas fórmulas, algoritmos, ¿verdad? Eh, y utilizando como entrada estas eh señales que le mandó Cloudwatch para ver si quita o agrega instancia. Y eso sería el paso dos, ¿verdad? El paso tres, recordemos que el low balancer a través del target group como pivote eh utilizar las eh las instancias que estén disponibles en el momento. Entonces, si el grupo de escalamiento elimina algo aquí, él le tiene que de alguna manera eh proveer la información al balanceador para que ey, ya Esto no existe. Entonces existe este o hay tres, ahora hay tres, ahora o ahora hay uno solamente, ¿verdad? En el tiempo. Entonces el paso tres se trata de eso. En el grupo, en el target room, él actualiza esa lista de disponibilidad y así el balanceó de carga tranquilo, sigue trabajando con lo que tiene. Bien, eso sería cómo funciona. Eh, ahora vamos a ver eh un poquito cómo se trabajó, el cómo de del módulo que se trabajó. Bien, les mencioné que utilicé Terrafone en la herramienta de infraestructura como código. Ventajas que te ayudan para este tipo de proyecto. Primero que es un lenguaje de configuración human readable. Sería es bastante amigable, intuitivo. La sintaxis se logra entender, es declarativo y ayuda en ese aspecto. Eh, permite hacer seguimiento de los cambios de infraestructura gracias al archivo de estado. Eh, sí, eso es algo importante. Estás trabajando con Terrafon. Eh, él te provee ahí promps cuando estás cultando tu comando y te dice eh cada vez que vas a hacer un cambio te quieres cambiar esto. Eh te te muestra la diferencia, quieres hacerte cambio, pero en tu nube tienes esto. Se va a crear esto, se va a editar esto y se va eh a borrar esto. Entonces, te probé esa herramienta para que tú te das seguridad sobre los cambios que vas a hacer. Tercero, el versionado. Puedes versionar ese código en GIP. Entonces, es chévere porque puedes trabajar en equipo. eh puedes eh viajar al pasado para ver un poquito otro tag de otra versión que tenía y todo eso. Y módulos, parte importante aquí porque los módulos son como para los lenguajes de programación vendrían siendo como eh, vamos a decirlo como funciones, como agrupaciones eh de cosas internas, de tareas internas que comunes que te permiten reusablas, además te permiten eh esa comunicación de entre módulos eh por medio de entradas y salidas como parámetro o como return. Yo utilicé los módulos para agrupar esos 20 recursos en diferentes grupos, balanceador de carga, política o escalamiento, networking, security y work. Y cada una de estas carpetas, el proyecto tiene definiciones de cinco, seis y todo lo demás. Bien, ahora sí, eh vamos a ver una una demostración un poquito para ver cómo se ejecutó y le voy a mostrar este el proceso de cómo se dispara una alarma y ver cómo actúa este el autoescalismo. Un momentico, quedó por ahí.
Creo que 20 eh con lo d play al no a la playa para ver cómo se ejecuta el código de terra bien la demo de fusión de terrafo el ent inicial eh AWS cero recursos, no había nada, cero instancia, cero balancer, eh no hay donde está el grupo. Ah,
vamos a ver qué pasa ahora. Este es el código del proyecto eh a la izquierda vemos el archivo mail que se está mostrando. Es como el punto de entrada, ahí donde define todas las cosas que quieres eh reusar, pues de todo tu código. Y yo estoy usando los módulos precisamente, ¿verdad? Networking, security, ALB, el cual hace match con estas carpetas organizadas aquí, estos grupos lógicos, eh, que tienen todos los recursos allí. Vamos a ver, a ver, eh, sí, bien, la aplicación. Aquí voy a ejecutar el comando. Eh, bien, lo que les mencionaba justamente de las herramientas que te da Terrafon, cuando tú vas a aplicar algún código, él hace esa comparación de los estados. Y entonces aquí me va a mostrar sugerencia o me va a decir que va a cambiar. El símbolo más es que es algo nuevo, el símbolo menos borrado, remarcado en rojo y entonces ahí ya tú este eh nota aquí aprovecho eh buena práctica. Siempre lean estas cosas porque de aquí dependen los cambios que van a a infraestructura y así se evitan de que puedan por allí meter algún cambio que sea inesperado. Adelante allí bastante porque tarda dale tr cu ahí se aplicó completo cuando actualizo ahora aquí a WS, entonces ahí se van a ver ya eh los recursos creados y vamos a ver ahorita solo hay una de forma general cómo se quedaron. Ahí van a ver el primero el advanc con sus detalles y todo eso. Después van a ver el grupo escalamiento. Aquí voy a mostrar las políticas que les mencioné. Si se dan cuenta, cuando veamos las políticas son como parte del grupo de funcionamiento, a pesar de que el terrafon nosotros lo definimos como un recurso pero aquí se refleja o lo ves aquí eh como una una subsección. Y bueno, la instancia creada. Eh, aquí vemos una instancia porque Bueno, porque cuando creé el grupo instalamiento, yo le dije, lo configuré, le dije, "Mira, como siempre cuando se cree empieza con uno, digamos, como el estado inicial de tu servicio. Eh, ¿qué número debes definir allí?" Bueno, el número que se en tu negocio o tu proceso, cuánto es más o menos la el tráfico que manejas y cuánto por cuánto debes empezar. Ahora vamos a leer aquí ahora una demostración de cómo se dispara una alarma, ¿verdad? eh relacionada al uso de CPU que tiene esta condición. Cuando el uso de CPU sea mayor al 40% no dentro de la ventana de 3 minutos, en los últimos 3 minutos. Eh, nada, ahí lo que hice eh básicamente me creé una un un script patch que hiciera constantemente eh consulta HTTP a la URL, el W balancer que se creó. Y entonces ¿Cuál es la idea o qué se espera que este gráfico primero de Cloudwatch, el cual esta línea roja es el umbral, eh empiecen a ver picos y se sobrepasa? Y cuando ocurra o cuando pase el tiempo más o menos de la ventana que se definió allí, se tiene que disparar esa alarma. Ahí adelanta bastante también porque tardé ahí hace un rato a tres cuartos. que a la derecha mejor gracias eh d un poquito para atrás. No, dale mucho más agito. Este, bueno, ahí el alarma se disparó y aquí podemos ver cuando vemos la autoescalamiento, se disparó la política a partir de eh una alarma, dice aquí una paró la política y si vemos automáticamente allí se crearon tres instancias. Entonces allí vemos el proceso de escalamiento, cómo se hace automatizado, eh controlados según parámetros que nosotros establezcamos. Eh ahora sí podemos volver a la presentación, por favor. Control al izquierda o derecha. la la presentación puede cerrar porque este es un video. Ah, sí, ahora sí o derecha. este de atletismo no veo ya me olvidado ya. Gracias. Bien, entonces ahora sí, la parte final, conclusiones. Primero, eh la alta disponibilidad en servicio Bismo, que es crucial. Eh tenemos una experiencia de hace unos días de AWS, entonces si tú tienes un negocio, tu negocio ya tiene una considerable cantidad de de cliente y todo eso, ya es tiempo de que ya tengas entre, digamos, tu mecanismo la alta disponibilidad con técnicas como esto, o incluso técnicas que ya son mucho más avanzado, incluso se puede aplicar a a cluster de cubernetes en este mismo esquema. Entonces, bueno, importante eh pruebas super importante también ahí existe una que se llaman las pruebas del caos. Justamente en el community vimos ahí un tuvimos un ponente, me acuerdo, mencionó bastante sobre esas pruebas y cómo cómo te ayudan a predecir los comportamientos cuando hay una caída. Entonces, es una buena práctica también, me parece. Eh, estos proveedores de cloud como WBS ya tienen esos recursos y entonces ustedes tienen que agarrar aquí, usarlo, conectarlo y probarlo y ver si está todo bien y ahí ya tienen su implementación. Eh, y bueno, herramientas de IAC es vital para cuando tienes que manejar, no sé, más de 10 recursos, más de 20 ya te ayuda muchísimo para este tipo de trabajo. Entonces, bueno, eso sería todo. Espero que les haya gustado y muchas gracias.
Bueno, César, muchísimas gracias. Antes de concluir tu charla, ¿alguien ¿Alguna pregunta? Eh,
sí, ya dime, dime.
No, la pregunta era este, fijaste ahí que se autogeneraban nuevas instancias en base al tráfico y y en caso de ser tráfico malicioso, ¿cómo lo detectarías? Este, ¿hay algún paso previo para detectar eso y que no te no te genere distancia en Mm. A ver, a ver, pensemos un poquito. Puede ser.
Sí, pienso que sí. E el tema es este,
¿cómo utilizas esos recursos de WS que ya te dan el tema de las alarmas con CloudW? Y ellos tienen allí, si no me equivoco, manejan los relogs. Entonces, por ahí puedes de repente eh trackar algún tipo de logs y basado en eso, hacer como una una alarma costiertos patrones. pone malicioso.
Sería algo que nosotros tenemos que configurar o es de parte. Sí, sí, porque este que yo usé son ya como que unos predefinidos que ellos tienen y ya te trae la condición. Tú lo que le dices es cuánto es el umbral, con cuánto empieza, pero tiene también para hacer algo más costo.
Eh, tiene esa opción siempre libre para que oye, por si acaso tienes que hacer una condición de una fórmula bien compleja para escalar.
Eh, me imagino que también debe tener algún mecanismo para leer loss porque el logs de cloudwatch, como vimos, un sistema monitoreo y si están los blogs puedes por ahí leerlos con algún patrón y de repente un patrón de no sé de cualquier tipo de cuestión de acceso o algo por ahí funciona. Entonces yo creo que sí te aconsejo que investigue lo voy a revisar y por ahí lo publico en el grupo también. Está interesante la pregunta.
Dale, gracias.
¿Alguien más tiene otra pregunta?
Continuando conmigo, digamos, se podrían integrar así. watch con algún otro servicio de monitoreamiento, cosa de que si sospechamos de que se pudiese tratar de algún ataque o un intento de of service, el poder ir y apagar manualmente las distancias o de alguna manera bloquear o limitar ese intento de no de mm pienso que sí porque eh este tema de las alarmas eh tú defines las alarmas cómo va la entrada de las condiciones y de forma genérica AWS lo dibuja como que eh condiciones y acciones. Seguramente ese bloque de acciones eh más allá de simplemente escalar, de repente por allí también puede hacer algo tipo más custom de que genera una señal a algún otro servicio para que haga algo. Por ahí de repente lo puedes trabajar. Entonces sería revisar un poco ese esa parte de las acciones de las alarmas y a ver cómo pudiésemos integrar con algún una acción que corresponda a lo que tú necesites. Okay, gracias.
¿Alguien más tiene alguna pregunta? Sería la última. Eh, ¿qué puedo preguntar? Claro. ¿Por qué Terrafor y no el servicio que tiene AWS para y y hacer?
Eh, es el que tengo experiencia, es con el que he trabajado. Eh, sí, básicamente. sería eso, pero sí he visto pues que tiene ese de ellos es el cloud, ¿cómo que se llama?
Cloud formation.
Cloud formation,
no es válido. Si tienen experiencia en uno y y les le funciona igual, está bueno.
Claro, la única diferencia ahí es eh cloud formation, creo que solo para WS, ¿no?
Solo para WS
en el ter ahí puedes usar varios proveedores, teoría,
pero es el mismo el mismo formato.
El mismo recurso no lo puedes provisionar.
Ah, el mismo recurso no tiene que como hacer una mímica.
Hacer una mímica.
Ah, buen punto. Interesante. Sí, pero bueno, sí, básicamente fue eso. Ya, ya justamente trabajé con Ter con y vamos a probar con la W que Ahí va.
Okay. Eh, bueno, César, muchísimas gracias. Y a lo que se prepara Carlos, yo tengo alguna pregunta y bueno, por $25 en AWS, ¿alguien me puede decir dos storage classes de S3? Como por ejemplo Intelligent theory. S3 estándar y S3 Glacier.
S3, ¿qué?
Glacier.
Estándar.
No, no es de es otro producto. Está cerca. Está cerca. Está cerca.
Ah, es otro producto.
Ya, pero dos este tres estándar es uno. Otro más
el E es el ejemplo. Ah,
okay. Y porito ya se habá ya se irán dando cuenta que las preguntas deito son un poco más difíciles. En la presentación de César, él habló de estrategias de alta disponibilidad. ¿Alguien me podría decir cuáles fueron las tres estrategias que él puso en su diapositiva? Dale. para hacer de carga de replicación. Copia alguien que le gana
ganaron.
Okay. Bueno, ya