Ingeniero DevOps enfocado en Kubernetes, Terraform y AWS. Diseño infraestructura inmutable y pipelines de CI/CD que llevan código a producción sin dramas, sin downtime y sin intervención manual.
➜ ~ whoami
juan_vargas — devops / sre engineer
➜ ~ cat philosophy.txt
automatización total
infraestructura inmutable
alta disponibilidad por diseño
cultura SRE, no héroes de guardia
➜ ~ kubectl get self -o status
Running · restarts: 0 · uptime: siempre listo
01 · SOBRE MÍ
No veo la infraestructura como un accesorio del código, la veo como parte del producto. Mi trabajo empieza donde termina el "funciona en mi máquina": diseño la ruta completa para que un cambio pase de un pull request a estar sirviendo tráfico real de forma segura, repetible y reversible.
Cada pieza de infraestructura que provisiono queda descrita en código, versionada y auditable. Si un servidor falla, no lo reparo: lo reemplazo. Esa es la diferencia entre mantener sistemas y diseñarlos para que fallen bien.
automatización_total
Si una tarea se repite dos veces, la tercera la hace un pipeline, no una persona.
infraestructura_inmutable
Nada se parchea a mano en producción. Se reconstruye desde código y se redespliega.
alta_disponibilidad
Diseño para el fallo: multi-AZ, health checks reales y rollbacks automáticos.
cultura_sre
Menos guardias apagando incendios, más SLOs, observabilidad y postmortems sin culpables.
02 · STACK TÉCNICO
☁ Cloud
⌘ IaC
↻ CI/CD
▣ Contenedores
◎ Monitoreo
§ Otros
03 · CASOS DE ESTUDIO
No solo qué tecnología usé, sino qué problema resolví.
EN PRODUCCIÓN
Problema
Un monolito corría sobre instancias EC2 gestionadas a mano, con despliegues manuales y un único punto de fallo por zona de disponibilidad.
Arquitectura
Cluster EKS distribuido en 3 AZ, autoscaling horizontal por métricas de CPU/latencia, y corte de tráfico progresivo (canary) validado con health checks reales.
99.95%
disponibilidad
0 min
downtime en el corte
EN PRODUCCIÓN
Problema
Despliegues manuales vía SSH, sin trazabilidad de qué versión corría en cada entorno ni forma confiable de revertir un cambio problemático.
Arquitectura
Pipeline de GitHub Actions construye y firma imágenes; ArgoCD sincroniza el estado declarado en Git contra el cluster. Rollback = revertir un commit.
-70%
tiempo de despliegue
<2 min
rollback promedio
CASO DE ESTUDIO
Problema
Infraestructura creada a mano desde la consola, sin separación entre entornos (dev/staging/prod) y sin forma de auditar quién cambió qué.
Arquitectura
Módulos de Terraform reutilizables por entorno, backend remoto con state locking, y políticas IAM de mínimo privilegio por cuenta.
100%
infra como código
3
entornos aislados
04 · INFRAESTRUCTURA DE ESTE SITIO
Está desplegado con el mismo estándar que exijo en producción. Overkill para una página estática, a propósito: es la demo en vivo de cómo trabajo.
00 → provisión
Terraform
Cluster EKS, VPC y networking definidos como código, aplicados desde un backend remoto con state locking.
01 → build
GitHub Actions
Cada push a main dispara lint, build de la imagen Docker y push al registry.
02 → gitops
ArgoCD
Detecta el nuevo manifiesto en el repo y sincroniza automáticamente el estado deseado contra el cluster.
03 → runtime
Kubernetes
Pods servidos vía Ingress con TLS automático, health checks y auto-restart ante fallo.
04 → observa
Prometheus + Grafana
Métricas de uptime y latencia expuestas en un dashboard público de estado.
$ git push origin main → build → registry → argocd sync → deploy en producción
05 · CONTACTO
Abierto a proyectos de migración a la nube, diseño de pipelines CI/CD o auditorías de infraestructura. Responde el humano detrás de la terminal.