- Al migrar de AWS y DigitalOcean a Hetzner, se redujeron los costos de la nube en 76% y la capacidad de recursos aumentó 3 veces
- Antes se usaban en paralelo ambos servicios en la nube, apoyándose en la estabilidad de AWS y la simplicidad de DigitalOcean
- Tras agotarse los créditos gratuitos, surgió una carga operativa de más de $449 al mes, lo que llevó a buscar alternativas como Hetzner
- Para reducir costos, se construyó un stack de nube autogestionado combinando Kubernetes basado en Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS y cert-manager, entre otros
- Con los servidores ARM de vCPU compartida y el almacenamiento compatible con S3 de Hetzner, se logró una gran ampliación de recursos manteniendo rendimiento y estabilidad
- La facilidad de administración disminuye un poco, pero como nube alternativa dentro de Europa ofrece una excelente eficiencia en costo y rendimiento
Contexto
- Todo el software desarrollado por DigitalSociety funciona sobre una base en la nube
- Antes de la migración, la infraestructura principal operaba tanto en AWS (servicios principales y gestión de autenticación, correo, etc.) como en DigitalOcean (servicios ligeros, monitoreo y Kubernetes)
- AWS fue elegido por la familiaridad de más de 15 años de uso y su alta estabilidad de API
- DigitalOcean fue elegido por su entorno sencillo de Kubernetes, su control plane gratuito y su eficiencia en costos
- Al principio solo se usaba DigitalOcean, pero para un SaaS intensivo en datos como tap se necesitaban muchos recursos y créditos adicionales, por lo que se aprovechó el crédito para startups de AWS ($1,000)
Fin de los créditos y presión de costos
- Gracias a Fargate de AWS (ejecución serverless de contenedores), al inicio fue posible montar la infraestructura a bajo costo, pero por la naturaleza intensiva en datos del servicio tap, para mantener el rendimiento se requerían como mínimo 2x CPU y 4 GiB de RAM
- En Fargate, un contenedor con esas especificaciones costaba más de $70 al mes, y al sumar dos instancias worker y otra infraestructura, el total subía hasta $449.50 mensuales
- Los créditos gratuitos proporcionados se agotaron en menos de 6 meses, y para una startup autofinanciada eso se convirtió en una pesada carga de costos fijos
Proceso de búsqueda de alternativas
- Para reducir los altos costos operativos y ganar independencia tecnológica, se buscaron proveedores de nube con base en Reino Unido/UE
- La competitividad de precios de Hetzner resultó muy atractiva, y pese a la complejidad operativa de un entorno VPS autogestionado, se decidió migrar tanto desde AWS como desde DigitalOcean
- Como la mayoría de los servicios ya corrían sobre Kubernetes, y Talos Linux facilita la creación del clúster, también se montó un clúster propio de Kubernetes en Hetzner
- Aunque ya no estaban disponibles los servicios Managed DB de AWS o DigitalOcean, con CloudNativePG se integró y gestionó de forma segura un clúster de PostgreSQL dentro de Kubernetes, incluyendo monitoreo, respaldos y respuesta ante fallas
Nuevo stack de infraestructura
- Hetzner: uso de servidores ARM, block storage, balanceadores de carga, red, firewall y almacenamiento de objetos compatible con S3
- Talos Linux: automatización operativa mediante la gestión de nodos Kubernetes con configuración declarativa
- CloudNativePG: soporte integrado para declarar clústeres de base de datos en manifiestos de Kubernetes, con respaldo automático y recuperación ante fallas
- Ingress NGINX Controller: gestión unificada del enrutamiento HTTP dentro del clúster
- ExternalDNS: integración automática de DNS con los recursos de ingress
- cert-manager: emisión automática de certificados TLS para HTTPS
- Toda la infraestructura fue definida como código con Terraform y Helm, y el despliegue automático mediante GitHub Actions permitió una práctica DevOps
Comparación de costos
- Costo mensual antes de la migración: AWS + DigitalOcean = $559.36
- Costo mensual después de la migración: Hetzner = $132.96 (−76%)
- Aumento de recursos:
- CPU: 12 vCPU → 44 vCPU (+367%)
- RAM: 24 GiB → 88 GiB (+367%)
- Aunque los recursos aumentaron, el costo mensual total quedó muy por debajo
Retos y prueba y error durante la migración
- Las network zones de Hetzner no son exactamente iguales a las Availability Zones de AWS
- En AWS, una región tiene varias Availability Zones y el private networking está ampliamente conectado a nivel de región
- En Hetzner, bajo una sola network zone (
eu-central) existen varias ubicaciones, y la latencia de red entre ellas es alta
- En la práctica, el monitoreo mostró que al distribuir la carga entre varias ubicaciones surgían problemas como degradación del rendimiento
- Como alternativa, se usó un Placement Group dentro de una sola ubicación (Núremberg) para lograr resiliencia ante fallas mediante la dispersión física de los servidores
- Incluso con servicios basados en contenedores, la portabilidad no fue sencilla
- Al mover el entorno de AWS ECS a Kubernetes, la modificación de scripts de automatización de toda la configuración (en especial el despliegue de archivos de config) tomó más tiempo del esperado
- Al final, se mejoró el esquema de integración de configuraciones sensibles y la gestión de archivos de config con Kustomize, aumentando la trazabilidad y la facilidad de revisión
Conclusión
- Hetzner no es un servicio administrado sencillo, pero es una opción muy eficiente para equipos capaces de autogestionarse
- La operación propia permite mantener el control sobre la configuración detallada y al mismo tiempo maximizar el rendimiento por costo
- Con este enfoque, se sentaron las bases para seguir desarrollando y operando el SaaS intensivo en datos tap con costos razonables y rendimiento estable
1 comentarios
Opiniones de Hacker News
Quiero enfatizar lo enorme que es la mejora de rendimiento que se siente al desplegar directamente sobre bare metal. En nuestro servicio, el rendimiento se duplicó y además mostró una performance estable y predecible. Hay varias razones:
Baja latencia: al administrar la red directamente, no compartes la compleja red de un gran centro de datos, así que la latencia se reduce más de 10 veces
Optimización de caché: con un despliegue optimizado para el hardware, se puede aprovechar de verdad el rendimiento real de los CPUs modernos
Uso de NVMe dedicado: la velocidad de I/O en disco es increíble
Otra ventaja es que casi deja de hacer falta un autoscaler. Por el mismo precio, el hardware rinde 10 veces más y además es 2 veces más rápido, así que tiene más sentido operar a tamaño completo. Todo el sistema es estable y más fácil de administrar
Tampoco hay que preocuparse por los cargos de S3. Basta con poner un SSD NVMe de 15 TB en cada servidor y correr un clúster de MinIO/garage. Nosotros estamos procesando 20 GiB por segundo y 50 mil llamadas de API por segundo en un clúster de 10 nodos. Si fuera S3, solo las llamadas de API costarían entre $20 y $250 por segundo, una diferencia brutal
Solo llega una tarifa fija mensual
Y además tienes almacenamiento rápido y barato, puedes operar grandes instancias de PostgreSQL a bajo costo, y se reducen muchísimo las limitaciones y dolores de cabeza que se sienten en la nube
Incluso invirtiendo en una estructura así, el costo sigue siendo una décima parte de AWS
Si administrarlo tú mismo te resulta pesado, nosotros (https://lithus.eu) lo administramos por ti a la mitad del precio de AWS y también damos soporte DevOps. Contacto: adam@, consulta el dominio
Contexto técnico: bare metal es ejecutar directamente sobre servidores físicos reales, no sobre virtualización (VM)
De verdad quisiera dejar atrás esa vieja época de “solo agrega más máquinas y será más rápido” y “el costo no importa”. En mi carrera, durante la época de .NET, vi sistemas aguantar millones de usuarios con un solo servidor en un gabinete. Luego me cambié a una empresa que usaba nube, contenedores y microservicios en Node, y viví a diario el caos de las facturas y los problemas de rendimiento; todavía me da escalofríos a veces
Parece que los cambios siempre se repiten. Si veo nuestra empresa, da la impresión de que no subirse a cada tecnología nueva es, paradójicamente, estar al frente de la ola de nube local/edge/IDC interno
Usar la API de S3 se siente como pelar cebollas. Mientras más la usas, más lágrimas te saca
Con bare metal necesitas personal dedicado para administrar la red, la seguridad, el monitoreo, los parches y las actualizaciones. Ese costo de especialistas solo es eficiente a partir de cierta escala. Por eso, para PyMEs, la nube sigue siendo mejor en seguridad y costos operativos
Incluso en AWS, la propia documentación admite que el criterio de asignación de 1 vCPU en Lambda en realidad entrega como un 50%. La proporción mejora al subir memoria y CPU asignadas, pero no significa que siempre te den 100% del rendimiento
Desde hace tiempo pienso que con servidores dedicados se puede maximizar muchísimo la eficiencia. Opero algunos nodos en Hetzner y, aunque alquiles servidores viejos de 3 años por subasta, el rendimiento está en otra categoría comparado con una VM. El hardware de servidor suele estar optimizado por cantidad de cores e I/O, y la mayoría de las nubes sobreasignan el hardware. Incluso con el I/O de disco hacen toda clase de trucos, como montar sobre NAS y emular disco local. La mayoría de las startups no necesita esa virtualización excesiva ni discos basados en NAS. Más bien, alquilar servidores en un lugar como Hetzner te deja llegar mucho más lejos por mucho menos dinero. Me interesa saber qué proveedores en Norteamérica, especialmente Canadá, ofrecen precio/calidad al nivel de Hetzner. Ya conozco OVH, pero si alguien sabe de otros similares, sería bueno saberlo
Parece que mucha gente cree que hay que copiar de inmediato la arquitectura técnica de Google o Facebook. Nosotros operamos modestamente usando VPS europeos. Pero cada vez que entra alguien nuevo a la empresa —de negocio o de desarrollo— dice que hay que arrancar un proyecto de migración a la nube. Siempre termino explicando algo como: “ya usamos nube; no voy a dejarte hacer un proyecto de migración a la nube solo para adornar tu currículum”
Tengo benchmarks reales comparando rendimiento de CPU entre nube y servidores bare metal, por si sirve de referencia https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12
Un sitio que encontré hace poco quizá ayude: https://vpspricetracker.com. El concepto es muy llamativo. La mayoría de los proveedores listados ahí también ofrece servidores dedicados
Si te sirve “calidad tipo Hetzner dentro de EE. UU., aunque no sea una marca local”, el propio Hetzner tiene 2 centros de datos en Estados Unidos
Como referencia en Canadá, algunos proveedores a revisar son https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/
Nosotros también estamos viendo la misma tendencia. Muchos equipos se mudan a Hetzner y se sorprenden con la relación precio/rendimiento, pero luego se dan cuenta de que tienen que volver a construir toda la operación de Postgres: backups, failover, monitoreo, etc. Por eso construimos un Postgres administrado que corre directamente sobre Hetzner. Mantiene la misma estructura optimizada para hardware, pero además incluye alta disponibilidad (HA), backups y recuperación a un punto en el tiempo (PITR). Es open source, corre cerca del hardware y no tiene las trampas ocultas típicas de AWS, como cargos por I/O o egreso de datos. Si te interesa, revisa el blog 1, 2
Por razones como esta, yo sí le veo mucho atractivo a Big Cloud, especialmente al PaaS y al SQL administrado (y también los equipos de desarrollo a los que asesoro). Aunque no tengas mucha experiencia operativa, la adopción da tranquilidad porque cosas como backup/recuperación de base de datos, parches, restricción de accesos, gestión de puertos, detección de anomalías y respuesta a ataques DoS se resuelven de forma automática. Tanto política como técnicamente, usar un proveedor de nube popular también da cierta seguridad psicológica
Si tienes problemas con tu versión auto-configurada y autoadministrada de Postgres, quizá te sirva https://www.elephant-shed.io/
Es curioso cómo este tipo de artículos o comentarios casi nunca da contexto para el consejo. No es lo mismo operar un boletín parroquial en tu tiempo libre que un SaaS empresarial de altísimo tráfico con clientes en todo el mundo. Sin explicar tu propio entorno, los consejos sobre precio, rendimiento o disponibilidad son prácticamente inútiles. Una de las razones por las que la infraestructura web se volvió demasiado compleja es que personas con necesidades totalmente distintas terminan copiando los consejos unas de otras
Sumando a mi idea de que “seguir consejos sin sentido crítico cuando los requisitos son distintos solo complica más la realidad”: en algunas empresas, el account manager de la nube se sienta a almorzar con ejecutivos C-level y termina impulsando el uso de AWS. En ese proceso, un arquitecto de AWS llega a trabajar directamente con nuestro equipo y, naturalmente, solo recomienda las opciones serverless más caras. Pero en la práctica igual acabas redeployando imágenes de Docker OS todo el tiempo y administrando sin parar, igual que con los parches de un servidor bare metal normal
Incluso mi Pastebin personal no aguantaría sin bare metal (broma)
Este es un ejemplo muy típico de cómo funciona la industria de TI
Los requisitos, el nivel técnico, la estructura de costos y el dominio del problema son completamente distintos. Hetzner y AWS superficialmente se parecen porque ambos son “nube”, pero en realidad son servicios totalmente diferentes. Lo digo como alguien que ha usado ambos
Totalmente de acuerdo. También dejé mi opinión en un blog, por si sirve https://news.ycombinator.com/item?id=45616366. El resumen sería: “entiende a los proveedores de hosting con una escala de precios desde DIY hasta enterprise, y si no lo necesitas (YAGNI), mejor ni lo elijas”
Llevo más de 10 años operando un SaaS sobre Hetzner. Hardware completamente dedicado, clústeres en centros de datos de Alemania y Finlandia, administrados con ansible. Para la conexión VPN entre servidores uso vpncloud (ese software es realmente excelente). El costo mensual de hosting es bajísimo comparado con AWS y similares, y los servidores son mucho más rápidos. La estructura es simple y basta con pocos servidores. Cuando hace falta, solo añadimos más servidores; al ser bare metal, no escalas en minutos, pero sí con algo de planeación en horas o días. La base de datos está en una estructura distribuida con RethinkDB (pronto migraremos a FoundationDB) para tolerancia a fallos
Yo también opero algo parecido con una combinación de rethinkdb. Pero me da curiosidad por qué elegiste FoundationDB. RethinkDB sigue en mantenimiento y de vez en cuando incluso recibe nuevas funciones. Sorprendentemente, todavía hay usuarios activos en la comunidad de Slack
Me alegra saber que todavía hay gente usando RethinkDB
¿Conectas directamente los centros de Hetzner DE/FI con vpncloud? Pensé que Hetzner ya ofrecía algo así de forma propia y barata
Últimamente he ayudado a muchos equipos a pasar de AWS a Hetzner (y Netcup), y lo que más sorprende a la gente no es tanto el costo o el rendimiento en sí, sino cómo toda la arquitectura se simplifica de golpe cuando quitas 15 capas de abstracción administrada (servicios). Desaparecen preocupaciones como S3/EFS/FSx, cold starts de Lambda o burst credits de EBS. Simplemente despliegas Docker sobre NVMe rápido y funciona. Claro, hace falta un poco más de capacidad DevOps —monitoreo, backups, parches, etc.—. Pero estas tareas operativas, una vez automatizadas, no son algo que cambie cada semana. En Elestio nos enfocamos justo en esa simplificación y ofrecemos stacks totalmente administrados de unas 400 soluciones open source en cualquier nube (incluyendo CI/CD). Cubre producción también sobre Hetzner y otros proveedores https://elest.io (aclaración: trabajo en Elestio, donde ofrecemos servicios open source multi-cloud)
Al inicio de mi carrera trabajé en una empresa increíble, pero necesitábamos una versión de Postgres que RDS todavía no soportaba, así que tuve que montar Postgres varias veces directamente en EC2. Era antes de Docker, así que cada vez era más tiempo perdido configurándolo. En cuanto RDS soportó esa versión, todo se volvió muchísimo más fácil. Todavía recuerdo claramente esas noches hasta las 3 a. m. reinstalando Postgres. El artículo está bien, pero al final hablamos de ahorrar apenas unos cientos de dólares al mes. Con que un solo ingeniero le dedique una hora al mes de mantenimiento, ese ahorro ya puede evaporarse. Y si de repente ocurre una falla, podrías perder en un solo día lo ahorrado en un año. Para un proyecto personal donde el tiempo no vale tanto —y sí necesitas servidores grandes—, operar bare metal puede convenir. Pero al final el valor de mi tiempo termina siendo mayor. Por ejemplo, un blog en Ghost con el hosting oficial cuesta $10 al mes, aunque podrías levantar varios en una instancia de Hetzner. Pero al final, cuando algo se rompe, te preguntas si no conviene más pagar $20 extra que pasar 2 o 3 horas arreglándolo
La mayor ventaja de algunos servidores dedicados de Hetzner es el ancho de banda ilimitado. Yo hospedo un sitio enfocado en imágenes y, desde que me migré a Hetzner, llevo 3 años pagando una tarifa fija y durmiendo tranquilo por las noches
Hetzner claramente tiene límites para escalar. Nosotros, al principio, corríamos cientos de VM sobre Hetzner y en picos necesitábamos escalar a más de mil. Ahí empezaron los problemas: a veces nos asignaban IPs en listas negras, lo que complicaba la conexión con AWS y Google (especialmente S3). Incluso hubo momentos en que ya no quedaban VM disponibles en nuestra región y se detuvo por completo la asignación de nuevas. Al final, si no necesitas una escala enorme, Hetzner es excelente; pero cuando de verdad necesitas escalar mucho, tuvimos que mezclarlo con otros servicios
Que una región se quede sin VM disponibles no parece ser un problema exclusivo de un proveedor. GCP también tuvo algo parecido hace unos años. Si pides cientos de VM de golpe en hora pico, parece que a cualquier nube le cuesta
Es bien conocido que Microsoft bloqueó servicios de Hetzner y Scaleway https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. No sabía que AWS y GCP también lo hicieran, aunque tampoco me sorprende tanto. Las grandes nubes justifican este comportamiento anticompetitivo con la excusa de “entra spam”, pero en realidad no es así
Tal vez aquí se está mezclando la experiencia de usuarios de hardware real de Hetzner (como Server Auction) con la de usuarios de servidores virtuales (VM). Los servidores físicos reales tienen mucha mejor relación precio/rendimiento y velocidad, y las VM, aunque no sean revolucionarias, siguen siendo más baratas que las de la competencia
Esta controversia se refiere al producto Hetzner Cloud (VM). El producto cloud salió relativamente hace poco comparado con los servidores dedicados. Muchos usuarios llegan a Hetzner precisamente por el valor de sus servidores dedicados
De verdad me da curiosidad qué tipo de servicio necesita cientos o miles de VM, y por qué eligieron VM en vez de servidores dedicados. Dicen que la VM más grande de Hetzner tiene 48 cores, 192 GB de RAM y 960 GB SSD, así que me intriga qué requería tanto
Hay razones para usar Hetzner, pero conviene tener en cuenta algunos puntos. La disponibilidad es algo menor que en AWS y también hay menos diversidad de regiones. Por eso recomiendo usarlo sí o sí junto con Cloudflare. En Hetzner operamos el sistema central (K8s), y los datos van en R2/D1/KV, con procesamiento distribuido en Edge Durable Objects. Al fragmentar los datos de clientes por cada DO, logramos al mismo tiempo distribuir la carga de la base de datos principal y mejorar la seguridad
AWS también ha tenido bastantes caídas grandes, más de lo que uno pensaría. Al final, si no diseñas multi-región, es difícil evitar estructuralmente los problemas de disponibilidad
Yo también lo diseñé con núcleo y redundancia de almacenamiento en servidores dedicados de Hetzner, y nodos edge globales adicionales en OVH, usándolo como mi propio CDN
Si los datos del cliente están en el edge, entonces me da curiosidad qué consideran exactamente como “núcleo”