- Ao migrar da AWS e da DigitalOcean para a Hetzner, os custos de nuvem foram reduzidos em 76% e a capacidade de recursos aumentou 3 vezes
- No passado, eram usados em paralelo dois serviços de nuvem com base na estabilidade da AWS e na simplicidade da DigitalOcean
- Após o fim dos créditos gratuitos, surgiu uma despesa operacional de mais de US$ 449 por mês, o que levou à busca por alternativas como a Hetzner
- Para reduzir custos, foi montada uma stack de nuvem autogerenciada combinando Kubernetes com base em Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS e cert-manager
- Com os servidores ARM com vCPU compartilhada e o armazenamento compatível com S3 da Hetzner, foi possível manter desempenho e estabilidade ao mesmo tempo em que se alcançou uma expansão significativa de recursos
- A conveniência de gestão diminui um pouco, mas como nuvem alternativa dentro da Europa a relação custo-desempenho é excelente
Contexto
- Todo o software desenvolvido pela DigitalSociety roda em uma base cloud-native
- Antes da migração, a infraestrutura principal era operada tanto na AWS (serviços principais, autenticação, e-mail etc.) quanto na DigitalOcean (serviços leves, monitoramento e Kubernetes)
- A AWS foi escolhida pela familiaridade de mais de 15 anos de uso e pela alta estabilidade da API
- A DigitalOcean foi escolhida por oferecer um ambiente Kubernetes simples, plano de controle gratuito e boa eficiência de custo
- No início, era usada apenas a DigitalOcean, mas para um SaaS intensivo em dados como o tap, eram necessários muitos recursos e créditos adicionais, então foram aproveitados os créditos para startups da AWS (US$ 1.000)
Fim dos créditos e peso dos custos
- Graças ao Fargate da AWS (execução serverless de contêineres), foi possível montar o ambiente inicial com baixo custo, mas as características intensivas em dados do serviço tap exigiam no mínimo 2x CPU e 4 GiB de RAM para manter o desempenho
- No Fargate, um contêiner com essa especificação custa mais de US$ 70 por mês, e somando duas instâncias de worker e outros componentes de infraestrutura, o total sobe para US$ 449,50 por mês
- Os créditos gratuitos fornecidos se esgotaram em menos de 6 meses e, para uma startup financiada com capital próprio, isso se tornou um peso sério de custo fixo
Processo de busca por alternativas
- Para reduzir os altos custos operacionais e ganhar independência tecnológica, foram buscados provedores de nuvem com base no Reino Unido/UE
- A competitividade de preço da Hetzner chamou atenção e, apesar da complexidade operacional de um ambiente VPS autogerenciado, foi decidida a migração tanto da AWS quanto da DigitalOcean
- Como a maior parte dos serviços já rodava sobre Kubernetes, também foi criado um cluster Kubernetes próprio no ambiente da Hetzner graças à facilidade de criação de cluster do Talos Linux
- Não havia serviços gerenciados de banco de dados como na AWS ou na DigitalOcean, mas com o CloudNativePG foi possível integrar e gerenciar com segurança clusters PostgreSQL dentro do Kubernetes (monitoramento, backup, resposta a falhas etc.)
Nova stack de infraestrutura
- Hetzner: uso de servidores ARM, armazenamento em bloco, load balancers, rede, firewall e armazenamento de objetos compatível com S3
- Talos Linux: automação operacional por meio da gestão de nós Kubernetes com configuração declarativa
- CloudNativePG: suporte integrado para declarar clusters de banco de dados em manifests do Kubernetes, com backup automático e resposta a falhas
- Ingress NGINX Controller: gestão unificada do roteamento HTTP dentro do cluster
- ExternalDNS: integração automática de DNS com recursos de ingress
- cert-manager: emissão automática de certificados TLS para HTTPS
- Toda a infraestrutura foi codificada com Terraform e Helm, com deploy automatizado via GitHub Actions para viabilizar DevOps
Comparação de custos
- Custo mensal antes da migração: AWS + DigitalOcean = US$ 559,36
- Custo mensal depois da migração: Hetzner = US$ 132,96 (−76%)
- Aumento de recursos:
- CPU: 12 vCPU → 44 vCPU (+367%)
- RAM: 24 GiB → 88 GiB (+367%)
- Mesmo com o aumento dos recursos, o custo mensal total ficou muito mais barato
Desafios e tentativas no processo de migração
- As network zones da Hetzner não são totalmente equivalentes às Availability Zones da AWS
- Na AWS, uma região possui várias Availability Zones, e a rede privada é amplamente conectada no nível da região
- Na Hetzner, há várias localizações sob uma única network zone (eu-central), e a latência de rede entre elas é alta
- Na prática, ao distribuir entre várias localizações, o monitoramento mostrou problemas como degradação de desempenho
- Como alternativa, foi usado um Placement Group dentro de uma única localização (Nuremberg) para garantir resiliência por meio da distribuição física dos servidores
- Mesmo serviços baseados em contêineres não são tão simples de portar
- Ao migrar do AWS ECS para Kubernetes, a revisão dos scripts de automação de toda a configuração, especialmente a distribuição de arquivos de config, levou mais tempo do que o esperado
- No fim, com Kustomize, foi melhorado o sistema de integração de configurações sensíveis e de gestão de arquivos de config, aumentando a rastreabilidade e a facilidade de revisão
Conclusão
- A Hetzner não é um serviço gerenciado fácil, mas é uma escolha muito eficiente para equipes capazes de operar por conta própria
- A operação própria garante controle sobre a configuração detalhada ao mesmo tempo em que maximiza o desempenho por custo
- Dessa forma, foi criada uma base para continuar desenvolvendo e operando o tap, um SaaS intensivo em dados, com custo razoável e desempenho estável
1 comentários
Comentários no Hacker News
Quero enfatizar o quanto o ganho de desempenho percebido ao implantar direto em bare metal é realmente enorme. No nosso serviço, o desempenho dobrou e passou a mostrar uma performance estável e previsível. Há vários motivos para isso:
Menor latência: ao gerenciar a rede diretamente, você não compartilha a rede complexa de um grande datacenter, então a latência cai mais de 10x
Otimização de cache: com uma implantação otimizada para o hardware, dá para aproveitar de verdade o desempenho dos CPUs modernos
Uso de NVMe dedicado: a velocidade de I/O de disco é absurda
Outra vantagem é que quase não se precisa mais de autoscaler. Pelo mesmo preço, o hardware entrega 10x mais desempenho e ainda roda 2x mais rápido, então faz mais sentido operar em capacidade cheia. O sistema inteiro fica estável e mais fácil de administrar
Também não precisa se preocupar com a conta do S3. Basta colocar um drive NVMe de 15 TB em cada servidor e rodar um cluster MinIO/garage. Estamos processando 20 GiB por segundo e 50 mil chamadas de API por segundo em um cluster de 10 nós. Se fosse no S3, só as chamadas de API custariam algo entre US$ 20 e US$ 250 por segundo, uma diferença impressionante
Sai só uma cobrança fixa por mês
E ainda há storage rápido e barato, operação de grandes instâncias PostgreSQL com baixo custo e uma enorme redução nas limitações e gambiarras que se sente na nuvem
Mesmo investindo numa estrutura dessas, ainda sai por um décimo do custo da AWS
Se gerenciar isso diretamente for pesado demais, nós (https://lithus.eu) fazemos essa gestão pela metade do preço da AWS e ainda damos suporte de DevOps. Contato: adam@, ver domínio
Contexto técnico: bare metal é rodar direto em servidor físico, e não em "virtualização (VM)"
Eu realmente queria que a gente superasse essa mentalidade antiga de "é só colocar mais máquinas que fica rápido" e "custo não importa muito". Na minha carreira, na época de .NET, já aguentei milhões de usuários com um servidor de um único rack. Depois, quando fui para uma empresa que usava nuvem, containers e microsserviços em Node, enfrentei diariamente o caos de faturas e problemas de performance, e isso ainda me dá arrepios de vez em quando
Parece que mudança é sempre um ciclo. Olhando para a nossa empresa, tenho a sensação de que não sair correndo atrás de toda tecnologia nova acaba sendo justamente estar na linha de frente da tendência de cloud local/edge/IDC próprio
Usar a API do S3 é como descascar cebola. Quanto mais você usa, mais chora
Em bare metal, é preciso ter pessoal dedicado para cuidar de rede, segurança, monitoramento, patches e atualizações. O custo dessa mão de obra especializada só faz sentido a partir de certa escala. Então, para pequenas e médias empresas, a nuvem ainda leva vantagem em segurança e custo operacional
A própria AWS diz em sua documentação que, no critério de alocação de 1 vCPU do Lambda, na prática entrega só algo em torno de 50%. A proporção melhora conforme se aumenta memória e CPU, mas isso não significa que entrega 100% de performance sempre
Faz tempo que penso que dá para maximizar a eficiência usando servidores dedicados. Opero alguns nós na Hetzner, e mesmo alugando em leilão servidores antigos de 3 anos, o desempenho é de outro nível comparado a VM. Esses hardwares de servidor são otimizados para número de núcleos e I/O, e a maioria das clouds oferece isso com oversubscription. Até o I/O de disco costuma vir com todo tipo de truque, como rodar em NAS e emular como se fosse disco local. A maioria das startups não precisa dessa virtualização excessiva nem de discos baseados em NAS. Alugar servidor em um lugar como a Hetzner permite ir muito mais longe por muito menos. Queria saber quais provedores na América do Norte, especialmente no Canadá, oferecem algo parecido com a Hetzner em preço e qualidade. Conheço a OVH, então aceito sugestões de alternativas parecidas
Parece que muita gente acha que precisa copiar imediatamente a arquitetura que Google e Facebook usam. Nós operamos modestamente em VPSs europeus. Mesmo assim, todo novo funcionário que entra (de negócios ou desenvolvimento) sempre diz que precisamos começar um projeto de migração para a cloud. Toda vez tenho que convencer a pessoa com algo como: "nós já usamos cloud; não vou deixar você fazer um projeto de migração para cloud só para enfeitar o currículo"
Tenho um registro de benchmark real comparando desempenho de CPU entre cloud e servidores bare metal, pode ser útil: https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12
Um site que encontrei recentemente talvez ajude: https://vpspricetracker.com, o conceito é muito interessante. A maioria dos provedores listados lá também oferece servidores dedicados
Se a ideia for "qualidade Hetzner nos EUA, mesmo que não seja uma marca local", a própria Hetzner já tem 2 datacenters nos EUA
Para o Canadá, alguns provedores que podem servir de referência são https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/
Estamos vendo a mesma tendência. Muitos times migram para a Hetzner e ficam impressionados com a relação custo/desempenho, mas percebem que precisam reconstruir toda a operação de Postgres por conta própria: backup, failover, monitoramento etc. Por isso criamos um Postgres gerenciado rodando diretamente sobre a Hetzner. Mantém a mesma otimização de hardware, mas com alta disponibilidade (HA), backups e recuperação point-in-time (PITR). É open source, roda perto do hardware e não tem as armadilhas ocultas comuns da AWS, como cobrança de I/O ou tráfego de saída. Se tiver curiosidade, veja o blog 1, 2
É exatamente por isso que eu sinto muito o apelo da Big Cloud, especialmente de PaaS e SQL gerenciado, e os times de desenvolvimento que eu aconselho também. Mesmo sem muita experiência operacional, backup/restauração de banco, patches, restrições de acesso, gerenciamento de portas, detecção de anomalias e resposta a ataques DoS passam a ser tratados automaticamente, e isso dá tranquilidade na adoção. Politicamente e tecnicamente, usar um provedor de cloud popular também funciona como rede de segurança psicológica
Se você tem problemas com uma versão configurada por conta própria e Postgres autogerenciado, vale olhar o https://www.elephant-shed.io/
Acho curioso como posts e comentários desse tipo quase nunca trazem o contexto do conselho. Faz muita diferença se a pessoa está rodando um boletim de igreja no tempo livre ou um SaaS enterprise de altíssimo tráfego com clientes no mundo todo. Sem explicar o próprio ambiente, conselho sobre preço, performance e disponibilidade é praticamente inútil. A infraestrutura web ficou complexa demais justamente porque pessoas com requisitos completamente diferentes tentam seguir os conselhos umas das outras
Somando ao meu ponto de que "seguir conselho sem crítica, mesmo com requisitos diferentes, só deixa a realidade mais complexa": em algumas empresas, o account manager da cloud entra no almoço de executivos C-level e acaba empurrando o uso de AWS. Nesse processo, arquitetos da AWS são colocados diretamente junto ao nosso time e, naturalmente, recomendam apenas as opções serverless mais caras. Mas, no fim das contas, a realidade continua sendo reimplantar imagens de SO em Docker e fazer manutenção constante, igual ao patching de um servidor bare metal comum
Até a minha Pastebin pessoal não aguentaria sem bare metal (brincadeira)
Isso é um exemplo típico de como a indústria de TI funciona
Requisitos, nível técnico, estrutura de custos e domínio do problema são totalmente diferentes. Hetzner e AWS parecem parecidas superficialmente por ambas serem "cloud", mas na prática são serviços completamente distintos. Digo isso como alguém que já usou as duas
Concordo fortemente. Até escrevi minha opinião em um blog: https://news.ycombinator.com/item?id=45616366. Em resumo: "entenda os provedores de hospedagem numa escala de preços que vai de DIY até enterprise e, se não usar já for melhor (YAGNI), nem escolha"
Opero um SaaS sobre a Hetzner há mais de 10 anos. Hardware totalmente dedicado, clusters nos datacenters da Alemanha e da Finlândia, tudo gerenciado com ansible. Para VPN entre servidores, uso vpncloud, e esse software é excelente. O custo mensal de hospedagem é ínfimo comparado com AWS e similares, e os servidores são bem mais rápidos. A estrutura é simples e um pequeno número de servidores já dá conta. Quando necessário, basta adicionar mais servidores, embora por ser bare metal isso não escale em minutos. É algo para planejar com algumas horas ou dias de antecedência. O banco de dados roda em arquitetura distribuída com RethinkDB, e em breve vamos migrar para FoundationDB para lidar com falhas
Eu também opero algo parecido com a combinação de rethinkdb. Mas fiquei curioso: por que escolher FoundationDB? O RethinkDB ainda é mantido, e de vez em quando até recebe novidades. A comunidade no Slack segue mais viva do que parece
Fico feliz em ver que ainda existem pessoas usando RethinkDB
Você conecta diretamente os centros DE/FI da Hetzner com vpncloud? Achei que a própria Hetzner oferecesse esse tipo de recurso por um preço baixo
Tenho ajudado muitos times a sair da AWS para a Hetzner (e Netcup) recentemente, e a maior surpresa para as pessoas não é nem o custo ou a performance em si, mas como a arquitetura fica muito mais simples quando se removem 15 camadas de abstração gerenciada. Acabam as preocupações com S3/EFS/FSx, cold start de Lambda, burst credits de EBS etc. É só implantar Docker em NVMe rápido e funciona. Claro, isso exige um pouco mais de capacidade de DevOps, como monitoramento, backup e patching. Mas essas tarefas operacionais podem ser automatizadas e não são coisas que mudam toda semana. Na Elestio, focamos exatamente nessa simplificação e oferecemos stacks totalmente gerenciadas de mais de 400 softwares open source em qualquer cloud, incluindo CI/CD. Cobrimos produção em Hetzner e em qualquer outro lugar https://elest.io (nota: trabalho na Elestio, que oferece serviços open source multi-cloud)
No começo da carreira, trabalhei em uma empresa excelente, mas precisávamos de uma versão de Postgres que o RDS ainda não suportava, então tive que configurar Postgres diretamente em EC2 várias vezes. Era a época anterior ao Docker, e aquilo foi virando um enorme desperdício de tempo. Assim que o RDS passou a suportar essa versão, tudo ficou muito mais fácil. Ainda lembro vividamente das madrugadas até 3 da manhã reinstalando Postgres. Gosto deste post, mas no fim das contas estamos falando de economizar algumas centenas de dólares por mês. Se um único engenheiro gastar só 1 hora por mês administrando isso, a economia já pode desaparecer. E se ocorrer uma falha repentina, um dia pode consumir toda a economia de um ano. Para projetos pessoais, em que o valor do seu tempo não pesa tanto e você precisa de um servidor grande, operar bare metal pode valer a pena. Mas, no fim, o valor do meu tempo tende a ficar maior. Por exemplo, a hospedagem oficial do Ghost custa US$ 10 por mês, enquanto eu poderia rodar várias instâncias num servidor da Hetzner. Só que quando algo quebra, você começa a pensar se não vale mais a pena pagar US$ 20 a mais do que gastar 2 ou 3 horas consertando
A maior vantagem de (alguns) servidores dedicados da Hetzner é a banda ilimitada. Eu hospedo um site focado em imagens e, desde que migrei para a Hetzner, há 3 anos pago sempre uma taxa fixa e durmo tranquilo à noite
A Hetzner claramente tem limites para escalar. No início, também rodávamos centenas de VMs na Hetzner, e nos picos precisávamos passar de mil. Foi aí que começaram os problemas: às vezes recebíamos IPs em blacklist, o que atrapalhava conexão com AWS e Google, especialmente com S3. Em determinado momento, nossa região simplesmente ficou sem VMs disponíveis, e novas alocações pararam. No fim, se você não precisa escalar tanto, a Hetzner é excelente, mas quando a exigência de escala é real, tivemos que misturar com outros serviços
Esgotar completamente a capacidade de VMs numa região não me parece um problema exclusivo desse provedor. A GCP também teve situações parecidas alguns anos atrás. Se você pedir centenas de VMs de uma vez em horário de pico, acho que qualquer cloud sofre um pouco
É bem conhecido o caso em que a Microsoft bloqueou serviços da Hetzner e da Scaleway https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. Eu não sabia que AWS e GCP também faziam isso, mas não me surpreende muito. As big clouds justificam esse tipo de comportamento anticompetitivo com a desculpa de "entrada de spam", mas na prática não é bem assim
Talvez aqui haja uma diferença entre quem fala da Hetzner como usuário de hardware físico real, como Server Auction, e quem fala da Hetzner como usuário de servidor virtual (VM). O servidor físico real entrega custo-benefício e velocidade muito melhores, e as VMs, embora não sejam revolucionárias, ainda costumam ser mais baratas que as da concorrência
Essa polêmica é sobre o produto Hetzner Cloud, ou seja, VMs. O produto de cloud foi lançado relativamente recentemente em comparação com os servidores dedicados. Muita gente procura a Hetzner justamente pelo valor dos servidores dedicados
Fiquei realmente curioso: que tipo de serviço exige centenas ou milhares de VMs, e por que usar VM em vez de servidores dedicados? Vi que a maior VM da Hetzner tem 48 núcleos, 192 GB de RAM e 960 GB de SSD, então imagino que deva ser algo bem específico para precisar disso nessa escala
Existem motivos para usar a Hetzner, mas alguns pontos exigem atenção. A disponibilidade é um pouco inferior à da AWS, e a variedade de regiões também é menor. Por isso, recomendo fortemente usar junto com a Cloudflare. Na Hetzner, operamos os sistemas centrais (K8s), e os dados ficam distribuídos em R2/D1/KV e Edge Durable Objects. Os dados dos clientes são shardados por DO, o que ajuda tanto a distribuir a carga do banco principal quanto a melhorar a segurança
A AWS também teve algumas falhas de grande porte, surpreendentemente. No fim, se a arquitetura não for multi-região, há um limite estrutural para evitar problemas de disponibilidade
Eu também projetei assim: core em bare metal na Hetzner, storage com redundância e nós de edge globais na OVH, funcionando como minha própria CDN
Se os dados do cliente ficam na edge, então o que exatamente entra na categoria de "central"?