Informática en la nube explicada: los 11 conceptos de arquitectura que debes conocer (Clase magistral 4K).

Qué cubre este vídeo

• - El Muro de la Arquitectura y el Plan Maestro
• - 01. Escalado vertical vs. horizontal
• - 02. Arquitectura de equilibrio de carga (L4 vs. L7 y comprobaciones de estado)
• - 03. Autoescalado y elasticidad
• - 04. Sin servidor (FaaS y MicroVM de Firecracker)

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

- El Muro de la Arquitectura y el Plan Maestro

0:00 Todo ingeniero de software se enfrenta finalmente al muro de la arquitectura en la nube. Construyes una aplicación en tu portátil, la subes a producción, y en el momento en que llegan usuarios reales, los servidores se caen, las conexiones a la base de datos se agotan y tu factura de AWS parece un número de teléfono. La mayoría de los desarrolladores intentan resolver la ingeniería en la nube memorizando trescientos acrónimos diferentes de productos de AWS. Pero la computación en la nube real no se trata de memorizar catálogos de proveedores: se basa en once primitivas arquitectónicas fundamentales.

0:34 En esta clase magistral, recorreremos todo el plan empresarial: desde escalado y equilibrio de carga hasta sin servidor, desacoplamiento basado en eventos, jerarquías de almacenamiento y redes en la nube. Domina estos once conceptos y podrás diseñar cualquier backend en AWS, GCP o Azure. Esto es The Daily Diff, bajo el capó.

- 01. Escalado vertical vs. horizontal

0:57 Concepto número uno: Escalado. Cuando tu aplicación experimenta un crecimiento del tráfico, tienes dos formas fundamentalmente diferentes de manejar la carga: escalado vertical o escalado horizontal. El escalado vertical, o escalar, significa tomar tu máquina existente y agregar más recursos: actualizar de cuatro núcleos de CPU a treinta y dos, o cambiar treinta y dos gigabytes de RAM por ciento veintiocho. El escalado vertical no requiere cambios arquitectónicos: tu código

1:28 y base de datos permanecen exactamente igual. Pero llega a un techo de hardware brutal. Ninguna máquina en el mundo tiene diez mil núcleos de CPU, y las instancias de primer nivel tienen un precio exponencialmente superior. El escalado horizontal, o escalar, significa mantener tus servidores pequeños y con precios de productos básicos, pero ejecutar múltiples instancias en paralelo detrás de un enrutador. Si una instancia falla, los nodos restantes absorben el tráfico con cero tiempo de inactividad. La regla de oro del escalado horizontal es la

2:01 ausencia de estado: los servidores de tu aplicación no pueden almacenar sesiones de usuario, archivos cargados o estado en sus discos locales. El estado debe residir en una base de datos o caché externa, permitiendo que cualquier nodo maneje cualquier solicitud de usuario.

- 02. Arquitectura de equilibrio de carga (L4 vs. L7 y comprobaciones de estado)

2:17 Concepto número dos: Equilibrio de carga. El escalado horizontal suena genial en el papel, pero introduce un problema inmediato: cuando diez mil usuarios acceden a tu nombre de dominio, ¿qué servidor específico recibe su tráfico? Un equilibrador de carga actúa como un proxy inverso que se interpone entre Internet público y tu clúster de backend privado. Acepta conexiones TCP o HTTP entrantes y distribuye las solicitudes entre tus instancias saludables.

2:47 Los equilibradores de carga operan en dos capas de red principales. Los equilibradores de carga de red de la Capa 4 operan en la capa de transporte, enrutando paquetes TCP y UDP sin procesar basados en la dirección IP y el puerto con latencia de microsegundos y millones de solicitudes por segundo. Los equilibradores de carga de aplicaciones de la Capa 7 inspeccionan el protocolo HTTP en sí: leyendo rutas de URL, encabezados de solicitud, cookies y métodos HTTP. Esto permite el enrutamiento basado en rutas: enviar solicitudes slash-api a tu clúster de backend y solicitudes slash-static a un

3:25 almacén de objetos. Crucialmente, los equilibradores de carga realizan comprobaciones de estado activas. Cada pocos segundos, el equilibrador hace ping a un punto final de estado en cada instancia. Si una instancia arroja tres errores quinientos consecutivos o no responde, se expulsa automáticamente del grupo con cero solicitudes perdidas.

- 03. Autoescalado y elasticidad

3:45 Concepto número tres: Autoescalado. Si tu aplicación web necesita dos servidores a las tres de la mañana, pero veinte servidores durante un lanzamiento a mediodía, hacer clic manualmente en los botones de la consola en la nube es un camino garantizado hacia el tiempo de inactividad y la quiebra. El autoescalado aporta elasticidad dinámica a los grupos de servidores horizontales. Un Grupo de Autoescalado monitorea métricas de rendimiento como la utilización promedio de la CPU, E/S de red o la profundidad de la cola de espera. Cuando la CPU promedio cruza un umbral definido —digamos,

4:19 setenta por ciento durante tres minutos consecutivos— el autoescalador automáticamente lanza nuevas máquinas virtuales, las registra con tu equilibrador de carga y comienza a enrutar el tráfico. Igualmente importante es el escalado de entrada: cuando la ola de tráfico retrocede, el autoescalador termina las instancias excedentes para que dejes de pagar por la computación inactiva. Para evitar el aleteo —donde los servidores se crean y destruyen rápidamente en un bucle interminable— los arquitectos de la nube configuran períodos de enfriamiento. Concepto número cuatro: Sin servidor.

- 04. Sin servidor (FaaS y MicroVM de Firecracker)

4:53 Durante años, los equipos de marketing promocionaron lo sin servidor como código mágico ejecutándose en el cielo. En realidad, lo sin servidor sigue utilizando servidores, pero no los posees, parcheas o pagas por ellos cuando no se está ejecutando ningún código. Con Function-as-a-Service como AWS Lambda o Google Cloud Functions, escribes una función de controlador independiente. Cuando ocurre una solicitud HTTP, una carga de archivo S3 o un cambio en la base de datos, el entorno de ejecución en la nube arranca una máquina virtual

5:23 micro-virtual efímera como Firecracker en menos de cinco milisegundos. Tu código se ejecuta, devuelve una respuesta y se apaga. Si nadie visita tu sitio web durante tres meses, tu factura de computación es exactamente cero dólares y cero centavos. Si un millón de usuarios lo visitan simultáneamente, el proveedor activa un millón de microVM concurrentes. Las compensaciones de ingeniería son reales: latencia de inicio en frío al iniciar nuevos entornos de ejecución, un límite de ejecución estricto de quince minutos en Lambda y una estricta ausencia de estado.

5:55 Lo sin servidor es imbatible para pipelines de eventos y API esporádicas, pero deficiente para WebSockets persistentes o ejecuciones de entrenamiento de varias horas.

- 05. Arquitectura basada en eventos (EDA y desacoplamiento)

6:05 Concepto número cinco: Arquitectura basada en eventos, o EDA. En las arquitecturas tradicionales, los servicios se comunican de forma síncrona. Tu servicio de pago llama a pago, pago llama a inventario, inventario llama a fraude y fraude llama a correo electrónico. Esto crea la cascada sincrónica de la perdición. Si el proveedor de correo electrónico de terceros experimenta un problema de red y tarda diez segundos en responder, la solicitud de pago completa de tu cliente agota el tiempo de espera con un error. En una arquitectura basada en eventos, los servicios están completamente desacoplados.

6:37 Cuando un cliente hace clic en comprar, el servicio de pago no llama a los servicios descendentes. Simplemente publica un evento llamado OrderPlaced en un Bus de eventos central como Amazon EventBridge o un tema de SNS. El pago se completa en cincuenta milisegundos. Los trabajadores descendentes para el pago, la deducción de inventario y los recibos de correo electrónico extraen mensajes de forma independiente de sus propias colas SQS dedicadas. Si el servicio de correo electrónico se cae durante una hora, los mensajes esperan de forma segura almacenados en la cola sin una sola orden perdida.

- 06. Orquestación de contenedores (Docker y Kubernetes)

7:13 Concepto número seis: Orquestación de contenedores. Docker resolvió el empaquetado: envuelve el código de tu aplicación, bibliotecas del sistema, configuración y tiempo de ejecución en una imagen inmutable que se ejecuta idénticamente en tu MacBook y en la nube. Pero empaquetar un contenedor es fácil. Ejecutar quinientos contenedores en cincuenta máquinas virtuales físicas es donde la ingeniería falla. Por eso existen orquestadores de contenedores como Kubernetes y AWS ECS.

7:41 Un orquestador proporciona un plano de control: un servidor de API, un almacén de estado etcd y un programador inteligente. Declaras tu estado deseado: Quiero diez réplicas de mi servicio de autenticación con dos gigabytes de RAM cada una. El programador inspecciona el clúster, coloca los pods en nodos con memoria libre, configura las redes internas y concilia continuamente la realidad. Si un nodo sufre un fallo de hardware, Kubernetes detecta la pérdida y reprograma instantáneamente todos los pods desplazados en

- 07. Los 4 pilares de almacenamiento en la nube (S3, EBS, bases de datos y Redis)

8:16 nodos saludables. Concepto número siete: La jerarquía de almacenamiento en la nube. Los principiantes a menudo tratan el almacenamiento en la nube como un único cubo donde se vierten archivos. En la arquitectura de producción, el almacenamiento se divide en cuatro pilares distintos según los patrones de acceso y la latencia. El primero es el Almacenamiento de objetos, como Amazon S3 o Google Cloud Storage. Se accede a los archivos a través de las API REST de HTTP utilizando llamadas PUT y GET simples. Ofrece capacidad horizontal infinita a dos centavos por gigabyte por mes,

8:49 lo que lo hace ideal para video, cargas de usuarios, registros y copias de seguridad. El segundo es el Almacenamiento en bloques, como Amazon EBS. Estos son discos duros virtuales montados directamente en una máquina virtual específica a través de interconexiones de alta velocidad. Se formatean en sistemas de archivos estándar como ext4, lo que permite un acceso rápido de lectura y escritura aleatoria requerido por los motores de bases de datos. El tercero son las Bases de datos administradas: motores relacionales como PostgreSQL en RDS que proporcionan transacciones ACID y uniones complejas,

9:21 y motores NoSQL como DynamoDB que ofrecen latencia de un solo dígito en milisegundos a gran escala. Y el cuarto son las Cachés en memoria como Redis. La lectura de datos de la RAM tarda microsegundos en lugar de milisegundos. Las cachés se sitúan delante de tu base de datos, protegiéndola del tráfico de lectura repetido y gestionando tokens de sesión de usuario volátiles.

- 08. Alta disponibilidad y los Nueves (conmutación por error multizona)

9:44 Concepto número ocho: Alta disponibilidad, o HA. La disponibilidad responde a una pregunta: ¿qué porcentaje del tiempo está tu aplicación operativa y accesible para los usuarios? En los contratos empresariales, la disponibilidad se mide en nueves. Dos nueves, o el noventa y nueve por ciento de disponibilidad, permite más de tres días y medio de tiempo de inactividad cada año. Cuatro nueves reduce el tiempo de inactividad permitido a cincuenta y dos minutos, y cinco nueves permite apenas cinco minutos de tiempo de inactividad total por

10:15 año. Para lograr alta disponibilidad, debes eliminar puntos únicos de falla en todos los dominios de falla. En la nube, eso significa implementar en múltiples Zonas de Disponibilidad. Una Zona de Disponibilidad no es un solo rack: es uno o más centros de datos físicos distintos a kilómetros de distancia con energía y refrigeración independientes. Al ejecutar instancias activas en la Zona A y la Zona B con replicación de bases de datos síncrona, un rayo o un corte de fibra que derriba toda una instalación física resulta en una conmutación por error automatizada.

10:50 en treinta segundos con cero intervención humana.

- 09. Durabilidad vs. disponibilidad (por qué 11 nueves no es tiempo de actividad)

10:53 Concepto número nueve: Durabilidad versus Disponibilidad. Esta es la trampa conceptual más común en las entrevistas de arquitectura en la nube. Los ingenieros frecuentemente usan las palabras indistintamente, pero miden propiedades completamente diferentes. La Disponibilidad mide el tiempo de actividad: ¿puedo hacer una llamada API para leer o escribir mis datos justo en este segundo? datos justo en este segundo? La Durabilidad mide la preservación: ¿mis datos sobrevivirán sin pérdida de bits, corrupción o destrucción permanente durante diez años? pérdida de bits, corrupción o destrucción durante diez años?

11:24 Mira Amazon S3 Standard. Su Acuerdo de Nivel de Servicio ofrece un noventa y nueve coma nueve por ciento de disponibilidad, lo que permite aproximadamente cuarenta y tres minutos de inactividad cada mes donde una solicitud API podría devolver un error de quinientos. Pero S3 promete once nueves de durabilidad: noventa y nueve coma nueve nueve nueve nueve nueve nueve nueve nueve nueve por ciento. Si almacenas diez millones de archivos en S3, puedes esperar estadísticamente perder un

11:56 promedio de un archivo cada diez mil años. S3 logra esto codificando por borrado objetos y replicando fragmentos a través de al menos tres instalaciones de datos geográficamente separadas. menos tres instalaciones de datos geográficamente separadas. Durante una interrupción importante de la red regional, S3 podría estar temporalmente no disponible, pero tus datos nunca se destruyen.

- 10. Infraestructura como código (Terraform vs. Console Drift)

12:14 Concepto número diez: Infraestructura como Código, o IaC. En los primeros días de la computación en la nube, los ingenieros iniciaban sesión en la consola de gestión web de AWS y hacían clic manualmente para crear máquinas virtuales, configurar subredes y adjuntar grupos de seguridad. La industria llama a esto ClickOps, y en producción, es un desastre absoluto. Los cambios manuales en la consola no tienen un registro de auditoría, ningún mecanismo de reversión, e inevitablemente causan una desviación de la configuración entre los entornos de staging y producción. Con herramientas de Infraestructura como Código como Terraform,

12:48 como Código como Terraform, OpenTofu, Pulumi o AWS CDK, defines tu arquitectura de nube completa en archivos de configuración declarativos almacenados en Git. Cada cambio en un puerto abierto o réplica de base de datos pasa por una solicitud de extracción y revisión por pares. La ejecución de terraform plan previsualiza la diferencia exacta de la API antes de que se toque nada, y levantar una réplica idéntica de tu pila de producción lleva cuatro minutos en lugar de cuatro semanas.

- 11. Redes en la nube (VPC, subredes, NAT y grupos de seguridad)

13:20 Concepto número once: Redes en la Nube y Nubes Privadas Virtuales. Cuando implementas servidores en la nube, no están expuestos directamente en la Internet pública. Viven dentro de un límite aislado definido por software llamado VPC. Dentro de tu VPC, asignas un espacio de direcciones IP privadas como diez punto cero punto cero punto cero barra dieciséis, y lo divides en subredes públicas y privadas. Una subred pública tiene una ruta directa a un Internet Gateway.

13:51 Contiene activos orientados al público como tus balanceadores de carga de aplicaciones y puertas de enlace NAT. Es la única parte de tu red que posee direcciones IP públicas. Tus servidores de aplicaciones y bases de datos de producción viven estrictamente en subredes privadas sin IPs públicas y cero rutas de entrada desde Internet. Cuando tus servidores de backend necesitan descargar actualizaciones de seguridad, su tráfico saliente se enruta a través del NAT Gateway en la subred pública. Rodeando cada instancia hay Grupos de Seguridad: firewalls virtuales con estado que aplican el principio de mínimo privilegio.

- 12. El plan empresarial completo y veredicto

14:28 Tu grupo de seguridad de base de datos solo acepta conexiones en el puerto 5432 estrictamente desde el grupo de seguridad de tus servidores de aplicaciones, haciendo matemáticamente imposible la penetración externa. Cuando haces zoom hacia afuera, estos once primitivos se conectan en un sistema cohesivo. Tu DNS se enruta a un Balanceador de Carga en una subred pública, los grupos de autoescalado gestionan los picos de tráfico en múltiples Zonas de Disponibilidad, los buses de eventos desacoplan los trabajadores de backend, y toda tu pila se despliega desde Git usando Infraestructura como Código.

15:02 El veredicto de la clase magistral de hoy: SHIP IT. Deja de memorizar cientos de acrónimos de marketing en la nube. Domina estos once patrones de arquitectura, desacopla tu estado, y construye sistemas que no pueden fallar. Dime qué concepto de la nube te dio el mayor dolor de cabeza cuando empezaste a construir en los comentarios. Y para obtener la hoja de trucos de arquitectura completa, suscríbete al boletín en the daily diff dot dev,

15:28 enlace abajo. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusiona responsablemente.

Fuentes

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io