Informática na nube explicada: os 11 conceptos de arquitectura que debes coñecer (Masterclass 4K).

Que abrangue este vídeo

• - O Muro da Arquitectura e o Plano Mestre
• - 01. Escalado Vertical vs. Horizontal
• - 02. Arquitectura de Balanceo de Carga (L4 vs. L7 e Comprobacións de Saúde)
• - 03. Autoescalado e Elasticidade
• - 04. Sen Servidor (FaaS e MicroVMs Firecracker)

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

- O Muro da Arquitectura e o Plano Mestre

0:00 Todo enxeñeiro de software acaba enfrontándose ao muro da arquitectura na nube. Constrúes unha aplicación no teu portátil, a levas a produción, e no momento en que chegan usuarios reais, os servidores caen, as conexións á base de datos esgótanse e a túa factura de AWS parece un número de teléfono. A maioría dos desenvolvedores intentan resolver a enxeñería na nube memorizando trescentos acrónimos de produtos de AWS diferentes. Pero a informática na nube real non consiste en memorizar catálogos de provedores: está construída sobre once primitivas arquitectónicas fundamentais.

0:34 Nesta masterclass, percorreremos todo o plano empresarial: desde o escalado e o balanceo de carga ata o servidor sen servidor, o desacoplamento dirixido por eventos, as xerarquías de almacenamento e a rede na nube. Domina estes once conceptos e poderás deseñar calquera backend en AWS, GCP ou Azure. Isto é The Daily Diff, entre bastidores.

- 01. Escalado Vertical vs. Horizontal

0:57 Concepto número un: Escalado. Cando a túa aplicación experimenta un crecemento de tráfico, tes dúas formas fundamentalmente diferentes de xestionar a carga: escalado vertical ou escalado horizontal. O escalado vertical, ou "scale up", significa tomar a túa máquina existente e engadir máis recursos: actualizar de catro núcleos de CPU a trinta e dous, ou cambiar trinta e dous gigabytes de RAM por cento e vinte e oito. O escalado vertical non require cambios arquitectónicos: o teu código

1:28 e a base de datos permanecen exactamente igual. Pero alcanza un brutal teito de hardware. Ningunha máquina no mundo ten dez mil núcleos de CPU, e as instancias de primeira liña teñen un prezo exponencialmente máis alto. O escalado horizontal, ou "scale out", significa manter os teus servidores pequenos e con prezos de "commodity", pero executar varias instancias en paralelo detrás dun router. Se unha instancia cae, os nodos restantes absorben o tráfico con cero tempo de inactividade. A regra de ouro do escalado horizontal é

2:01 a "statelessness": os teus servidores de aplicacións non poden almacenar sesións de usuario, ficheiros cargados ou estado nos seus discos locais. O estado debe residir nunha base de datos externa ou caché, permitindo que calquera nodo xestione calquera solicitude de usuario.

- 02. Arquitectura de Balanceo de Carga (L4 vs. L7 e Comprobacións de Saúde)

2:17 Concepto número dous: Balanceo de Carga. O escalado horizontal soa xenial no papel, pero introduce un problema inmediato: cando dez mil usuarios acceden ao teu nome de dominio, que servidor específico recibe o seu tráfico? Un balanceador de carga actúa como un proxy inverso situado entre a internet pública e o teu clúster de backend privado. Acepta conexións TCP ou HTTP entrantes e distribúe as solicitudes entre as túas instancias en bo estado.

2:47 Os balanceadores de carga operan en dúas capas de rede principais. Os balanceadores de carga de rede da Capa 4 operan na capa de transporte, encaminando paquetes TCP e UDP brutos baseados no enderezo IP e o porto con latencia de microsegundos e millóns de solicitudes por segundo. Os balanceadores de carga de aplicacións da Capa 7 inspeccionan o propio protocolo HTTP: lendo rutas URL, cabeceiras de solicitude, cookies e métodos HTTP. Isto permite o enrutamento baseado en rutas: enviar solicitudes "slash-api" ao teu clúster de backend e solicitudes "slash-static" a un

3:25 almacén de obxectos. Fundamentalmente, os balanceadores de carga realizan comprobacións de saúde activas. Cada poucos segundos, o balanceador fai "ping" a un punto final de saúde en cada instancia. Se unha instancia lanza tres erros "quinhentos" consecutivos ou non responde, é expulsada automaticamente do grupo con cero solicitudes perdidas.

- 03. Autoescalado e Elasticidade

3:45 Concepto número tres: Autoescalado. Se a túa aplicación web necesita dous servidores ás tres da mañá, pero vinte servidores durante un lanzamento ao mediodía, facer clic manualmente nos botóns da consola na nube é un camiño garantido cara á inactividade e a bancarrota. O autoescalado aporta elasticidade dinámica aos grupos de servidores horizontais. Un Grupo de Autoescalado monitoriza métricas de rendemento como a utilización media da CPU, a E/S da rede ou a profundidade da cola de pendentes. Cando a CPU media supera un limiar definido —digamos,

4:19 o setenta por cento durante tres minutos consecutivos— o autoescalador lanza automaticamente novas máquinas virtuais, rexístraas co teu balanceador de carga, e comeza a enrutar o tráfico. Igualmente importante é o "scaling in": cando a onda de tráfico diminúe, o autoescalador termina as instancias sobrantes para que deixes de pagar por computación ociosa. Para evitar o "flapping" —onde os servidores se crean e se destrúen rapidamente nun ciclo interminable de "thrashing"— os arquitectos da nube configuran períodos de arrefriamento. Concepto número catro: Sen Servidor.

- 04. Sen Servidor (FaaS e MicroVMs Firecracker)

4:53 Durante anos, os equipos de marketing venderon o "sen servidor" como código máxico executándose no ceo. En realidade, o "sen servidor" aínda usa servidores — pero non os posúes, non os parcheas nin os pagas cando non se está executando ningún código. Con Función-como-Servizo como AWS Lambda ou Google Cloud Functions, escribes unha función "handler" autónoma. Cando se produce unha solicitude HTTP, unha carga de ficheiro S3 ou un cambio na base de datos, o tempo de execución da nube arranca unha micro-máquina-virtual

5:23 efímera como Firecracker en menos de cinco milisegundos. O teu código execútase, devolve unha resposta e apágase. Se ninguén visita o teu sitio web durante tres meses, a túa factura de computación é exactamente cero dólares e cero céntimos. Se un millón de usuarios o visitan simultaneamente, o provedor activa un millón de microVMs concurrentes. As compensacións de enxeñería son reais: latencia de inicio en frío ao iniciar "runtimes" novos, un límite de execución estrito de quince minutos en Lambda e estrita "statelessness".

5:55 O "sen servidor" é inmellorable para "pipelines" de eventos e APIs esporádicas, pero deficiente para WebSockets persistentes ou execucións de adestramento de varias horas.

- 05. Arquitectura Dirixida por Eventos (EDA e Desacoplamento)

6:05 Concepto número cinco: Arquitectura Dirixida por Eventos, ou EDA. Nas arquitecturas tradicionais, os servizos comunícanse de forma síncrona. O teu servizo de "checkout" chama a pagamento, pagamento chama a inventario, inventario chama a fraude e fraude chama a correo electrónico. Isto crea a cascada síncrona da perdición. Se o provedor de correo electrónico de terceiros experimenta un contratempo na rede e tarda dez segundos en responder, toda a solicitude de "checkout" do teu cliente esgótase con un erro. Nunha arquitectura dirixida por eventos, os servizos están completamente desacoplados.

6:37 Cando un cliente fai clic en comprar, o servizo de "checkout" non chama a servizos subseguintes. Simplemente publica un evento chamado "PedidoRealizado" nun Bus de Eventos central como Amazon EventBridge ou un tema SNS. O "checkout" complétase en cincuenta milisegundos. Os traballadores subseguintes para o pagamento, a dedución de inventario e os recibos de correo electrónico extraen mensaxes de forma independente das súas propias colas SQS dedicadas. Se o servizo de correo electrónico cae durante unha hora, as mensaxes esperan de forma segura almacenadas na cola sen unha soa orde perdida.

- 06. Orquestración de Contedores (Docker e Kubernetes)

7:13 Concepto número seis: Orquestración de Contedores. Docker resolveu o empaquetado: envolve o código da túa aplicación, as bibliotecas do sistema, a configuración e o tempo de execución nunha imaxe inmutable que se executa de forma idéntica no teu MacBook e na nube. Pero empaquetar un contedor é fácil. Executar cincocentos contedores en cincuenta máquinas virtuais físicas é onde a enxeñería se descompón. É por iso que existen orquestradores de contedores como Kubernetes e AWS ECS.

7:41 Un orquestrador proporciona un plano de control: un servidor de API, un almacén de estado etcd e un planificador intelixente. Declara o teu estado desexado: quero dez réplicas do meu servizo de autenticación con dous gigabytes de RAM cada unha. O planificador inspecciona o clúster, sitúa os "pods" nos nodos con memoria libre, configura a rede interna e reconcilia continuamente a realidade. Se un nodo sofre un fallo de hardware, Kubernetes detecta a perda e reprograma instantaneamente todos os "pods" desprazados en

- 07. Os 4 Pilares de Almacenamento na Nube (S3, EBS, DBs e Redis)

8:16 nodos saudables. Concepto número sete: A Xerarquía de Almacenamento na Nube. Os principiantes a miúdo tratan o almacenamento na nube como un único cubo onde se descargan ficheiros. Na arquitectura de produción, o almacenamento divídese en catro piares distintos baseados en patróns de acceso e latencia. O primeiro é o Almacenamento de Obxectos, como Amazon S3 ou Google Cloud Storage. Accédese aos ficheiros mediante APIs REST HTTP usando chamadas PUT e GET sinxelas. Ofrece capacidade horizontal infinita a dous céntimos por gigabyte ao mes,

8:49 facéndoo ideal para vídeo, cargas de usuarios, rexistros e copias de seguridade. O segundo é o Almacenamento en Bloques, como Amazon EBS. Son discos duros virtuais montados directamente nunha máquina virtual específica a través de interconexións de alta velocidade. Formatean en sistemas de ficheiros estándar como ext4, soportando o acceso rápido de lectura e escritura aleatoria requirido polos motores de bases de datos. O terceiro son as Bases de Datos Xestionadas: motores relacionais como PostgreSQL en RDS que proporcionan transaccións ACID e "joins" complexos,

9:21 e motores NoSQL como DynamoDB que ofrecen latencia de un só díxito de milisegundos a gran escala. E o cuarto son as Cachés en Memoria como Redis. Ler datos da RAM leva microsegundos en lugar de milisegundos. As cachés sitúanse diante da túa base de datos, protexéndoa do tráfico de lectura repetido e xestionando os "tokens" de sesión de usuario volátiles.

- 08. Alta Dispoñibilidade e os Nove (Failover Multi-AZ)

9:44 Concepto número oito: Alta Dispoñibilidade, ou HA. A dispoñibilidade responde a unha pregunta: que porcentaxe do tempo a túa aplicación está operativa e accesible polos usuarios? Nos contratos empresariais, a dispoñibilidade mídese en "noves". Dous "noves", ou noventa e nove por cento de dispoñibilidade, permite máis de tres e medio días de inactividade cada ano. Catro "noves" reduce o tempo de inactividade permitido a cincuenta e dous minutos, e cinco "noves" permite apenas cinco minutos de tempo de inactividade total por

10:15 ano. Para lograr alta dispoñibilidade, debes eliminar os puntos únicos de fallo en todos os dominios de fallo. Na nube, iso significa despregar en varias Zonas de Dispoñibilidade. Unha Zona de Dispoñibilidade non é un único "rack": é un ou máis centros de datos físicos distintos a quilómetros de distancia con enerxía e refrixeración independentes. Ao executar instancias activas na Zona A e na Zona B con replicación síncrona da base de datos, un raio ou un corte de fibra que derrube unha instalación física completa resulta nun "failover" automatizado.

10:50 en trinta segundos sen intervención humana.

- 09. Durabilidade vs. Dispoñibilidade (Por que 11 Noves non é Tempo de Actividade)

10:53 Concepto número nove: Durabilidade contra Dispoñibilidade. Esta é a trampa conceptual máis común nas entrevistas de arquitectura na nube. Os enxeñeiros usan con frecuencia as palabras de xeito intercambiable, pero miden propiedades completamente diferentes. A dispoñibilidade mide o tempo de actividade: podo facer unha chamada API para ler ou escribir os meus datos agora mesmo? A durabilidade mide a preservación: os meus datos sobrevivirán sen putrefacción de bits permanente, corrupción ou destrución durante dez anos?

11:24 Vexamos Amazon S3 Standard. O seu Acordo de Nivel de Servizo ofrece un noventa e nove punto nove por cento de dispoñibilidade, o que permite aproximadamente corenta e tres minutos de tempo de inactividade cada mes onde unha solicitude API podería devolver un erro de cincocentos. Pero S3 promete once noves de durabilidade: noventa e nove punto nove nove nove nove nove nove nove nove nove por cento. Se almacena dez millóns de ficheiros en S3, estatisticamente pode esperar perder unha media

11:56 dun ficheiro cada dez mil anos. S3 consegue isto codificando obxectos con borrado e replicando fragmentos en polo menos tres instalacións de datos xeograficamente separadas. Durante unha interrupción importante da rede rexional, S3 podería estar temporalmente non dispoñible, pero os seus datos nunca son destruídos.

- 10. Infraestrutura como Código (Terraform vs. Console Drift)

12:14 Concepto número dez: Infraestrutura como Código, ou IaC. Nos primeiros días da computación na nube, os enxeñeiros iniciaron sesión na consola de xestión web de AWS e fixeron clic manualmente para crear máquinas virtuais, configurar subredes e asociar grupos de seguridade. A industria chama a isto ClickOps, e en produción, é un desastre absoluto. Os cambios manuais na consola non teñen rastro de auditoría, nin mecanismo de retroceso, e inevitablemente causan deriva de configuración entre os ambientes de staging e produción. Con ferramentas de Infraestrutura

12:48 como Código como Terraform, OpenTofu, Pulumi ou AWS CDK, define toda a súa arquitectura na nube en ficheiros de configuración declarativos almacenados en Git. Cada cambio nun porto aberto ou réplica de base de datos pasa por unha solicitude pull e revisión por pares. Executar 'terraform plan' previsualiza a diferenza exacta da API antes de que se toque nada, e pór en marcha unha réplica idéntica da súa pila de produción leva catro minutos en lugar de catro semanas.

- 11. Rede na Nube (VPC, Subredes, NAT e Grupos de Seguridade)

13:20 Concepto número once: Redes na Nube e Nubes Privadas Virtuais. Cando implementa servidores na nube, non están expostos na Internet pública pura. Viven dentro dun límite illado definido por software chamado VPC. Dentro da súa VPC, asigna un espazo de enderezos IP privados como dez-punto-cero-punto-cero-punto-cero barra dezaseis, e divídeo en subredes públicas e privadas. Unha subrede pública ten unha ruta directa a unha Pasarela de Internet.

13:51 Contén activos de cara ao público como os seus Balanzadores de Carga de Aplicacións e Pasarelas NAT. É a única parte da súa rede que posúe enderezos IP públicos. Os seus servidores de aplicacións e bases de datos de produción viven estritamente en subredes privadas sen IPs públicas e sen rutas de entrada desde a internet. Cando os seus servidores backend necesitan descargar actualizacións de seguridade, o seu tráfico de saída enruta a través da Pasarela NAT na subrede pública. Rodeando cada instancia hai Grupos de Seguridade: cortalumes virtuais estatais que aplican o principio do mínimo privilexio.

- 12. O Plano Empresarial Completo e o Veredicto

14:28 O seu grupo de seguridade da base de datos só acepta conexións no porto 5432 estritamente do grupo de seguridade dos seus servidores de aplicacións, facendo a penetración externa matematicamente imposible. Cando se afasta, estes once elementos primitivos conéctanse nun sistema cohesivo. O seu DNS encamíñase a un Balanceador de Carga nunha subrede pública, os grupos de autoescalado xestionan os picos de tráfico en varias Zonas de Dispoñibilidade, os buses de eventos desacoplan os traballadores backend, e toda a súa pila é implementada desde Git usando Infraestrutura como Código.

15:02 Veredicto da masterclass de hoxe: SHIP IT. Deixe de memorizar centos de acrónimos de mercadotecnia na nube. Domine estes once patróns de arquitectura, desacople o seu estado, e constrúa sistemas que non poidan fallar. Dígame cal concepto da nube lle deu a maior dor de cabeza cando comezou a construír nos comentarios. E para obter a folla de trampas de arquitectura completa, subscríbase ao boletín en the daily diff dot dev,

15:28 ligazón abaixo. E esa é a diferenza de hoxe. Son Niko de Axrisi. Fusionar con responsabilidade.

Fontes

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