5 servicios
Código, contenedores, pruebas unitarias, métricas y flujo E2E documentado.
DOCKET / AWS.
Microservicios y entrega GitOps sobre AWS
Caso DevOps colaborativo que conecta cinco servicios, pipelines CI, imágenes inmutables, Terraform modular, Amazon EKS, Gateway API y reconciliación con Argo CD.
01 / CONTEXTO
Proyecto académico/técnico de modernización DevOps para una aplicación de tareas distribuida en cinco servicios y un worker orientado a eventos.
02 / EL RETO
Convertir servicios heredados y heterogéneos en una plataforma reproducible, observable y trazable, sin confundir configuración declarada con operación comprobada.
03 / LA SOLUCIÓN
CI por repositorio, publicación versionada en ECR, infraestructura AWS con Terraform, workloads Kubernetes separados por namespace y GitOps por ambiente con Argo CD.
04 / MI TRABAJO
El material demuestra trabajo colaborativo en automatización CI, IaC, manifiestos GitOps, instrumentación y pruebas. Las fuentes no permiten atribuir individualmente cada pieza, por lo que no se reclama autoría exclusiva.
05 / PUNTOS CLAVE
- 5 servicios con CI y métricas
- DEV históricamente validado en EKS y Argo CD
- 4 diagramas reconstruidos desde código y manifiestos
TRANSPARENCIA
DEV figura como desplegado y validado históricamente en los registros del repositorio. Observabilidad, staging y producción se presentan según su evidencia real: configurados o documentados, no verificados como activos.
01 / ESTADO DE EVIDENCIA
Lo construido, lo validado y lo que quedó pendiente.
La lectura conjunta de código, pruebas, Terraform y manifiestos permite separar la implementación real de la evidencia histórica y de los planes que no llegaron a validarse.
DEV
EKS, Argo CD, workloads, imágenes inmutables y Gateway constan como validados en el registro del repositorio.
OBSERVABILIDAD
Prometheus, Grafana, ServiceMonitors y dashboards están declarados; el acta de validación quedó vacía.
STAGING + PROD
Existen manifiestos y promoción documentada, pero los clústeres y rollouts no tienen evidencia de ejecución.
02 / SISTEMA
Cinco servicios, una ruta pública y límites explícitos.
El frontend es la única entrada de aplicación. Autenticación, usuarios, tareas, Redis y el worker permanecen como servicios internos; los eventos de tareas viajan por Pub/Sub.
Vue / Node
Frontend
Interfaz y proxy de las rutas /login y /todos.
Go / Echo
Auth API
Valida credenciales, consulta Users y emite JWT HS256.
Spring Boot
Users API
Expone perfiles y valida el JWT compartido.
Node / Express
Todos API
CRUD autenticado, memoria de proceso y publicación de eventos.
Python
Log processor
Consume eventos Redis, registra el procesamiento y expone métricas.
03 / ARQUITECTURA RECONSTRUIDA
Del repositorio a una lectura visual.
Diagramas originales reconstruidos desde código y configuración. Las líneas sólidas representan implementación declarada; las discontinuas distinguen estrategia o integración no validada.
Arquitectura de microservicios
Rutas y dependencias verificadas en el código de los cinco servicios y en los Deployments/Services de DEV.
Infraestructura AWS
VPC, subredes privadas, EKS, ECR, OIDC/IRSA y la frontera entre Terraform y GitOps.
CI/CD + GitOps
Pruebas y build por repositorio, publicación reutilizable a ECR y reconciliación por ambiente.
Observabilidad
Métricas Prometheus implementadas, ServiceMonitors y dashboards declarados; validación live no registrada.
04 / AWS + TERRAFORM
La plataforma separó cloud, clúster y estado deseado.
Terraform compone módulos versionados para red, EKS y ECR. Un estado separado administra recursos dentro del clúster —namespaces, Gateway API y AWS Load Balancer Controller— mientras Argo CD conserva los workloads.
Subredes privadas y públicas, NAT y etiquetas requeridas por EKS/LB.
Clúster administrado, node groups, add-ons y entradas de acceso.
Cinco repositorios con referencias de imagen versionadas e inmutables.
GitHub OIDC evita claves persistentes; IRSA limita el controlador de carga.
Una frontera operativa deliberada
Terraform posee AWS, namespaces y controladores de plataforma. GitOps posee Deployments, Services, Gateway, HTTPRoutes y versiones de imagen. Esa separación reduce cambios manuales y mantiene trazabilidad.
cloud/ network · eks · ecr · iamplatform/ namespaces · gateway controllergitops/ workloads · routes · image tags
05 / GATEWAY + SEGURIDAD
Un ALB compartido; APIs internas por defecto.
EXPOSICIÓN
Gateway API dirige / al frontend. El proxy del frontend resuelve /login y /todos; Users, Redis y el worker no se publican directamente.
IDENTIDAD CLOUD
OIDC para CI, roles de IAM de mínimo alcance e IRSA para AWS Load Balancer Controller están definidos en Terraform.
CONTROL KUBERNETES
RBAC declara grupos de lectura y administración. Los secretos JWT quedan fuera de Git y deben aprovisionarse por ambiente.
RIESGO DOCUMENTADO
El pentest histórico confirmó deuda en credenciales, rate limiting y dependencias antiguas. El secreto débil fue rechazado en el retest de DEV.
*La publicación omite cuentas, hosts, secretos, credenciales de prueba y pasos explotables. TLS con certificado público, rate limiting y modernización de dependencias permanecieron pendientes.
06 / CI/CD + GITOPS
Construir una vez. Promover por referencia.
Cada servicio tiene un workflow que prueba y verifica su imagen. En main delega la publicación a un workflow reutilizable con OIDC. GitOps fija el tag completo y Argo CD reconcilia el ambiente.
- 01Código
- 02Lint + test
- 03Docker check
- 04Imagen ECR
- 05Manifest PR
- 06Argo CD
CI funcional
Los cinco repositorios contienen workflows, reportes de cobertura y release reutilizable; los changelogs registran releases.
DEV validado históricamente
El repositorio registra sincronización, self-heal, workloads saludables e imágenes inmutables en el clúster DEV.
Promoción documentada
Staging automatiza sync; producción exige sync manual según los manifiestos actuales. No se afirma ejecución de esos ambientes.
07 / OBSERVABILIDAD
Instrumentación implementada; operación incompleta.
Los cinco servicios exponen métricas HTTP o de worker. ServiceMonitors, Prometheus, Grafana, dashboards y Kubecost están declarados como código, pero el checklist de validación live no fue diligenciado.
08 / CALIDAD
Pruebas con alcance y límites visibles.
El reporte fechado del proyecto conserva resultados reproducibles sin convertirlos en métricas de producción.
E2E crítico
PASS documentadoLogin → crear tarea → listar → actualizar estado.
Todos API
8 pruebas100% líneas/funciones y 87,5% ramas en la verificación local registrada.
Auth + worker
PASS57,5% y 56% de statements respectivamente.
Límite
Sin navegador realNo cubrió persistencia, concurrencia ni durabilidad de Redis Pub/Sub.
09 / FASES HISTÓRICAS
Una evolución que no conviene mezclar.
Aplicación de referencia
Microservicios heredados con runtimes antiguos, autenticación compartida y trazas Zipkin.
Entrega y plataforma
CI por servicio, ECR, Terraform modular, clúster DEV, GitOps y Gateway documentados.
Pruebas y seguridad
E2E local, DAST contra DEV y registro de riesgos y remediaciones parciales.
Operación madura
Persistencia, alertas, staging/prod, TLS público, rate limiting y actualización de dependencias.
10 / DECISIONES
Decisiones técnicas con costo explícito.
Gateway API sobre Ingress
Concentra una entrada ALB y mantiene los servicios como ClusterIP, a cambio de operar CRDs y controlador AWS.
Imágenes inmutables
Evita latest y hace auditable cada rollout; exige promoción explícita del mismo artefacto.
Git como fuente de verdad
Prune y self-heal reducen drift en DEV/staging; producción conserva aprobación manual.
Redis Pub/Sub
Simplifica el desacoplamiento del worker, pero no ofrece durabilidad después de una interrupción.
11 / CONTRIBUCIÓN + APRENDIZAJES
Evidencia colectiva, aprendizaje demostrable.
Los repositorios prueban trabajo colaborativo en modernización DevOps: automatización CI, Terraform modular, manifiestos GitOps, exposición controlada, instrumentación y pruebas integradas. Sin una atribución documental por persona, este caso no reclama autoría exclusiva de esas piezas.
Separar control planes
Cloud, plataforma y aplicaciones evolucionan mejor cuando cada repositorio tiene ownership claro.
La configuración no equivale a operación
Un dashboard o manifiesto completo sigue necesitando evidencia de reconciliación y datos reales.
La deuda también es evidencia
Documentar límites de seguridad y persistencia hace el caso más útil que ocultarlos.
BACKLOG / EVIDENCE GAP
Pendientes verificables
- Activar y validar observabilidad con datos no vacíos
- Provisionar y demostrar staging y producción
- Modernizar runtimes y dependencias vulnerables
- Añadir rate limiting, credenciales seguras y TLS público
- Persistir tareas y adoptar mensajería durable
Fuentes: código de los cinco servicios, workflows CI, módulos Terraform, manifiestos Kubernetes/Argo CD y documentación técnica del repositorio. Estado observado en archivos locales; no se consultó ni modificó infraestructura activa.
05 / CONTACTO
DISPONIBLE PARA CONVERSAR
TU IDEA.
NUESTRO SIGUIENTE
PROYECTO.
¿Tienes un producto por construir o buscas a alguien para tu equipo? Conversemos.