Cuando recomiendas nube privada, deberías vivir en ella
CCsolutions asesora a empresas que evalúan migrar de la nube pública a infraestructura privada. Durante más de un año, nuestro propio stack de monitoreo corría en DigitalOcean. La incoherencia era evidente. Predicábamos los beneficios de la nube privada mientras pagábamos premium por máquinas virtuales compartidas.
Este artículo documenta exactamente cómo movimos Grafana, Loki y Mimir de DigitalOcean a Hetzner Baremetal gestionado con Syself. Sin filtros de marketing. Con todos los números.
El problema con la configuración anterior
Nuestro stack en DigitalOcean tenía 6 nodos virtualizados, cada uno con 8 vCPU y 32 GB RAM. Coste mensual: aproximadamente 2.000 euros. Sobre el papel, suficiente para un equipo pequeño con un volumen moderado de logs y métricas. En la práctica, una serie de problemas operativos.
Primer dolor de cabeza: errores OOM en Loki y Mimir cada pocos días. La compactación de bloques históricos de Mimir consumía RAM por encima de los 25 GB en momentos puntuales, suficiente para activar el OOM killer. Cada reinicio significaba pérdida temporal de datos en el monitoreo, exactamente cuando más lo necesitas.
Segundo: latencia de queries. Los dashboards de Grafana con 30 días de datos cargaban en 8 a 12 segundos. Los de 90 días, 30 segundos o más. El motivo es simple. El almacenamiento por bloques sobre VMs compartidas no entrega el throughput de I/O que necesita Loki para escanear índices.
Tercero, y el más relevante para nuestra estrategia: cero control sobre el hardware subyacente. En máquinas virtuales no sabes con quién compartes el hipervisor. Tu vecino ruidoso puede consumir ancho de banda de disco en el peor momento. Para un sistema de monitoreo crítico, esa imprevisibilidad es inaceptable.
Por qué Hetzner Baremetal con Syself
Evaluamos cuatro opciones. Aumentar el plan de DigitalOcean. Migrar a AWS o GCP con instancias dedicadas. Alquilar baremetal en OVH o Hetzner. Construir un clúster propio on-premises.
Descartamos la primera porque escalaba el problema económico sin resolver la causa raíz. AWS y GCP cayeron por coste: una instancia EC2 dedicada con specs comparables sale al doble del precio. On-premises requiere personal de datacenter que no tenemos.
Hetzner Baremetal ganó por una combinación rara: precio bajo, hardware moderno, datacenters europeos con baja latencia hacia DACH y LATAM, y APIs aceptables para automatización.
El segundo problema era el plano de control de Kubernetes. Bootstrap manual con kubeadm es factible, pero los upgrades del control plane y la operación diaria consumen tiempo del equipo. Aquí entró Syself, un proveedor que se encarga del clúster Kubernetes sobre hardware ajeno. Pagas la gestión del control plane y mantienes el control total sobre los workers y los datos.
Hardware y arquitectura final
Cuatro nodos baremetal en Hetzner. Specs por nodo:
- AMD Ryzen, 16 cores físicos
- 64 GB RAM DDR4 ECC
- 1 TB NVMe SSD
Capacidad total del clúster: 64 cores físicos, 256 GB RAM, 4 TB de almacenamiento NVMe local.
El plano de control de Kubernetes lo gestiona Syself en su propia infraestructura. Los 4 nodos son workers donde corre todo el stack: Grafana para visualización, Loki para agregación de logs, Mimir para métricas a largo plazo, y los agentes de cada uno (Promtail, Grafana Agent).
El almacenamiento es el cambio fundamental. En la versión anterior dependíamos de los block volumes de DigitalOcean. Ahora tenemos NVMe local en cada worker. Para Loki y Mimir, que son sensibles a I/O, el efecto es directo. Las queries que antes tardaban segundos ahora se ejecutan en milisegundos.
El proceso de migración
La migración duró tres semanas, sin downtime en el monitoreo. Los pasos relevantes:
Semana 1: Provisión y validación. Aprovisionamos los 4 nodos en Hetzner, los conectamos al control plane de Syself, configuramos networking y storage. Validamos que el clúster pasaba los tests básicos de Kubernetes (e2e tests) antes de tocar workloads productivos.
Semana 2: Replicación de datos. Configuramos Mimir y Loki en el nuevo clúster apuntando al mismo bucket S3 que el clúster antiguo. Ambos clústeres escribieron a la misma fuente de datos durante varios días para garantizar consistencia. Grafana se configuró con datasources en paralelo.
Semana 3: Cambio de tráfico. Apuntamos los agentes de los entornos productivos al nuevo clúster. Verificamos que los dashboards funcionaban idénticamente. Mantuvimos el clúster antiguo durante 5 días adicionales como red de seguridad. Después, terminación.
Cero pérdida de datos, cero ventanas de mantenimiento, cero llamadas a las 3 AM.
Resultados, con números reales
Después de tres meses de operación productiva:
| Métrica | Antes (DigitalOcean) | Después (Hetzner) | Cambio | |---|---|---|---| | Coste mensual | ~2.000 EUR | ~1.000 a 1.100 EUR | 40 a 50% menos | | CPU cores totales | 48 vCPU | 64 cores físicos | 33% más | | RAM total | 192 GB | 256 GB | 33% más | | Errores OOM | Cada 2 a 3 días | Cero en 90 días | Eliminados | | Latencia query 30d | 8 a 12s | < 1s | 10x más rápido | | Latencia query 90d | 30s+ | 2 a 3s | 10x más rápido |
El ahorro real es mayor que el 40% nominal porque no estamos comparando capacidad equivalente. Estamos pagando menos por más recursos. La diferencia entre vCPU virtualizadas con shared tenancy y cores físicos dedicados también importa. Las picos de Mimir ya no compiten con cargas desconocidas.
Lo que aprendimos
Tres conclusiones que llevamos a proyectos de clientes.
El ahorro de coste es real, pero la consistencia operativa importa más. El monitoreo es la primera infraestructura que un equipo de SRE necesita estable. Si tu Grafana cae mientras debugeas una incidencia, multiplicaste el problema. Cero errores OOM en 90 días vale más que el 40% de ahorro.
El I/O es el cuello de botella oculto. En la mayoría de stacks que evaluamos, el bottleneck no es CPU o RAM, sino el throughput de almacenamiento. NVMe local elimina ese problema. Si tus workloads son sensibles a disco (bases de datos, sistemas de logs, sistemas de métricas), considera baremetal antes que VMs.
Kubernetes managed sobre hardware propio es un sweet spot poco explotado. La mayoría de equipos eligen entre managed completo (EKS, AKS, GKE) o self-hosted completo. La opción intermedia, control plane gestionado y workers propios, combina lo mejor de ambos. Simplicidad operativa sin perder soberanía sobre el dato.
Conclusión
Migrar nuestro propio monitoreo no fue un proyecto de cliente. Fue una validación de la tesis que vendemos. Si recomendamos nube privada a clientes con cargas sensibles a coste o compliance, queremos haber hecho ese mismo viaje primero, con todos sus errores y aprendizajes.
Si estás evaluando una migración similar y quieres hablar de los detalles que no entran en un blog post (configuración exacta de Mimir, costos de transferencia de datos, opciones de proveedores en LATAM), agenda una llamada gratuita de 45 minutos. Compartimos lo que sabemos.
Co-fundador de CCsolutions. Más de una década construyendo infraestructura para sectores regulados (finanzas, salud, energía). Especializado en Kubernetes, FinOps y arquitecturas de IA privada. Escribe sobre lo que funciona y lo que no, con números reales.
Más sobre nosotros