Módulo 8: Capstone The Andes Cargo Pipeline

7. Lo que Andes Cargo todavía necesita

Siguiente →

Descripción

Las lecciones 5 y 6 trazaron dos fronteras de honestidad: qué no se pudo ejecutar bajo act, y qué seguridad esta guía nunca se propuso construir. Esta lección cierra el mapa completo con una tercera frontera, distinta a las dos anteriores: no lo que falta dentro de este pipeline, sino lo que Andes Cargo, como sistema completo, todavía necesitaría para operar en producción real, más allá de CI/CD. Tres piezas, cada una con su propia guía dedicada en este ecosistema: cómputo a escala con Kubernetes y el GitOps pull-based que ya nombró el Módulo 7, la disciplina operacional de qué hacer cuando algo falla en producción, y el control de costos de la infraestructura que este pipeline despliega.

Conexión con el módulo

Esta lección no ejecuta nada — es la última pieza puramente conceptual de esta guía antes del proyecto final de la lección 8. Retoma, sin repetir en detalle, lo que el Módulo 7 ya nombró sobre ArgoCD/Flux y GitOps pull-based, y agrega dos dominios que ninguna lección anterior de esta guía mencionó todavía: SRE del propio despliegue, y FinOps de infraestructura.

Analogía: la fábrica ya construida, y las tres preguntas que siguen

Piensa en Andes Cargo, tal como quedó al cerrar esta guía, como una fábrica recién inaugurada: la línea de montaje funciona (el pipeline), tiene revisión de calidad en cada estación (ci.yml, el guardrail), y un protocolo claro para aplicar cambios aprobados (apply.yml). Inaugurar la fábrica no es el final de la historia — es el punto donde empiezan tres preguntas distintas, cada una con su propio equipo especializado en una operación real: ¿qué pasa si la demanda crece más allá de lo que esta línea puede producir? (escala), ¿qué pasa la noche que algo se rompe y nadie lo estaba mirando? (operación de incidentes), y ¿cuánto está costando operar esta fábrica, y podría costar menos sin perder capacidad? (control de costos). Esta lección nombra, sin construir, la respuesta de esta guía a cada una.

1. Cómputo a escala: EKS y el GitOps pull-based

El Módulo 7, lecciones 3 y 4, ya nombró la pieza técnica: ArgoCD y Flux son operadores que corren dentro de un clúster de Kubernetes, haciendo watch continuo de un repositorio Git y aplicando cualquier diferencia automáticamente — el modelo pull-based, distinto en mecanismo (aunque no en principio) del push-based que esta guía construyó con apply.yml.

Lo que esta lección agrega es el contexto de cuándo Andes Cargo necesitaría dar ese salto. El proyecto de esta guía tiene una única función Lambda —process-shipment-manifest—, sin ningún servidor de aplicación corriendo de forma continua. Si Andes Cargo creciera hasta necesitar, por ejemplo, un servicio de API con múltiples réplicas, escalado automático según carga, y despliegues de aplicación con estrategias como blue/green o canary (nombradas, sin construir, en el Módulo 7, lección 5), Kubernetes —y con él, kubernetes-and-eks-in-production-guide— sería el siguiente paso lógico. El GitOps de esa guía no reemplazaría a apply.yml — coexistiría con él: apply.yml seguiría gestionando la infraestructura de base (el clúster de EKS en sí, las tablas, los buckets), mientras que ArgoCD gestionaría qué versión de la aplicación corre dentro de ese clúster.

   ESTE PIPELINE (push-based)              ARGOCD/FLUX (pull-based, otra guía)

   GitHub Actions EMPUJA el cambio          Un operador DENTRO del clúster
   hacia AWS (terraform apply)              hace watch de Git y JALA el cambio

   Gestiona: infraestructura de base        Gestiona: qué versión de la app corre
   (buckets, tablas, roles, funciones)      dentro del clúster (Deployments, Pods)

   Sigue siendo necesario incluso           Se agrega ENCIMA de la infraestructura
   con Kubernetes en el medio               que este pipeline ya sabe desplegar

2. SRE del propio despliegue

Ninguna lección anterior de esta guía mencionó qué pasa después de que un apply exitoso deja infraestructura corriendo en producción — el Módulo 6 cubrió qué hacer si el apply en sí sale mal (rollback con git revert), pero no qué hacer si la infraestructura, ya aplicada correctamente, empieza a fallar en producción por una razón que ningún plan podría haber anticipado: una función Lambda que empieza a agotar su memoria bajo carga real, una tabla DynamoDB que empieza a lanzar throttling porque el tráfico superó lo esperado, un bucket que recibe más tráfico del que su configuración de red tolera.

Esta es, con precisión, la disciplina de SRE (Site Reliability Engineering): definir SLI/SLO (indicadores y objetivos de nivel de servicio — por ejemplo, "el 99.9% de las invocaciones de process-shipment-manifest deben completarse en menos de 3 segundos"), tener un proceso de guardia (on-call) para cuando ese objetivo se rompe fuera de horario laboral, y escribir un postmortem sin culpa después de cada incidente real, para que el mismo error no se repita. sre-and-incident-response-guide es la guía de este ecosistema que construye esa disciplina completa — algo que el pipeline de CI/CD de esta guía hace posible (todo cambio queda registrado y es reversible) pero no reemplaza en absoluto.

3. FinOps de infraestructura

El Módulo 1 de esta guía fue explícito sobre su propio costo: act corre en Docker local, LocalStack simula AWS sin costo — el pipeline completo de esta guía cuesta $0 por diseño. Esa misma honestidad exige decir, al cerrar la guía, que una infraestructura real de Andes Cargo, corriendo contra una cuenta AWS de verdad, sí tiene un costo, y que ese costo necesita su propia disciplina de control: cuánto cuesta cada invocación de la función Lambda, cuánto cuesta el almacenamiento del bucket a medida que crece, cuánto costaría escalar el pipeline mismo si se moviera de act local a runners hospedados de GitHub con minutos facturables (una mención de awareness, no una guarda construida, que ya adelantó DISENO.md de esta guía). finops-and-cost-guardrails-guide es la guía que construye esa disciplina: presupuestos con alertas, etiquetado de costos por proyecto (el mismo tipo de tag que agregaste en la lección 3 de este módulo, CostCenter, es exactamente el tipo de dato que un sistema de FinOps real usaría para atribuir gasto), y guardrails automatizados que bloquean un apply si el costo estimado de un cambio supera un umbral.

El mapa completo del ecosistema, con Andes Cargo en el centro

                        terraform-and-iac-guide
                        (HCL, state, módulos — YA COMPLETA)
                                    │
                                    ▼
                    cicd-and-gitops-on-aws-guide (ESTA GUÍA)
                    (CI/CD de infraestructura, GitOps push-based)
                                    │
              ┌─────────────────────┼─────────────────────┐
              ▼                     ▼                     ▼
   kubernetes-and-eks-      sre-and-incident-    finops-and-cost-
   in-production-guide      response-guide       guardrails-guide
   (EKS, ArgoCD/Flux,       (SLI/SLO, on-call,    (presupuestos,
   GitOps pull-based)       postmortems)          etiquetado, alertas)
              │
              ▼
   cloud-security-and-guardrails-guide
   (OIDC real, SAST/DAST, SBOM/cosign/
   Trivy, Sentinel/OPA — Módulo 6 de esta guía)

Cuatro guías hermanas, cada una resolviendo un problema que esta guía nombra pero no construye, cada una con Andes Cargo —o el mismo tipo de sistema— como caso continuo. Ninguna de las cuatro es un "capítulo 2" obligatorio de esta guía — son caminos independientes, cada uno relevante según qué necesite crecer primero en un proyecto real: más escala de cómputo, más disciplina de incidentes, más control de costos, o más profundidad de seguridad.

Errores comunes

Pensar que hay un único orden correcto para completar las cuatro guías hermanas (conceptual). Qué pasa: alguien busca una secuencia recomendada, asumiendo que kubernetes-and-eks-in-production-guide debe venir antes que finops-and-cost-guardrails-guide, o algún orden similar. Cómo corregirlo: las cuatro son independientes entre sí — un proyecto real podría necesitar FinOps mucho antes que Kubernetes (si el costo ya es un problema pero la escala de cómputo no lo es), o seguridad de OIDC antes que SRE (si el riesgo de una credencial filtrada es más urgente que la disciplina de incidentes). La elección depende de qué necesita tu propio Andes Cargo, no de un temario fijo.

Confundir SRE con "arreglar el apply cuando falla" (conceptual, revisita el Módulo 6). Qué pasa: alguien piensa que el rollback con git revert del Módulo 6 ya cubre lo que hace SRE. Cómo corregirlo: el rollback del Módulo 6 responde a "el cambio que aplicamos estaba mal" —un problema del propio apply—; SRE responde a "el cambio que aplicamos estaba bien, pero la infraestructura, ya corriendo en producción, empezó a fallar por una razón operacional" —tráfico inesperado, un límite de servicio alcanzado, una dependencia externa caída—. Son dos problemas distintos, con dos disciplinas distintas.

Asumir que Andes Cargo "necesita" las cuatro piezas para ser un proyecto legítimo de portfolio (de expectativa). Qué pasa: alguien, al ver el mapa completo del ecosistema, siente que el proyecto de esta guía está incompleto sin las cuatro extensiones. Cómo corregirlo: un pipeline de CI/CD de infraestructura completo, probado de punta a punta con un cambio aceptado y uno rechazado, es un entregable real y defendible por sí solo — exactamente lo que la lección 8 de este módulo va a demostrar. Las cuatro guías hermanas son el camino de crecimiento, no un requisito retroactivo para que lo ya construido cuente.

Ejercicios

Ejercicio 1 — Ubica las tres piezas de esta lección en la fábrica de la analogía. Sin mirar el texto, explica con tus propias palabras qué pregunta responde cada una de las tres piezas (EKS/ArgoCD, SRE, FinOps) en la analogía de la fábrica que abrió esta lección.

Ver solución

EKS/ArgoCD responde "¿qué pasa si la demanda crece más allá de lo que esta línea puede producir?" — la pregunta de escala de cómputo. SRE responde "¿qué pasa la noche que algo se rompe y nadie lo estaba mirando?" — la pregunta de operación de incidentes en producción, después de que la infraestructura ya está corriendo. FinOps responde "¿cuánto está costando operar esta fábrica, y podría costar menos?" — la pregunta de control de costo continuo, no de una sola decisión de diseño.

Ejercicio 2 — Explica por qué el tag CostCenter de la lección 3 conecta directamente con esta lección. ¿Qué relación tiene el cambio de HCL que hiciste en la lección 3 de este módulo con la pieza de FinOps que acabas de leer?

Ver solución

El tag CostCenter = "logistics-andes" que agregaste en la lección 3 es, exactamente, el tipo de metadato que un sistema real de FinOps usaría para atribuir el costo de ese bucket específico a un área de negocio concreta —permite que una herramienta de análisis de costos de AWS agrupe el gasto por CostCenter, en vez de ver un número agregado sin ninguna forma de saber qué equipo lo generó—. Es una pieza pequeña y aislada de lo que finops-and-cost-guardrails-guide construiría a fondo: un sistema completo de presupuestos, alertas, y guardrails automáticos basados en ese mismo tipo de etiquetado.

Ejercicio 3 — Decide qué guía hermana elegirías primero para tu propio proyecto, y justifica. Sin una respuesta única correcta: si tuvieras que elegir una sola de las cuatro guías hermanas de esta lección para continuar hoy, ¿cuál elegirías, y qué necesidad concreta de un proyecto real justificaría esa elección?

Ver solución

No hay una respuesta única, pero una justificación completa debería nombrar una necesidad concreta, no una preferencia abstracta. Ejemplo: "Elegiría cloud-security-and-guardrails-guide primero, porque cualquier proyecto que vaya a tocar una cuenta AWS real necesita resolver el problema de credenciales de larga vida antes de cualquier otra cosa —es la pieza que, si se hace mal, tiene el radio de daño más amplio e inmediato—." O, en un contexto distinto: "Elegiría finops-and-cost-guardrails-guide primero, porque mi equipo ya tiene un incidente real de costo descontrolado, y necesito visibilidad antes que cualquier otra mejora." El criterio que importa es que la elección responda a una necesidad real, no a un orden fijo.

Resumen y siguiente paso

En esta lección cerraste el mapa completo de honestidad de esta guía con la tercera y última frontera: no lo que no corrió bajo act (lección 5), no la seguridad que esta guía no construyó (lección 6), sino el resto del ciclo de vida operacional que Andes Cargo todavía necesitaría en producción real — cómputo a escala con Kubernetes y GitOps pull-based, la disciplina de SRE para cuando algo falla después de un apply exitoso, y FinOps para controlar el costo continuo de la infraestructura que este pipeline despliega. Viste el mapa completo del ecosistema, con las cuatro guías hermanas como caminos independientes, no como una secuencia obligatoria.

Antes de avanzar deberías poder: explicar qué pregunta responde cada una de las tres piezas de esta lección; conectar el tag CostCenter de la lección 3 con la disciplina de FinOps; y justificar, para un proyecto real hipotético, qué guía hermana elegirías primero.

Con las tres lecciones de honestidad de frontera completas —Módulo 8, lecciones 5, 6 y 7—, la lección 8 cierra la guía completa: el repositorio entero de Andes Cargo, convertido en una pieza de portfolio que puedes defender sin dudar.

Recursos

  1. Módulo 7 de esta guía (03-gitops-for-kubernetes-argocd-and-flux.md) — el origen completo de ArgoCD/Flux y el modelo pull-based, retomado aquí en contexto de escala.
  2. Google SRE Book — Service Level Objectives — la referencia canónica de SLI/SLO, la base conceptual de la pieza de SRE de esta lección.
  3. AWS Well-Architected Framework — Cost Optimization Pillar — documentación oficial de AWS sobre optimización de costos, la base de la pieza de FinOps de esta lección.
  4. kubernetes-and-eks-in-production-guide, sre-and-incident-response-guide, finops-and-cost-guardrails-guide (NIEVA) — las tres guías hermanas que construyen, cada una de punta a punta, las piezas nombradas en esta lección.
← Anterior6. La seguridad que esta guía no construyóSiguiente →8. Proyecto final: el pipeline de Andes Cargo como entregable