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

Lo que cubre este video

• - La Pared de Arquitectura y el Plan Maestro
• - 01. Escalado Vertical vs. Horizontal
• - 02. Arquitectura de Balanceo de Carga (L4 vs. L7 y Verificaciones de Salud)
• - 03. Autoescalado y Elasticidad
• - 04. Sin Servidor (FaaS y MicroVMs Firecracker)

Transcripción traducida

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

- La Pared de Arquitectura y el Plan Maestro

0:00 Todo ingeniero de software eventualmente se enfrenta a la pared de la arquitectura en la nube. Usted construye una aplicación en su laptop, la lanza a producción, y en el momento en que llegan usuarios reales, los servidores se caen, las conexiones de la base de datos se agotan, y su 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 construye sobre once primitivas arquitectónicas fundamentales.

0:34 En esta clase magistral, recorreremos el plan empresarial completo: desde el escalado y balanceo de carga hasta el desacoplamiento sin servidor y dirigido por eventos, jerarquías de almacenamiento y redes en la nube. Domine estos once conceptos, y podrá 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 su aplicación experimenta un aumento de tráfico, tiene dos maneras fundamentalmente diferentes de manejar la carga: escalado vertical o escalado horizontal. El escalado vertical, o escalar hacia arriba, significa tomar su 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: su código

1:28 y base de datos permanecen exactamente iguales. Pero alcanza un brutal límite de hardware. Ninguna máquina en el mundo tiene diez mil núcleos de CPU, y las instancias de primer nivel tienen una prima de precio exponencial. El escalado horizontal, o escalar hacia afuera, significa mantener sus servidores pequeños y con precios de productos básicos, pero ejecutando múltiples instancias en paralelo detrás de un enrutador. Si una instancia se cae, 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: sus servidores de aplicaciones no pueden almacenar sesiones de usuario, archivos subidos 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 Balanceo de Carga (L4 vs. L7 y Verificaciones de Salud)

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

2:47 Los balanceadores de carga operan en dos capas de red principales. Los balanceadores de carga de red de 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 balanceadores de carga de aplicaciones de 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 su clúster de backend y solicitudes slash-static a un

3:25 almacén de objetos. Crucialmente, los balanceadores de carga realizan verificaciones de salud activas. Cada pocos segundos, el balanceador hace ping a un punto final de salud 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 su aplicación web necesita dos servidores a las tres de la mañana, pero veinte servidores durante un lanzamiento al mediodía, hacer clic manualmente en los botones de la consola de la nube es un camino garantizado hacia el tiempo de inactividad y la bancarrota. 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 pendientes. Cuando la CPU promedio supera un umbral definido — por ejemplo,

4:19 el setenta por ciento durante tres minutos consecutivos — el autoescalador automáticamente lanza nuevas máquinas virtuales, las registra con su balanceador 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 deje de pagar por el cálculo inactivo. Para evitar el "flapping" — donde los servidores se crean y destruyen rápidamente en un ciclo de "thrashing" sin fin — los arquitectos de la nube configuran períodos de enfriamiento. Concepto número cuatro: Sin Servidor.

- 04. Sin Servidor (FaaS y MicroVMs Firecracker)

4:53 Durante años, los equipos de marketing promocionaron el "serverless" como código mágico ejecutándose en el cielo. En realidad, "serverless" sigue utilizando servidores, pero usted no los posee, los parchea ni paga por ellos cuando no se ejecuta ningún código. Con Function-as-a-Service como AWS Lambda o Google Cloud Functions, usted escribe una función controladora 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 micro-máquina virtual

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

5:55 Serverless es inmejorable para pipelines de eventos y APIs esporádicas, pero deficiente para WebSockets persistentes o ejecuciones de entrenamiento de varias horas.

- 05. Arquitectura Orientada a Eventos (EDA y Desacoplamiento)

6:05 Concepto número cinco: Arquitectura Orientada a Eventos, o EDA. En las arquitecturas tradicionales, los servicios se comunican sincrónicamente. Su servicio de pago llama a inventario, inventario llama a fraude, 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, toda la solicitud de pago de su cliente expira con un error. En una arquitectura orientada a 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 independientemente de sus propias colas SQS dedicadas. Si el servicio de correo electrónico falla durante una hora, los mensajes esperan de forma segura almacenados en búfer 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 su aplicación, bibliotecas del sistema, configuración y entorno de ejecución en una imagen inmutable que se ejecuta de manera idéntica en su 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 se descompone. Por eso existen orquestadores de contenedores como Kubernetes y AWS ECS.

7:41 Un orquestador proporciona un plano de control: un servidor API, un almacén de estado etcd y un programador inteligente. Usted declara su 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 reconcilia continuamente la realidad. Si un nodo sufre un fallo de hardware, Kubernetes detecta la pérdida e instantáneamente reasigna todos los pods desplazados a

- 07. Los 4 Pilares del Almacenamiento en la Nube (S3, EBS, DBs 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 basados en patrones de acceso y latencia. Primero está el Almacenamiento de Objetos, como Amazon S3 o Google Cloud Storage. Usted accede a los archivos a través de APIs REST HTTP usando llamadas PUT y GET simples. Ofrece capacidad horizontal infinita a dos centavos por gigabyte al mes,

8:49 lo que lo hace ideal para video, cargas de usuarios, registros y copias de seguridad. Segundo está 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 admite un acceso rápido de lectura y escritura aleatoria requerido por los motores de bases de datos. Tercero son las Bases de Datos Gestionadas: motores relacionales como PostgreSQL en RDS que proporcionan transacciones ACID y uniones complejas,

9:21 y motores NoSQL como DynamoDB que ofrecen latencia de milisegundos de un solo dígito a gran escala. Y cuarto son los Cachés en Memoria como Redis. Leer datos de la RAM toma microsegundos en lugar de milisegundos. Los cachés se sitúan delante de su 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 Multi-AZ)

9:44 Concepto número ocho: Alta Disponibilidad, o HA. La disponibilidad responde a una pregunta: ¿qué porcentaje del tiempo su aplicación está operativa y accesible para los usuarios? En los contratos empresariales, la disponibilidad se mide en nueves. Dos nueves, o 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, debe eliminar los puntos únicos de falla en todos los dominios de falla. En la nube, eso significa desplegar 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 millas de distancia con energía y refrigeración independientes. Al ejecutar instancias activas en la Zona A y la Zona B con replicación síncrona de la base de datos, un rayo o un corte de fibra que derribe 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 ahora mismo? La Durabilidad mide la preservación: ¿mis datos sobrevivirán sin pérdida permanente de bits, corrupción o destrucción durante diez años?

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

11:56 promedio de un archivo cada diez mil años. S3 logra esto mediante la codificación de borrado de objetos y la replicación de fragmentos a través de al 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 sus datos nunca se destruyen.

- 10. Infraestructura como Código (Terraform vs. Desviación de Consola)

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 administración web de AWS y hacían clics 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 absoluto desastre. Los cambios manuales en la consola no tienen un rastro de auditoría, ningún mecanismo de reversión e inevitablemente causan una desviación de la configuración entre los entornos de preparación y producción. Con herramientas de Infraestructura como Código

12:48 como Terraform, OpenTofu, Pulumi o AWS CDK, usted define toda su arquitectura en la nube en archivos de configuración declarativos almacenados en Git. Cada cambio a un puerto abierto o réplica de base de datos pasa por una solicitud de extracción y revisión por pares. Ejecutar terraform plan previsualiza la diferencia exacta de la API antes de que se toque algo, y levantar una réplica idéntica de su pila de producción toma cuatro minutos en lugar de cuatro semanas. Concepto número once: Redes en la Nube y Nubes Privadas Virtuales.

- 11. Redes en la Nube (VPC, Subredes, NAT y Grupos de Seguridad)

13:20 Cuando implementa servidores en la nube, no están expuestos en la internet pública en bruto. Viven dentro de un límite aislado definido por software llamado VPC. Dentro de su VPC, asigna un espacio de direcciones IP privadas como diez punto cero punto cero punto cero barra dieciséis, y lo divide en subredes públicas y privadas. Una subred pública tiene una ruta directa a un Gateway de Internet. Contiene activos de cara al público como sus Application Load Balancers y NAT

13:51 Gateways. Es la única parte de su red que posee direcciones IP públicas. Sus servidores de aplicaciones y bases de datos de producción viven estrictamente en subredes privadas sin IPs públicas y cero rutas entrantes desde internet. Cuando sus servidores 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 hacen cumplir el principio de mínimo privilegio. Su grupo de seguridad de base de datos solo acepta conexiones en el puerto

- 12. El Plan Empresarial Completo y Veredicto

14:28 5432 estrictamente desde el grupo de seguridad de sus servidores de aplicaciones, haciendo matemáticamente imposible la penetración externa. Cuando se aleja, estos once primitivos se conectan en un sistema cohesivo. Su DNS se enruta a un Balanceador de Carga en una subred pública, los grupos de autoescalado manejan los aumentos de tráfico a través de múltiples Zonas de Disponibilidad, los buses de eventos desacoplan los trabajadores de backend, y toda su pila se implementa desde Git usando Infraestructura como Código. Veredicto de la clase magistral de hoy: SHIP IT.

15:02 Deje de memorizar cientos de acrónimos de marketing de la nube. Domine estos once patrones de arquitectura, desacople su estado, y construya sistemas que no puedan fallar. Dígame qué concepto de la nube le dio el mayor dolor de cabeza cuando empezó a construir en los comentarios. Y para obtener la hoja de trucos completa de arquitectura, suscríbase al boletín en the daily diff dot dev, enlace abajo. Y esa es la diferencia de hoy.

15:28 Soy Niko de Axrisi. Fusione responsablemente. Fusione 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