═══════════════════════════════════════════════════════════════════════════════
NOTAS DEL PRESENTADOR - COMPLETAS
ARQUITECTURA DE MICROSERVICIOS - 20 DIAPOSITIVAS
═══════════════════════════════════════════════════════════════════════════════
TIEMPO TOTAL ESTIMADO: 25-30 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 1: PORTADA
═══════════════════════════════════════════════════════════════════════════════
Bienvenidos a la presentación sobre Arquitectura de Microservicios. Hoy vamos a
explorar cuatro pilares fundamentales de esta arquitectura moderna:
1. Domain-Driven Design (DDD) y cómo definir contextos delimitados
2. Service Mesh con Istio y su capacidad para gestionar la comunicación entre
servicios
3. El trío de observabilidad: métricas, trazas y logs
4. API Gateway y sus mecanismos de control de tráfico
Esta arquitectura es fundamental en sistemas distribuidos modernos y es utilizada
por empresas como Netflix, Amazon, Uber y muchas más.
TIEMPO ESTIMADO: 30 segundos de introducción
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 2: ÍNDICE
═══════════════════════════════════════════════════════════════════════════════
Esta presentación está estructurada en 4 secciones principales:
1. DOMAIN-DRIVEN DESIGN: Comenzaremos con los conceptos fundamentales de DDD,
específicamente Bounded Contexts (contextos delimitados) y Context Mapping
(mapeo de contextos), que son esenciales para diseñar microservicios cohesivos.
2. SERVICE MESH CON ISTIO: Veremos cómo Istio utiliza el patrón sidecar con Envoy
para gestionar la comunicación entre servicios, incluyendo seguridad automática
con mTLS.
3. OBSERVABILITY TRIO: Exploraremos las tres dimensiones de la observabilidad:
métricas con Prometheus, trazas distribuidas con Jaeger, y agregación de logs
con Fluentd.
4. API GATEWAY: Finalmente, estudiaremos los mecanismos de control de tráfico:
rate limiting, spike arrest y quotas.
TIEMPO ESTIMADO: 45 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 3: INTRODUCCIÓN A MICROSERVICIOS
═══════════════════════════════════════════════════════════════════════════════
INTRODUCCIÓN A MICROSERVICIOS:
Definición: Los microservicios son un estilo arquitectónico que descompone
aplicaciones monolíticas en servicios pequeños y especializados. Cada servicio
se enfoca en una capacidad de negocio específica.
CARACTERÍSTICAS CLAVE:
1. MODULARIDAD: Cada microservicio es una unidad funcional independiente. Esto
permite que equipos diferentes trabajen en servicios diferentes sin interferir
entre sí.
2. BASE DE DATOS PROPIA: Cada servicio gestiona su propia base de datos. Esto
evita el acoplamiento a nivel de datos y permite que cada servicio elija la
tecnología de persistencia más adecuada (patrón Database per Service).
3. AUTONOMÍA: Los servicios se pueden desarrollar, desplegar y escalar de forma
completamente independiente. Un cambio en un servicio no requiere redesplegar
toda la aplicación.
4. ESCALABILIDAD: Podemos escalar horizontalmente solo los servicios que lo
necesiten, en lugar de escalar toda la aplicación monolítica.
Contraste con monolitos: En un monolito, todo el código está en una sola
aplicación. Un cambio pequeño requiere redesplegar todo. En microservicios, cada
servicio es independiente.
TIEMPO ESTIMADO: 1 minuto y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 4: DOMAIN-DRIVEN DESIGN - INTRODUCCIÓN
═══════════════════════════════════════════════════════════════════════════════
TRANSICIÓN A DOMAIN-DRIVEN DESIGN:
Domain-Driven Design (DDD) es una metodología de diseño de software propuesta por
Eric Evans en 2003. Es fundamental para diseñar microservicios efectivos.
¿Por qué DDD es importante para microservicios?
- Ayuda a identificar los límites naturales entre servicios
- Promueve un lenguaje común entre desarrolladores y expertos del dominio
- Evita crear microservicios demasiado pequeños o demasiado grandes
DDD se enfoca en modelar el software basándose en la complejidad del dominio del
negocio, no en la complejidad técnica.
Los dos conceptos clave que veremos son:
1. Bounded Contexts (Contextos Delimitados)
2. Context Mapping (Mapeo de Contextos)
TIEMPO ESTIMADO: 45 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 5: BOUNDED CONTEXTS
═══════════════════════════════════════════════════════════════════════════════
BOUNDED CONTEXTS (CONTEXTOS DELIMITADOS):
DEFINICIÓN:
Un Bounded Context es un límite lógico y explícito que define el alcance donde un
modelo de dominio específico es aplicable y consistente. Es uno de los patrones
más importantes de DDD.
CONCEPTO CLAVE:
El mismo concepto puede tener diferentes significados en diferentes contextos. Por
ejemplo, "Producto":
- En el contexto de CATÁLOGO: incluye descripción, imágenes, categorías, reseñas
- En el contexto de PEDIDOS: solo necesita ID, nombre, precio, cantidad
- En el contexto de INVENTARIO: incluye SKU, stock disponible, ubicación en
almacén
- En el contexto de ENVÍOS: solo necesita dimensiones, peso, y fragilidad
EJEMPLO VISUAL:
En un sistema de e-commerce, tenemos 4 bounded contexts claramente diferenciados.
Cada uno modela "Producto" de manera diferente según sus necesidades.
BENEFICIOS:
1. REDUCE AMBIGÜEDAD: Al definir límites claros, evitamos confusión sobre qué
significa cada término en cada contexto.
2. EVOLUCIÓN INDEPENDIENTE: Cada contexto puede evolucionar sin afectar a otros.
Podemos cambiar el modelo de Catálogo sin impactar Pedidos.
3. DIVISIÓN EN MICROSERVICIOS: Cada bounded context es un candidato natural para
convertirse en un microservicio independiente.
4. COMUNICACIÓN MEJORADA: Los equipos tienen un lenguaje ubicuo (ubiquitous
language) dentro de su contexto.
REGLA PRÁCTICA: Si dos equipos diferentes están discutiendo sobre el significado
de un término, probablemente estén en diferentes bounded contexts.
TIEMPO ESTIMADO: 2 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 6: CONTEXT MAPPING
═══════════════════════════════════════════════════════════════════════════════
CONTEXT MAPPING (MAPEO DE CONTEXTOS):
DEFINICIÓN:
Context Mapping es el proceso de documentar y diseñar las relaciones entre
diferentes Bounded Contexts. Define cómo se comunican, qué datos comparten, y
quién depende de quién.
IMPORTANCIA:
Una vez que tenemos múltiples bounded contexts (potencialmente microservicios),
necesitamos definir cómo interactúan. El context map es literalmente un mapa que
muestra estas relaciones.
PATRONES PRINCIPALES:
1. PARTNERSHIP (Asociación):
- Dos equipos tienen un objetivo común y colaboran estrechamente
- Coordinan cambios juntos
- Ejemplo: Servicio de Pedidos y Servicio de Pagos trabajando juntos para
garantizar transacciones exitosas
2. SHARED KERNEL (Núcleo Compartido):
- Dos o más contextos comparten un subconjunto pequeño del modelo
- Requiere coordinación para cambios
- Ejemplo: Pedidos e Inventario comparten el concepto de "SKU de producto"
- CUIDADO: No abusar de este patrón, puede crear acoplamiento
3. CUSTOMER-SUPPLIER (Cliente-Proveedor):
- Relación upstream/downstream clara
- El proveedor (upstream) define el contrato
- El cliente (downstream) consume la API
- Ejemplo: Servicio de Catálogo (upstream) provee datos a Servicio de
Recomendaciones (downstream)
4. ANTICORRUPTION LAYER (Capa Anti-corrupción):
- Capa de traducción que aísla un contexto de otro
- Previene que conceptos de un modelo contaminen otro
- Muy importante al integrar con sistemas legacy o externos
- Ejemplo: Traducir entre nuestro modelo interno de "Cliente" y el modelo de un
CRM externo
REGLA DE ORO:
El context map debe reflejar no solo las dependencias técnicas, sino también las
relaciones organizacionales entre equipos.
TIEMPO ESTIMADO: 2 minutos y 15 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 7: SERVICE MESH - INTRODUCCIÓN
═══════════════════════════════════════════════════════════════════════════════
TRANSICIÓN A SERVICE MESH:
Ahora que entendemos cómo diseñar microservicios con DDD, necesitamos abordar un
desafío crítico: ¿Cómo gestionamos la comunicación entre decenas o cientos de
microservicios?
PROBLEMA:
En una arquitectura de microservicios, los servicios se comunican constantemente
entre sí por red. Esto introduce complejidad:
- ¿Cómo manejamos reintentos cuando un servicio falla?
- ¿Cómo balanceamos carga entre instancias?
- ¿Cómo aseguramos la comunicación?
- ¿Cómo monitoreamos el tráfico?
SOLUCIÓN TRADICIONAL (problemática):
Cada servicio implementa su propia lógica de comunicación, lo que resulta en:
- Código duplicado en cada servicio
- Diferentes implementaciones (inconsistencia)
- Difícil de actualizar o cambiar
SOLUCIÓN MODERNA: SERVICE MESH
Una capa de infraestructura dedicada que maneja toda la comunicación
service-to-service, externalizando esta complejidad del código de la aplicación.
Istio es la implementación de Service Mesh más popular y madura. Vamos a explorar
cómo funciona.
TIEMPO ESTIMADO: 1 minuto y 15 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 8: ARQUITECTURA DE ISTIO
═══════════════════════════════════════════════════════════════════════════════
ARQUITECTURA DE ISTIO:
Istio se compone de dos planos principales:
1. DATA PLANE (Plano de Datos):
- Consiste en un conjunto de proxies Envoy desplegados como sidecars
- Un sidecar es un contenedor adicional que se ejecuta junto a cada instancia de
servicio en el mismo pod (en Kubernetes)
- Estos proxies interceptan TODO el tráfico de red entrante y saliente del
servicio
- Ejecutan políticas como rate limiting, circuit breaking, y autenticación
- Recopilan telemetría (métricas, logs, trazas)
2. CONTROL PLANE (Plano de Control):
- Istiod es el componente central (unificado desde Istio 1.5)
- Configura y gestiona los proxies del data plane
- Gestiona certificados para mTLS
- Descubrimiento de servicios: mantiene un registro actualizado de todos los
servicios
- Convierte configuraciones de alto nivel en configuraciones de Envoy
FLUJO DE TRÁFICO:
Cuando el Servicio A quiere comunicarse con el Servicio B:
1. La petición sale del Servicio A pero es interceptada por su sidecar Envoy
2. Envoy aplica políticas (autenticación, rate limiting, etc.)
3. Envoy enruta la petición al sidecar de Servicio B
4. El sidecar de Servicio B valida y aplica políticas de entrada
5. Finalmente, la petición llega al Servicio B
Todo esto ocurre de forma transparente - los servicios no saben que Istio existe.
Istiod configura todos estos proxies de forma centralizada, garantizando políticas
consistentes.
TIEMPO ESTIMADO: 2 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 9: ENVOY SIDECAR PATTERN
═══════════════════════════════════════════════════════════════════════════════
ENVOY SIDECAR PATTERN:
¿QUÉ ES ENVOY?
Envoy es un proxy de red de alto rendimiento desarrollado originalmente por Lyft
y ahora es un proyecto de la CNCF (Cloud Native Computing Foundation).
Características clave:
- Escrito en C++ para máximo rendimiento
- Diseñado específicamente para arquitecturas cloud-native
- API dinámica de configuración (xDS APIs)
- Telemetría rica integrada
CARACTERÍSTICAS TÉCNICAS DE ENVOY:
1. LOAD BALANCING AVANZADO: Soporta múltiples algoritmos (round-robin, least
request, ring hash, random, etc.)
2. CIRCUIT BREAKING: Previene cascadas de fallos al detener peticiones a servicios
que están fallando
3. HEALTH CHECKING: Verifica constantemente la salud de los endpoints y elimina
los no saludables del pool
4. OBSERVABILIDAD: Genera métricas, logs y trazas automáticamente sin cambios en
el código
5. SERVICE DISCOVERY DINÁMICO: Se actualiza automáticamente cuando servicios se
agregan o eliminan
6. RETRY Y TIMEOUTS: Configuración granular de políticas de reintento y tiempo de
espera
PATRÓN SIDECAR:
El patrón sidecar es fundamental en Istio:
- En Kubernetes, un Pod puede contener múltiples contenedores
- Istio inyecta automáticamente un contenedor Envoy junto a cada contenedor de
aplicación
- Ambos contenedores comparten:
* La misma interfaz de red (localhost)
* El mismo namespace de almacenamiento
* El mismo ciclo de vida
FLUJO:
1. Todo el tráfico de entrada y salida de la aplicación es interceptado por Envoy
mediante iptables
2. Envoy aplica políticas, recopila métricas y luego enruta el tráfico
3. La aplicación no sabe que Envoy existe - es completamente transparente
VENTAJA CLAVE: La lógica de red se externaliza completamente de la aplicación.
Puedes cambiar políticas sin tocar código.
TIEMPO ESTIMADO: 2 minutos y 15 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 10: mTLS AUTOMÁTICO CON ISTIO
═══════════════════════════════════════════════════════════════════════════════
mTLS AUTOMÁTICO CON ISTIO:
¿QUÉ ES mTLS?
TLS tradicional (como HTTPS) solo autentica el servidor - el cliente verifica que
está hablando con el servidor correcto.
mTLS (mutual TLS) es bidireccional: TANTO el cliente COMO el servidor verifican la
identidad del otro usando certificados digitales. Esto es crítico en arquitecturas
de microservicios donde servicios necesitan confiar mutuamente.
BENEFICIOS DE mTLS:
1. ENCRIPTACIÓN: Todo el tráfico entre servicios está encriptado, protegiendo
datos
en tránsito
2. AUTENTICACIÓN FUERTE: Cada servicio puede verificar la identidad del servicio
con el que está comunicando
3. PREVENCIÓN DE MAN-IN-THE-MIDDLE: Un atacante no puede interceptar ni modificar
tráfico entre servicios
4. CUMPLIMIENTO: Muchas normativas (PCI DSS, HIPAA) requieren encriptación de
datos
sensibles
AUTOMATIZACIÓN EN ISTIO:
El mayor valor de Istio es que mTLS es completamente automático:
PASO 1: Istiod actúa como Certificate Authority (CA) y genera certificados X.509
únicos para cada servicio/workload
PASO 2: Distribuye estos certificados a los proxies Envoy correspondientes
PASO 3: Los proxies Envoy usan estos certificados automáticamente para establecer
conexiones mTLS entre servicios
PASO 4: Rotación automática: Istio rota los certificados cada 24 horas por defecto
(configurable). Esto elimina el riesgo de certificados comprometidos a largo plazo
VENTAJA CLAVE:
Sin Istio, implementar mTLS requiere:
- Gestionar una CA
- Distribuir certificados manualmente
- Implementar lógica en cada servicio para usar certificados
- Gestionar rotación y renovación
Con Istio: CERO CAMBIOS en el código de la aplicación. Los servicios ni siquiera
saben que mTLS existe - todo ocurre a nivel de proxy.
Puedes habilitar/deshabilitar mTLS con una simple configuración YAML sin tocar
servicios.
TIEMPO ESTIMADO: 2 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 11: OBSERVABILITY TRIO - INTRODUCCIÓN
═══════════════════════════════════════════════════════════════════════════════
TRANSICIÓN A OBSERVABILITY:
Ahora que tenemos múltiples microservicios comunicándose de forma segura, surge
una pregunta crítica: ¿Cómo entendemos qué está pasando en nuestro sistema
distribuido?
PROBLEMA DE VISIBILIDAD:
En un monolito:
- Un solo proceso para debuggear
- Stack traces completos
- Logs centralizados en un solo lugar
En microservicios:
- Decenas o cientos de servicios
- Una petición puede atravesar 10+ servicios
- Logs distribuidos en múltiples lugares
- Difícil rastrear errores a través de servicios
SOLUCIÓN: OBSERVABILITY (OBSERVABILIDAD)
Observability es la capacidad de entender el estado interno de un sistema
basándose en sus salidas externas.
Hay tres pilares fundamentales de observabilidad, conocidos como "The Three
Pillars":
1. METRICS (Métricas): ¿QUÉ está pasando? - Números agregados
2. TRACES (Trazas): ¿DÓNDE está pasando? - Seguimiento de peticiones
3. LOGS (Registros): ¿POR QUÉ está pasando? - Detalles contextuales
Vamos a explorar cada pilar con las herramientas estándar de la industria:
- Prometheus para métricas
- Jaeger para trazas distribuidas
- Fluentd para agregación de logs
Estas tres herramientas juntas forman el "observability trio" que nos da
visibilidad completa.
TIEMPO ESTIMADO: 1 minuto y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 12: PROMETHEUS - MÉTRICAS
═══════════════════════════════════════════════════════════════════════════════
PROMETHEUS - MÉTRICAS:
¿QUÉ SON LAS MÉTRICAS?
Las métricas son mediciones numéricas recopiladas a lo largo del tiempo. Responden
a preguntas como:
- ¿Cuántas peticiones por segundo estamos recibiendo?
- ¿Cuál es la latencia promedio?
- ¿Cuántos errores estamos teniendo?
- ¿Cuánta memoria está usando mi servicio?
Las métricas son agregadas - no guardan detalles de cada petición individual, sino
estadísticas.
TIPOS DE MÉTRICAS EN PROMETHEUS:
1. COUNTER (Contador):
- Solo puede incrementar (nunca decrementar)
- Se resetea a 0 cuando el servicio reinicia
- Ejemplo: total_http_requests, total_errors
- Útil para calcular tasas (requests/segundo)
2. GAUGE (Medidor):
- Puede subir y bajar
- Representa un valor instantáneo
- Ejemplo: memory_usage_bytes, active_connections, temperature
- Útil para snapshots del estado actual
3. HISTOGRAM (Histograma):
- Agrupa observaciones en buckets configurables
- Calcula sumas y conteos
- Ejemplo: request_duration_seconds con buckets [0.1, 0.5, 1.0, 2.5]
- Permite calcular percentiles aproximados (P50, P95, P99)
4. SUMMARY (Resumen):
- Similar a histogram pero calcula percentiles directamente en el cliente
- Más costoso computacionalmente
- Percentiles exactos pero no agregables
CARACTERÍSTICAS CLAVE DE PROMETHEUS:
1. PULL-BASED:
- Prometheus "extrae" (pull) métricas de los servicios periódicamente
- Cada servicio expone un endpoint HTTP (ej: /metrics)
- Contrasta con sistemas push-based como StatsD
2. PROMQL:
- Lenguaje de consulta potente y expresivo
- Ejemplo: rate(http_requests_total[5m]) - tasa de requests en últimos 5 minutos
- Soporta agregaciones, funciones matemáticas, joins
3. ALERTING:
- Alertmanager evalúa reglas y envía notificaciones
- Ejemplo: alertar si latencia P95 > 1 segundo por más de 5 minutos
- Integra con Slack, PagerDuty, email, etc.
4. INTEGRACIÓN CON GRAFANA:
- Prometheus almacena datos, Grafana visualiza
- Dashboards interactivos y hermosos
- Grafana consulta Prometheus usando PromQL
EN MICROSERVICIOS:
Cada servicio expone métricas en formato Prometheus. Istio/Envoy genera métricas
automáticamente de tráfico, latencias, errores sin cambios en código.
TIEMPO ESTIMADO: 2 minutos y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 13: JAEGER - TRAZAS DISTRIBUIDAS
═══════════════════════════════════════════════════════════════════════════════
JAEGER - TRAZAS DISTRIBUIDAS:
¿QUÉ SON LAS TRAZAS DISTRIBUIDAS?
Imagina una petición de usuario: "Crear pedido". En microservicios, esto puede
resultar en:
1. API Gateway recibe petición
2. Auth Service valida token
3. Order Service crea pedido
4. Payment Service procesa pago
5. Inventory Service reduce stock
6. Notification Service envía email
Una traza distribuida captura TODO este flujo, mostrando:
- Qué servicios se invocaron
- En qué orden
- Cuánto tiempo tomó cada uno
- Si hubo errores
ANATOMÍA DE UNA TRAZA:
El diagrama muestra una línea de tiempo real. Observen:
- API Gateway es el span padre que dura toda la petición (1.5 segundos)
- Auth Service se ejecuta primero y rápido (0.4 segundos)
- Order Service inicia después y toma más tiempo
- Payment e Inventory se ejecutan en paralelo (visible en la superposición)
CONCEPTOS CLAVE:
1. TRACE (Traza):
- Representa UNA petición end-to-end completa
- Tiene un trace_id único (ej: "a1b2c3d4e5f6")
- Agrupa todos los spans relacionados
2. SPAN:
- Una operación individual dentro de la traza
- Cada llamada a servicio es un span
- Incluye: nombre, timestamp inicio/fin, tags, logs
- Ejemplo: "POST /api/orders" en Order Service
3. TRACE ID:
- Identificador único generado al inicio
- Se propaga en headers HTTP (ej: x-trace-id)
- Permite correlacionar spans de diferentes servicios
4. PARENT/CHILD (Padre/Hijo):
- Los spans tienen relaciones jerárquicas
- Order Service span es hijo de API Gateway span
- Payment Service span es hijo de Order Service span
- Esto forma un árbol de spans
BENEFICIOS EN MICROSERVICIOS:
1. DEBUGGING: "Este pedido falló" → Miras la traza → ves que Payment Service
tardó 10 segundos
2. ANÁLISIS DE LATENCIA: Identificas qué servicio es el cuello de botella
3. DEPENDENCIAS: Visualizas qué servicios llaman a qué otros
4. ANÁLISIS DE ERRORES: Ves exactamente dónde falló una petición
IMPLEMENTACIÓN CON ISTIO:
Istio/Envoy genera automáticamente spans y propaga trace IDs sin cambios en código
(aunque para trazas completas, los servicios deben propagar headers).
TIEMPO ESTIMADO: 2 minutos y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 14: FLUENTD - AGREGACIÓN DE LOGS
═══════════════════════════════════════════════════════════════════════════════
FLUENTD - AGREGACIÓN DE LOGS:
¿QUÉ SON LOS LOGS?
Los logs son registros textuales de eventos. Mientras que las métricas te dicen
"QUÉ" está pasando en números, y las trazas te dicen "DÓNDE" está pasando el
flujo, los logs te dicen "POR QUÉ" con detalles contextuales.
Ejemplos de logs:
- "2024-03-19 10:15:32 ERROR OrderService: Payment failed for order #12345 Insufficient funds"
- "2024-03-19 10:15:33 INFO InventoryService: Stock reduced for SKU ABC-123,
remaining: 47"
PROBLEMA EN MICROSERVICIOS:
Sin una solución centralizada:
1. LOGS DISPERSOS: Cada servicio genera logs en su propio contenedor/pod
2. FORMATOS DIFERENTES: JSON, texto plano, formatos personalizados
3. CORRELACIÓN DIFÍCIL: ¿Cómo vinculas el log de Payment Service con el log de
Order Service para la misma petición?
4. PÉRDIDA DE LOGS: Cuando un pod muere, sus logs se pierden si no están agregados
SOLUCIÓN: FLUENTD
Fluentd es un recolector de logs de código abierto que:
- Unifica la recolección de logs de múltiples fuentes
- Normaliza formatos
- Enriquece con metadatos
- Enruta a diferentes destinos
ARQUITECTURA - PIPELINE DE 4 ETAPAS:
1. INPUT (Entrada):
- Recolecta logs de múltiples fuentes
- Fuentes: archivos de log, stdout/stderr de contenedores, syslog, HTTP
- En Kubernetes: DaemonSet que lee logs de todos los pods en el nodo
2. FILTER (Filtro):
- Parsea logs (convierte texto a JSON estructurado)
- Enriquece con metadatos (namespace, pod name, trace_id)
- Filtra logs no deseados (debug logs en producción)
- Transforma datos (ofuscar información sensible)
3. BUFFER (Buffer):
- Almacena temporalmente logs en memoria o disco
- Maneja picos de tráfico
- Permite reintentos si el destino falla
4. OUTPUT (Salida):
- Envía logs procesados a destinos
- Destinos comunes: Elasticsearch, S3, Kafka, Splunk
- Puede enviar a múltiples destinos simultáneamente
STACK EFK:
La combinación más común en Kubernetes:
- ELASTICSEARCH: Base de datos NoSQL que almacena y indexa logs
- FLUENTD: Recolecta, procesa y envía logs a Elasticsearch
- KIBANA: UI web para buscar, visualizar y analizar logs
Flujo completo:
1. Pods emiten logs a stdout/stderr
2. Fluentd DaemonSet los recolecta
3. Fluentd parsea, enriquece y envía a Elasticsearch
4. Desarrolladores buscan/visualizan en Kibana
VALOR EN DEBUGGING:
Ves en Jaeger que Payment Service falló. Vas a Kibana, buscas por trace_id, y ves
el log exacto: "Payment gateway returned error 503".
TIEMPO ESTIMADO: 2 minutos y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 15: API GATEWAY - INTRODUCCIÓN
═══════════════════════════════════════════════════════════════════════════════
TRANSICIÓN A API GATEWAY:
Hemos visto cómo diseñar microservicios (DDD), cómo gestionan comunicación segura
(Istio), y cómo los monitoreamos (Observability). Ahora: ¿Cómo acceden los
clientes a estos servicios?
PROBLEMA SIN API GATEWAY:
Imagina una app móvil que necesita:
- Autenticar usuario
- Buscar productos
- Crear pedido
- Procesar pago
Sin API Gateway:
- El cliente debe conocer la IP/URL de cada servicio
- Debe manejar autenticación separadamente con cada servicio
- Expone la arquitectura interna
- Complica cambios (si divides un servicio, afectas clientes)
SOLUCIÓN: API GATEWAY
Un API Gateway es un punto de entrada único que:
1. Acepta todas las llamadas de clientes
2. Enruta a los servicios backend apropiados
3. Agrega respuestas de múltiples servicios si es necesario
4. Aplica políticas transversales
BENEFICIOS CLAVE:
- ABSTRACCIÓN: Clientes no conocen arquitectura interna
- SEGURIDAD: Punto único para aplicar autenticación/autorización
- CONTROL DE TRÁFICO: Rate limiting, throttling, quotas
- TRANSFORMACIÓN: Convertir entre protocolos (REST ↔ gRPC)
- AGREGACIÓN: Combinar múltiples llamadas en una
Ejemplos populares: Kong, AWS API Gateway, Azure API Management, Apigee,
Ambassador
Vamos a enfocarnos en tres mecanismos críticos de control de tráfico:
1. Rate Limiting
2. Spike Arrest
3. Quotas
TIEMPO ESTIMADO: 1 minuto y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 16: RATE LIMITING
═══════════════════════════════════════════════════════════════════════════════
RATE LIMITING (LIMITACIÓN DE TASA):
¿QUÉ ES RATE LIMITING?
Rate limiting controla cuántas peticiones puede hacer un cliente (identificado por
API key, IP, o user ID) en una ventana de tiempo.
Ejemplo común: "100 requests por minuto por API key"
PROPÓSITO:
1. PREVENIR SOBRECARGA: Protege servicios backend de ser abrumados
2. USO JUSTO: Evita que un cliente abuse de recursos
3. SEGURIDAD: Mitiga ataques DDoS y brute force
4. MODELOS DE NEGOCIO: Planes gratuitos vs premium (100 req/min vs 10,000 req/min)
EJEMPLO PRÁCTICO:
Cliente hace peticiones a lo largo de un minuto:
- 0:00 - 20 requests → PERMITIDO (acumulado: 20)
- 0:15 - 30 requests → PERMITIDO (acumulado: 50)
- 0:30 - 40 requests → PERMITIDO (acumulado: 90)
- 0:45 - 15 requests → BLOQUEADO (acumulado sería 105 > límite de 100)
El cliente recibe HTTP 429 "Too Many Requests"
ALGORITMOS PRINCIPALES:
1. FIXED WINDOW (Ventana Fija):
- Divide tiempo en ventanas fijas (ej: cada minuto empieza a las 10:00:00,
10:01:00, etc.)
- Contador se resetea al inicio de cada ventana
- PROBLEMA: Permite el doble del límite al borde de ventanas
* Ejemplo: 100 requests a las 10:00:59 + 100 requests a las 10:01:00 = 200 en
2 segundos
2. SLIDING WINDOW (Ventana Deslizante):
- Ventana de tiempo se mueve continuamente
- Cuenta requests en los últimos N segundos desde ahora
- MÁS PRECISO pero más costoso computacionalmente
- Requiere guardar timestamp de cada request
3. TOKEN BUCKET (Cubeta de Tokens):
- Bucket (cubeta) se llena con tokens a tasa constante (ej: 100 tokens/minuto)
- Cada request consume 1 token
- Si no hay tokens, request se rechaza
- VENTAJA: Permite ráfagas cortas (burst) si hay tokens acumulados
- Usado por AWS API Gateway
IMPLEMENTACIÓN:
API Gateway verifica límites antes de enrutar al backend. Si se excede, retorna
429 inmediatamente sin tocar servicios.
TIEMPO ESTIMADO: 2 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 17: SPIKE ARREST
═══════════════════════════════════════════════════════════════════════════════
SPIKE ARREST (ARRESTO DE PICOS):
¿QUÉ ES SPIKE ARREST?
Mientras que rate limiting cuenta el número total de peticiones en una ventana,
spike arrest se enfoca en SUAVIZAR la distribución de esas peticiones a lo largo
del tiempo.
DIFERENCIA CLAVE CON RATE LIMITING:
Imagina un límite de 100 requests/minuto:
CON SOLO RATE LIMITING:
- Cliente puede enviar las 100 peticiones en los primeros 5 segundos
- Luego espera 55 segundos sin poder hacer nada
- Esto puede causar picos de carga que sobrecargan el backend
CON SPIKE ARREST:
- 100 requests/minuto = máximo 1.66 requests/segundo
- Si el cliente envía 10 requests en 1 segundo, spike arrest rechaza 8 (solo
permite ~2)
- Fuerza una distribución más uniforme del tráfico
VISUALIZACIÓN:
Gráfica izquierda (SIN SPIKE ARREST):
- Barras irregulares muestran ráfagas grandes
- Algunas barras muy altas (picos de 15+ requests/segundo)
- Otras muy bajas (1-2 requests/segundo)
- Total puede estar dentro de límite, pero picos sobrecargan
Gráfica derecha (CON SPIKE ARREST):
- Barras más uniformes en altura
- Tráfico distribuido de manera más pareja
- Backend recibe carga consistente y manejable
CÓMO FUNCIONA:
Si configuras 100 requests/minuto:
1. API Gateway calcula: 100/60 = 1.66 requests por segundo
2. Cada segundo, permite máximo ~2 peticiones
3. Si llegan 10 peticiones en 1 segundo, 8 se rechazan con HTTP 429
BENEFICIO:
Protege el backend de picos súbitos que pueden causar:
- Aumento repentino de latencia
- Agotamiento de recursos (conexiones a DB)
- Cascadas de fallos
ANALOGÍA:
Rate limiting es como un portero que cuenta cuántas personas entraron en la última
hora. Spike arrest es como un portero que solo deja pasar 2 personas por minuto,
sin importar si hay una fila de 50 esperando.
USO COMÚN:
Se combinan ambos:
- Rate limiting: 10,000 requests/hora por cliente
- Spike arrest: Máximo 100 requests/segundo
Esto permite throughput alto pero protege de ráfagas.
TIEMPO ESTIMADO: 2 minutos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 18: QUOTA
═══════════════════════════════════════════════════════════════════════════════
QUOTA (CUOTA):
¿QUÉ ES QUOTA?
Quota establece un límite de uso total durante un período largo (generalmente
días,
semanas o meses), independientemente de cómo se distribuyan las peticiones en ese
período.
DIFERENCIA FUNDAMENTAL:
Mientras rate limiting y spike arrest se preocupan por la TASA (velocidad) de
peticiones, quota se preocupa por el VOLUMEN TOTAL.
Ejemplo:
- Rate limiting: "No más de 100 peticiones por minuto"
- Spike arrest: "No más de 2 peticiones por segundo"
- Quota: "No más de 1 millón de peticiones este mes"
COMPARACIÓN DETALLADA:
1. RATE LIMITING:
- Ventana: Corto plazo (segundos, minutos)
- Ejemplo: 100 requests/minuto
- Propósito: Prevenir sobrecarga del backend
- Se resetea rápidamente (cada minuto/hora)
2. SPIKE ARREST:
- Ventana: Muy corto plazo (subsegundos, segundos)
- Ejemplo: 10 requests/segundo
- Propósito: Suavizar picos y ráfagas
- Distribución uniforme del tráfico
3. QUOTA:
- Ventana: Largo plazo (días, semanas, meses)
- Ejemplo: 1 millón requests/mes
- Propósito: Modelo de negocio, monetización
- Se resetea mensualmente
USO EN PLANES DE SERVICIO:
Las quotas son fundamentales para modelos de negocio basados en API:
PLAN FREE:
- Quota: 10,000 requests/mes
- Rate limit: 10 requests/minuto
- Permite a usuarios probar el servicio
PLAN PRO ($99/mes):
- Quota: 1,000,000 requests/mes
- Rate limit: 1,000 requests/minuto
- Para negocios pequeños a medianos
PLAN ENTERPRISE (Personalizado):
- Quota: Ilimitado o muy alto
- Rate limit: 10,000 requests/minuto
- Para grandes corporaciones
IMPLEMENTACIÓN:
API Gateway rastrea el consumo acumulado:
1. Cada petición incrementa contador del mes actual
2. Si contador >= quota, retorna 429 con mensaje "Monthly quota exceeded"
3. Contador se resetea el primer día del siguiente mes
VENTAJA:
Permite a los clientes planificar su uso. Pueden usar su quota rápido o lento,
pero una vez agotada, deben esperar al siguiente período o actualizar plan.
COMBINACIÓN:
En la práctica, se combinan los tres:
- Quota: 1M requests/mes (control de volumen)
- Rate limiting: 1000 requests/minuto (prevenir sobrecarga)
- Spike arrest: 50 requests/segundo (suavizar picos)
Esto garantiza uso justo, protección del backend, y modelo de negocio sostenible.
TIEMPO ESTIMADO: 2 minutos y 15 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 19: RESUMEN
═══════════════════════════════════════════════════════════════════════════════
RESUMEN DE LA PRESENTACIÓN:
Hemos recorrido los cuatro pilares fundamentales de la arquitectura de
microservicios moderna:
1. DOMAIN-DRIVEN DESIGN:
- Los Bounded Contexts nos ayudan a definir límites claros entre servicios
- El Context Mapping documenta y gestiona las relaciones entre contextos
- DDD proporciona la base conceptual para diseñar microservicios cohesivos y bien
delimitados
2. SERVICE MESH CON ISTIO:
- El patrón Envoy sidecar intercepta y gestiona todo el tráfico de red
- mTLS automático proporciona seguridad sin modificar el código de las
aplicaciones
- Istio centraliza la gestión de comunicación, liberando a los servicios de esta
complejidad
3. OBSERVABILITY TRIO:
- Prometheus recopila métricas agregadas para entender QUÉ está pasando
- Jaeger rastrea peticiones distribuidas para saber DÓNDE está pasando
- Fluentd agrega logs para descubrir POR QUÉ está pasando
- Juntos proporcionan visibilidad completa del sistema distribuido
4. API GATEWAY:
- Rate Limiting controla la tasa de peticiones para prevenir sobrecarga
- Spike Arrest suaviza picos de tráfico distribuyendo peticiones uniformemente
- Quotas establecen límites de uso a largo plazo para modelos de negocio
Estos componentes trabajan juntos para crear una arquitectura de microservicios
robusta, observable y escalable.
TIEMPO ESTIMADO: 1 minuto y 30 segundos
═══════════════════════════════════════════════════════════════════════════════
DIAPOSITIVA 20: CIERRE
═══════════════════════════════════════════════════════════════════════════════
CIERRE:
Hemos completado nuestro recorrido por los componentes esenciales de la
arquitectura de microservicios.
PUNTOS CLAVE FINALES:
- Domain-Driven Design nos ayuda a DISEÑAR microservicios bien delimitados
- Service Mesh gestiona la COMUNICACIÓN de forma transparente y segura
- Observability nos da VISIBILIDAD completa del sistema distribuido
- API Gateway proporciona CONTROL de acceso y tráfico
Estos no son componentes aislados - trabajan juntos en un ecosistema cohesivo que
permite construir sistemas distribuidos complejos de manera manejable.
APLICACIÓN PRÁCTICA:
Cuando diseñen su próximo sistema de microservicios:
1. Empiecen con DDD para definir bounded contexts
2. Usen Istio para gestionar comunicación
3. Implementen observability desde el día 1
4. Agreguen API Gateway para control de acceso
PRÓXIMOS PASOS:
- Explorar implementaciones prácticas de cada componente
- Estudiar casos de uso reales en producción
- Experimentar con estas tecnologías en entornos de desarrollo
Ahora estoy disponible para responder cualquier pregunta que tengan.
TIEMPO ESTIMADO: 1 minuto
═══════════════════════════════════════════════════════════════════════════════
FIN DE LAS NOTAS
═══════════════════════════════════════════════════════════════════════════════