Módulo 8: Capstone Andes Cargo On Kubernetes
6. La corrección de continuidad que esta guía deja para el ecosistema
Descripción
Esta lección cierra un hilo que el Módulo 1, lección 3, y el Módulo 6, lección 1, abrieron y prometieron cerrar aquí: dos guías hermanas de este ecosistema, escritas antes de que este clúster existiera, afirman que "Andes Cargo no tiene contenedores". Esa frase era cierta cuando se escribió. Dejó de serlo el día en que este mismo laboratorio cargó andes-cargo-status-api:latest dentro de andes-cargo-cluster, en el Módulo 1. Esta lección documenta, con evidencia verificada línea por línea contra los archivos reales de esas guías, cuál corrección ya se aplicó y cuál sigue pendiente — sin editar ningún archivo fuera de esta guía.
Conexión con el módulo
Esta es, en cierto sentido, la lección menos técnica de todo el capstone —no aplica ningún manifiesto, no corre ningún comando contra kind— y al mismo tiempo la que más honra la regla dura que sostuvo las ocho guías del ecosistema aws-cloud-ecosystem: nunca dejar una premisa desactualizada sin nombrarla.
La premisa original, y por qué era cierta cuando se escribió
Hasta el Módulo 6 de aws-serverless-and-containers-guide, el caso Andes Cargo tenía un solo componente que respondía a eventos: process-shipment-manifest, un handler Lambda empaquetado en .zip, sin ninguna imagen Docker de por medio. Cuando cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide se diseñaron, la frase "Andes Cargo no tiene contenedores en este ecosistema" era una descripción exacta del estado real del caso en ese momento.
Esa foto cambió en el Módulo 6 de esa misma guía (aws-serverless-and-containers-guide): se construyó, de verdad, andes-cargo-status-api — un Dockerfile de cinco instrucciones, una imagen corrida local con docker run, publicada en un registro local. El componente en contenedor ya existía desde ese punto del ecosistema — lo único que le faltaba era un orquestador que lo corriera de verdad, algo que ni esa guía (por el límite de LocalStack Hobby con ECS) ni ninguna guía posterior resolvió hasta esta. El Módulo 1, lección 3, de esta guía ya documentó ese recap completo.
El estado real, verificado archivo por archivo, hoy
Esta lección no asume nada — verificó, contra el contenido real de cada guía hermana, si la corrección ya se aplicó o sigue pendiente.
cloud-security-and-guardrails-guide — CORREGIDA
Su capstone (Módulo 8, lección 7, "Lo que Andes Cargo todavía necesita") ya no repite la premisa vieja. Dice, palabra por palabra:
"El handler Lambda de Andes Cargo se empaqueta en
.zip, no en imagen de contenedor; el escaneo y la firma de esta guía son de artefacto de despliegue y de IaC, no de imagen. **El único componente contenerizado del caso —andes-cargo-status-api, la imagen queaws-serverless-and-containers-guideconstruyó pero nunca llegó a orquestar— recibe su runtime y su seguridad de runtime (admission control, escaneo de imagen, NetworkPolicy) enkubernetes-and-eks-in-production-guide".
Esta es, exactamente, la frase que reconoce con precisión lo que este ecosistema construyó: el .zip de Lambda sigue siendo cierto para process-shipment-manifest, y andes-cargo-status-api —el componente en contenedor— tiene, ahora, un lugar explícito donde su seguridad de runtime se construye: esta guía.
finops-and-cost-guardrails-guide — TODAVÍA NO CORREGIDA
Su capstone (Módulo 8, lección 7, la misma sección equivalente) sigue afirmando, palabra por palabra, al momento de escribir esta lección:
"La frontera, ya nombrada en el Módulo 7 de esta guía: el rightsizing de esta guía es de Lambda, DynamoDB y S3 — Andes Cargo no tiene contenedores en este ecosistema."
Esta frase sigue siendo la premisa vieja, sin corregir. No invalida el contenido de esa guía —su alcance de rightsizing (Lambda, DynamoDB, S3, sin Kubernetes) sigue siendo correcto punto por punto—, pero la premisa literal debería decir, con la misma precisión que ya logró cloud-security-and-guardrails-guide, algo equivalente a "Andes Cargo tiene un componente en contenedor (andes-cargo-status-api), cuyo rightsizing de requests/limits a nivel de Pod queda fuera del alcance de esta guía, cubierto en su lugar por kubernetes-and-eks-in-production-guide".
sre-and-incident-response-guide — TODAVÍA NO CORREGIDA
Su capstone (Módulo 8, lección 7, la misma sección) también sigue afirmando la premisa vieja, palabra por palabra:
"Andes Cargo, en todo este ecosistema, no tiene contenedores — el SLI de esta guía mide un Lambda y una API, nunca un pod."
Igual que con finops-and-cost-guardrails-guide, esto no invalida el contenido de esa guía —su disciplina de SLI/SLO/error budget sobre Lambda y API sigue siendo exactamente lo que promete—, pero la premisa debería reflejar que el componente en contenedor sí existe, con su propia disciplina de confiabilidad (que esa misma guía nombra, correctamente, como algo que aplicaría "con señales completamente distintas" si Andes Cargo migrara a Kubernetes) construida en esta guía.
La tabla de estado, en un solo lugar
| Guía hermana | Premisa "Andes Cargo no tiene contenedores" | Estado, verificado contra el archivo real |
|---|---|---|
cloud-security-and-guardrails-guide | Corregida — reconoce andes-cargo-status-api por nombre, señala hacia esta guía | ✅ Al día |
finops-and-cost-guardrails-guide | Sin corregir — repite la premisa original, palabra por palabra | ⚠️ Pendiente |
sre-and-incident-response-guide | Sin corregir — repite la premisa original, palabra por palabra | ⚠️ Pendiente |
Por qué esta lección documenta, y no corrige
Esta guía (kubernetes-and-eks-in-production-guide) tiene una regla dura, declarada desde su propio diseño: no edita ningún archivo de otra guía. Cada guía del ecosistema aws-cloud-ecosystem es responsable de su propio contenido, y el mecanismo correcto para propagar una corrección de continuidad como esta es que quien audite el ecosistema completo —no una guía individual, actuando por su cuenta— decida cuándo y cómo actualizar cada archivo. Esta lección hace exactamente lo que le corresponde: dejar la evidencia completa, verificada, en un solo lugar, para que esa auditoría no tenga que redescubrirla desde cero.
Vale la pena notar, además, que la corrección real no es simétrica en dificultad: finops-and-cost-guardrails-guide y sre-and-incident-response-guide no necesitan reescribir nada de su contenido técnico — la corrección es, en los dos casos, una frase de frontera, del mismo tamaño y precisión que la que cloud-security-and-guardrails-guide ya logró.
Analogía: la nota en el margen del plano compartido
Ocho guías de este ecosistema comparten un mismo caso —Andes Cargo—, como ocho equipos distintos trabajando sobre el mismo plano de un edificio en expansión. Cuando un equipo agrega un ala nueva al edificio (el contenedor andes-cargo-status-api, construido en aws-serverless-and-containers-guide), los planos de los otros equipos, dibujados antes de esa ampliación, quedan desactualizados en ese único detalle — no están mal hechos, simplemente no vieron la ampliación a tiempo. Esta lección es la nota que alguien deja en el margen de dos de esos planos, con lápiz, sin borrar ni redibujar nada: "esta parte del plano ya no refleja el edificio actual — revisar cuando corresponda". No es responsabilidad de quien deja la nota redibujar el plano ajeno; es responsabilidad de quien la lee, la próxima vez que abra ese plano, tomarla en cuenta.
Errores comunes
Interpretar esta lección como una crítica a finops-and-cost-guardrails-guide o sre-and-incident-response-guide (de tono). Qué pasa: alguien lee la tabla de estado y concluye que esas dos guías están "mal hechas". Cómo detectarlo: si tu reacción es "esas guías tienen un error". Cómo corregirlo: repasa la sección "Por qué esta lección documenta, y no corrige" — el contenido técnico de ambas guías (el rightsizing de Lambda/DynamoDB/S3, la disciplina de SLI/SLO sobre Lambda y API) sigue siendo completamente correcto. Lo único desactualizado es una frase de frontera, escrita en un momento del ecosistema en que era exacta, y que dejó de serlo por un desarrollo posterior de otra guía — el mismo tipo de desactualización que cualquier documentación viva acumula con el tiempo.
Asumir que esta guía debería haber corregido los archivos directamente (de urgencia mal dirigida, el mismo patrón que la lección 4 de este módulo advirtió sobre kubectl apply --force). Qué pasa: alguien pregunta por qué esta lección no simplemente edita el archivo de finops-and-cost-guardrails-guide para arreglarlo. Cómo detectarlo: si tu reacción frente a esta lección es "¿por qué no lo arreglaron ya?". Cómo corregirlo: cada guía del ecosistema es responsable de su propio contenido — la disciplina correcta, la misma que sostiene la integridad de las nueve guías completas, es documentar el hallazgo con evidencia verificable y dejar que el proceso de auditoría del ecosistema decida cuándo aplicar el cambio, no que una guía individual reescriba el contenido de otra por su cuenta.
No distinguir "premisa de frontera imprecisa" de "alcance de la guía incorrecto" (de lectura apresurada de la tabla). Qué pasa: alguien lee que dos guías tienen una premisa sin corregir y asume que sus fronteras de alcance completas están mal definidas. Cómo detectarlo: si tu resumen es "el rightsizing de FinOps no cubre lo que debería" en vez de "una frase específica de esa guía necesita actualizarse". Cómo corregirlo: la sección de cada guía citada en esta lección deja claro que el alcance en sí (Lambda/DynamoDB/S3 para FinOps; Lambda/API para SRE) sigue siendo la frontera correcta — lo único impreciso es la premisa de que "no hay contenedores en absoluto" en el ecosistema.
Ejercicios
Ejercicio 1 — Reconstruye la tabla de estado de memoria. Sin volver a esta lección, indica, para cada una de las tres guías hermanas mencionadas, si su premisa está corregida o pendiente, y con qué cita textual la verificaste.
Ver solución
cloud-security-and-guardrails-guide — corregida: su capstone nombra a andes-cargo-status-api explícitamente y señala hacia esta guía para su seguridad de runtime. finops-and-cost-guardrails-guide — pendiente: su capstone sigue diciendo "Andes Cargo no tiene contenedores en este ecosistema", sin corregir. sre-and-incident-response-guide — pendiente: su capstone sigue diciendo "Andes Cargo, en todo este ecosistema, no tiene contenedores", sin corregir.
Ejercicio 2 — Explica, en una frase, por qué esta corrección no invalida el contenido técnico de las guías pendientes. Sin copiar el texto de esta lección, explica a un colega por qué "Andes Cargo no tiene contenedores" siendo una premisa imprecisa no significa que el rightsizing de Lambda de finops-and-cost-guardrails-guide esté mal.
Ver solución
Una explicación razonable: "El alcance de esa guía —comparar PAY_PER_REQUEST contra PROVISIONED, afinar memoria de Lambda con datos reales de Infracost— nunca dependió de si Andes Cargo tenía o no un componente en contenedor; es una disciplina completa y correcta sobre los recursos que sí analiza. Lo único impreciso es la frase que describe el ecosistema completo como 'sin contenedores', que dejó de ser cierta después de que otra guía construyera uno — pero esa imprecisión vive en una sola oración de frontera, no en el trabajo técnico central de la guía."
Ejercicio 3 — Diseña la corrección exacta que aplicarías a finops-and-cost-guardrails-guide, sin editar el archivo. Basándote en cómo cloud-security-and-guardrails-guide ya resolvió esta misma corrección, escribe (en tu cuaderno, no en el archivo real) la frase de reemplazo que propondrías para la premisa de finops-and-cost-guardrails-guide.
Ver solución
Una propuesta razonable, siguiendo el mismo patrón que usó cloud-security-and-guardrails-guide: "El rightsizing de esta guía es de Lambda, DynamoDB y S3. El único componente contenerizado del caso —andes-cargo-status-api, la imagen que aws-serverless-and-containers-guide construyó pero nunca llegó a orquestar— recibe su propio rightsizing de requests/limits a nivel de Pod en kubernetes-and-eks-in-production-guide, fuera del alcance de esta guía." Esta propuesta cambia solo la premisa, sin tocar ni una palabra del contenido técnico real de esa guía — exactamente el tipo de corrección quirúrgica que esta lección describe como pendiente.
Resumen y siguiente paso
Esta lección cerró el hilo de continuidad que el Módulo 1, lección 3, y el Módulo 6, lección 1, dejaron abierto: verificó, contra el contenido real de tres guías hermanas, que cloud-security-and-guardrails-guide ya corrigió su premisa sobre "Andes Cargo no tiene contenedores", mientras que finops-and-cost-guardrails-guide y sre-and-incident-response-guide todavía la repiten, sin que eso invalide el contenido técnico de ninguna de las dos. La corrección queda documentada aquí, con cita textual verificable, para que el proceso de auditoría del ecosistema —no esta guía por su cuenta— decida cuándo aplicarla.
Antes de avanzar deberías poder: reconstruir la tabla de estado de las tres guías citadas; explicar por qué una premisa de frontera imprecisa no invalida el contenido técnico de una guía; y proponer la corrección exacta que aplicarías, sin necesitar editar ningún archivo fuera de esta guía.
Siguiente lección: lo que Andes Cargo todavía necesita. Ahí el mapa se abre hacia adelante — qué disciplinas del ecosistema aws-cloud-ecosystem ya existen, listas para quien quiera seguir construyendo sobre andes-cargo-status-api más allá de esta guía.
Recursos
cloud-security-and-guardrails-guide(NIEVA), Módulo 8, lección 7 — la corrección ya aplicada, citada textualmente en esta lección.finops-and-cost-guardrails-guide(NIEVA), Módulo 8, lección 7 — la premisa pendiente de corrección, citada textualmente en esta lección.sre-and-incident-response-guide(NIEVA), Módulo 8, lección 7 — la segunda premisa pendiente de corrección, citada textualmente en esta lección.kubernetes-and-eks-in-production-guide(NIEVA), Módulo 1, lección 3, y Módulo 6, lección 1 — los dos puntos donde esta guía prometió, por primera vez, cerrar este hilo en el capstone.