Heru moderniza su plataforma fiscal en AWS/EKS con GitOps y mantiene Kubernetes siempre vigente (1.22 → 1.29)

Solución implementada

• Migró la arquitectura de Porter a una infraestructura propia en Amazon EKS multi-cuenta (dev/mgt/prod) con VPN
• Llevó toda la infraestructura a código (IaC) con Terraform
• Implementó GitOps con ArgoCD y autoscaling de nodos con Karpenter
• Optimizó el CI/CD con tests integrados y runners self-hosted
• Migró el API Gateway propio del cliente al API Gateway de AWS
• Centralizó los secrets en Vault y montó observabilidad con OpenTelemetry y service mesh
• Migró las bases de datos a Amazon Aurora, actualizó PostgreSQL y aplicó hardening de RDS, IAM y SSO
• Mantuvo el cluster siempre vigente con upgrades sostenidos de EKS (1.22 → 1.29)

Desafío de negocio

El punto de partida tenía varias trabas. Los despliegues no estaban automatizados y cualquier cambio tomaba mucho tiempo. La arquitectura corría sobre Porter, un servicio limitado que no seguía buenas prácticas, y los secrets se manejaban dentro de los charts sin versionado. El API Gateway propio del cliente no escalaba. Y faltaba lo más básico para operar con seriedad: separación de entornos y cuentas, versionado de infraestructura y control de costos.

Solución

Craftech actuó como el equipo DevOps extendido de Heru y encaró una modernización integral. El primer gran movimiento fue migrar Porter a una arquitectura propia en Amazon EKS multi-cuenta (dev/mgt/prod), con VPN y toda la infraestructura como código en Terraform. Sobre esa base se implementó GitOps con ArgoCD y autoscaling de nodos con Karpenter, y se optimizó el CI/CD con tests integrados y runners self-hosted, reduciendo el tiempo y el riesgo de cada despliegue. El API Gateway propio del cliente se migró al API Gateway de AWS para que escalara, los secrets se centralizaron en Vault y se montó observabilidad con OpenTelemetry y un service mesh. En la capa de datos, las bases se migraron a Amazon Aurora, se actualizó PostgreSQL y se aplicó hardening de RDS, IAM y SSO. A esto se sumó una línea de optimización de costos —con apagado nocturno de los entornos no productivos— y, de manera sostenida, los upgrades de EKS que mantuvieron el cluster siempre en una versión soportada de Kubernetes, del 1.22 al 1.29.

Resultados

• Despliegues con CI/CD y tests que redujeron el tiempo y el riesgo de cada cambio
• Arquitectura propia en Amazon EKS multi-cuenta, estandarizada y versionada con Terraform
• Secrets centralizados en Vault y observabilidad con OpenTelemetry
• Cluster siempre en una versión soportada de Kubernetes (1.22 → 1.29) durante más de tres años
• Reducción sostenida de costos con apagado nocturno de entornos no productivos y runners self-hosted

Trabajar con Craftech

Durante más de tres años, Craftech funcionó como una extensión del equipo de Heru, no como un proveedor externo puntual. Esa continuidad permitió no solo migrar y modernizar, sino sostener la plataforma en el tiempo: mantener el cluster siempre vigente, evolucionar las prácticas y optimizar costos de forma continua. El valor estuvo en la combinación de ejecución técnica de alto nivel y un acompañamiento estable, que dejó a Heru con una plataforma propia, estandarizada y operable por su equipo.

Tecnologías utilizadas

La plataforma se basa en Amazon EKS multi-cuenta, con Karpenter para el autoescalado y ArgoCD para el despliegue continuo bajo modelo GitOps. Toda la infraestructura se versiona con Terraform. El API Gateway de AWS expone las APIs, los secrets se gestionan con Vault y la observabilidad combina OpenTelemetry con un service mesh (Istio). La capa de datos corre sobre Amazon Aurora y Amazon RDS (PostgreSQL), con hardening de IAM y SSO. El CI/CD integra tests y runners self-hosted.

Stack & tecnologías