Cómo migrar de dependencias US SaaS a alternativas self‑hosted y EU cloud

Problema

Muchas startups y equipos de producto inician sus proyectos en plataformas populares de EE. UU. (Google Cloud, GitHub, Cloudflare, etc.) porque la curva de aprendizaje es baja y la infraestructura está lista para escalar. Con el tiempo, esa comodidad se convierte en dependencia: bases de datos, CI, DNS, mensajería y autenticación quedan atadas a APIs propietarias, a facturación en dólares y a políticas de privacidad que no siempre alinean con requisitos de soberanía de datos. Cuando el negocio necesita cambiar de jurisdicción, reducir costos o evitar lock‑in, la migración se vuelve una tarea enorme que suele aparecer como “un montón de servicios que hay que reemplazar”.

El patrón recurrente es una arquitectura híbrida donde la mayor parte del código está bajo control propio, pero la capa de servicios externos está dispersa entre varios proveedores estadounidenses. Cada servicio tiene su propio flujo de autenticación, webhook y modelo de datos, lo que complica la sustitución rápida y segura.

Causa

1. Elección por familiaridad – Los equipos optan por la solución que ya conocen (p.ej. GCP) sin evaluar alternativas locales.
2. Lock‑in implícito – APIs propietarias y SDKs se integran profundamente en el código; la refactorización requiere tiempo y pruebas.
3. Falta de auditoría de dependencias – No existe un inventario actualizado de qué servicio cubre cada funcionalidad (CI, DNS, base de datos, etc.).
4. Políticas de datos – Regulaciones como GDPR obligan a almacenar datos en la UE; los proveedores estadounidenses pueden no ofrecer garantías suficientes.
5. Costos ocultos – Facturación por uso, tráfico saliente y licencias pueden escalar inesperadamente, empujando a buscar opciones más predecibles.

Solución

Una migración exitosa se basa en tres pilares: inventario, alternativa y automatización. El proceso es reutilizable para cualquier stack que dependa de SaaS externos.

1. Inventario estructurado

• Mapeo de servicios: crea una tabla con columnas → Servicio, Función, API/SDK, Datos críticos, Facturación, Región actual.
• Clasificación de criticidad: alta (auth, base de datos), media (CI, monitoring), baja (notificaciones).
• Identificación de sustitutos: para cada fila busca una alternativa self‑hosted o EU‑cloud que cubra la misma función. Prioriza proyectos con comunidad activa y soporte Docker/K8s.

Ejemplo de fila:

2. Selección de alternativas

3. Automatización con IaC

Una vez definido el nuevo stack, codifícalo con Terraform, Ansible o Pulumi. Mantén la infraestructura declarativa para que la reversión o replicación sea trivial.

Paso a paso

1. Provisionar VMs o bare metal – Usa Hetzner Cloud o Scaleway para máquinas Linux.
2. Desplegar contenedores – Docker Compose o Helm charts para cada servicio (Forgejo, Drone, Authelia, etc.).
3. Configurar red y DNS – Crea zonas en PowerDNS, apunta los registros a las nuevas IPs.
4. Migrar datos – Exporta bases de datos (pg_dump) y repositorios (git clone –mirror) hacia los nuevos hosts.
5. Actualizar pipelines – Cambia URLs de repositorios y variables de entorno en los scripts CI.
6. Desactivar servicios antiguos – Una vez verificado, elimina recursos en GCP, Cloudflare, etc.

4. Pruebas y validación

• Entorno staging: replica la producción en una zona separada y ejecuta pruebas de integración.
• Smoke tests: verifica que los webhooks, CI jobs y despliegues siguen funcionando.
• Auditoría de logs: revisa que no queden llamadas a APIs externas.

Cuándo aplicar esta solución

Señales de que la migración es pertinente

• Necesidad de cumplir con GDPR o regulaciones locales.
• Creciente factura en servicios US y falta de previsibilidad de costos.
• Dependencia de APIs que impiden despliegues offline o en zonas aisladas.
• Requerimientos de alta disponibilidad en regiones europeas.

Escenarios donde no aplica

• Aplicaciones que dependen de características exclusivas de un proveedor (p.ej. BigQuery) sin equivalente viable.
• Equipos sin capacidad para mantener infraestructura propia (recursos humanos limitados).

Código

# Terraform: crear una instancia Hetzner para Forgejo
terraform init
terraform apply -var 'hcloud_token=YOUR_TOKEN' -auto-approve

# Docker Compose: lanzar Forgejo y Authelia en la misma red
cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:latest
    restart: always
    environment:
      - USER_UID=1000
      - USER_GID=1000
    volumes:
      - forgejo-data:/var/lib/forgejo
    ports:
      - "3000:3000"
  authelia:
    image: authelia/authelia:latest
    restart: always
    volumes:
      - authelia-config:/config
    ports:
      - "9091:9091"
volumes:
  forgejo-data:
  authelia-config:
EOF

docker compose up -d

Verificación

1. Acceso HTTP – Navega a http://<IP>:3000 y verifica que Forgejo muestra la página de login.
2. Clone de repositorio – En una máquina cliente:

   git clone http://<IP>:3000/username/repo.git
   

   Confirma que el historial está completo.
3. Pipeline CI – Ejecuta un job en Drone que haga git push al nuevo remoto; revisa que el build pasa sin errores.
4. DNS – Usa dig para comprobar que los registros A apuntan a la IP de Hetzner y que la zona en PowerDNS responde correctamente.
5. Auditoría de tráfico – Con tcpdump o logs de firewall verifica que no haya llamadas salientes a github.com, cloudflare.com u otros endpoints antiguos.

Notas adicionales

• Backup: configura snapshots automáticos en Hetzner y exporta bases de datos diariamente con pg_dump.
• TLS: Let’s Encrypt sigue siendo la opción más sencilla; si necesitas una autoridad europea, considera ZeroSSL o Buypass.
• Monitoreo: Prometheus + Grafana pueden desplegarse junto a los servicios para observar latencias y errores.
• Escalado: Si la carga crece, migra los contenedores a Kubernetes (k3s) en los mismos nodos para obtener auto‑escalado sin cambiar proveedores.
• Licencias: verifica que las alternativas elegidas tengan licencias compatibles con tu modelo de negocio (MIT, Apache 2.0, etc.).

Con un inventario claro, alternativas bien evaluadas y la infraestructura declarada como código, la sustitución de dependencias US SaaS se vuelve un proyecto de días, no de meses. La clave está en tratar cada servicio como un componente reemplazable y automatizar tanto el despliegue como la migración de datos.