- Relato de um desenvolvedor que migrou da AWS para servidores próprios e reduziu o custo mensal de infraestrutura para um décimo, caindo de US$ 1.400 para US$ 120 e ainda conseguindo servidores mais potentes
- Servidores bare metal oferecidos por empresas como a Hetzner custam cerca de US$ 190 por mês para 80 núcleos, ficando entre 7 e 18 vezes mais baratos do que instâncias equivalentes na AWS
- O motivo de engenheiros de nuvem se oporem à operação de servidores próprios é a segurança do emprego e a dependência de infraestruturas complexas, enquanto o custo real é arcado pelo empregador
- A maioria das pequenas empresas não precisa de recursos de nível enterprise como alta disponibilidade, replicação multi-zona e failover automático, e um único servidor já consegue processar milhões de requisições por dia
- A administração de servidores tende a se manter estável após a configuração inicial, e, com a ajuda de ferramentas de IA, a barreira de entrada para operar servidores Linux está mais baixa do que nunca
Casos de redução de custos com nuvem
- Recentemente, migrei todos os meus projetos para fora da nuvem e consegui reduzir em 10 vezes os custos mensais com AWS, economizando milhares de dólares
- A conta mensal da AWS caiu de cerca de US$ 1.400 para menos de US$ 120
- Passei a ter uma infraestrutura de servidores mais potente por um custo menor
- O desempenho dobrou e fiquei livre do lock-in do fornecedor
- Quando esse tweet viralizou, descobri duas coisas: muitos desenvolvedores se interessaram pelo método, e muitos outros reagiram com forte antipatia e postura confrontadora à ideia
- Do ponto de vista do negócio, eu havia conseguido ganhos evidentes: custo 10 vezes menor, desempenho 2 vezes maior e saída do lock-in do fornecedor, mas ainda assim enfrentei uma forte reação contrária
Os interesses dos defensores da nuvem
- A maioria das pessoas que discordou tinha no perfil palavras-chave como "devops", "cloud engineer", "serverless guy", "AWS certified"
- Essas pessoas não operam seus próprios projetos na nuvem nem pagam diretamente pelos custos dela
- Não se importam com a fatura de AWS do empregador e não sentem na pele a dor de ver milhares de dólares sendo desperdiçados todo mês
- Por que a AWS é conveniente para elas
- Parece tecnicamente complexa, o que as faz parecer inteligentes diante de outros desenvolvedores
- Cria dependências e efeitos de lock-in, tornando-as difíceis de substituir como funcionárias
- Como trabalhar com nuvem garante salários mais altos, elas não têm incentivo para tomar decisões realmente eficientes para o negócio
- Na verdade, quanto mais complexa e obscura for a infraestrutura do negócio, mais seguro fica o próprio emprego
- Essas pessoas não vão contar a verdade de que servidores são, na prática, baratos
Opções baratas para alugar servidores
- Migrar para a Hetzner (sem afiliação, apenas porque oferece servidores baratos)
- É possível alugar um servidor bare metal com 80 núcleos por menos de US$ 190 por mês
- Instâncias equivalentes da linha C5-C6 da AWS custam entre US$ 2.500 e US$ 3.500 por mês, ou seja, 13 a 18 vezes mais caras
- Mesmo com instâncias reservadas, o custo continua em torno de US$ 1.300 por mês, ainda 7 vezes maior, além de exigir US$ 46.000 adiantados e contrato de 3 anos
- A opção de VPS também é atraente
- Máquina com 48 vCPUs por US$ 300 por mês, sem taxa de setup nem contrato de longo prazo, garantindo total flexibilidade
- Máquina com 8 núcleos e 32 GB de RAM por US$ 50 por mês, suficiente para rodar todos os projetos ao mesmo tempo, a menos que você tenha milhões de requisições por dia
Compra de servidores e uso de data center
- No longo prazo, comprar servidores sai mais barato
- É possível comprar um servidor rack mount com 44 CPUs, 256 GB de RAM e SSD NVMe de 2 TB por menos de US$ 1.000
- Dá para operar aplicativos por anos por um custo menor do que um único mês de nuvem
- Opção de alugar espaço em rack em data center
- É possível alugar uma cage ou espaço compartilhado em rack de data center com energia, internet, refrigeração e segurança
- Você pode procurar data centers na sua região em sites como o DatacenterMap
- Isso é complexo demais para desenvolvedores pequenos
- Exige contratação de engenheiros, negociação de preços e outros processos trabalhosos
- Em geral é voltado para empresas médias e grandes, sendo pouco prático para times pequenos
- Na prática, é quase a mesma coisa que alugar um servidor já montado com provedores como a Hetzner, só que sem o peso de administrar o hardware por conta própria
Resposta à crítica de que "isso ainda é nuvem"
- A crítica mais comum é: "isso ainda é nuvem", "você não saiu da nuvem, só trocou de provedor"
- É uma crítica que perde o ponto principal
- O que importa é o valor de administrar seus próprios servidores versus tratar a nuvem como padrão inevitável
- Se você roda uma pequena máquina Linux e substitui serviços gerenciados caros como o RDS, paga de 10 a 100 vezes menos
- A maioria dos desenvolvedores tem medo de servidores e só precisa de um pequeno incentivo para perceber que consegue montar sua própria infraestrutura de forma barata
- No mundo real, quase ninguém precisa dos serviços gerenciados caros da nuvem; em alguns poucos servidores Linux com software comum já dá para fazer o necessário
- Discutir nomes desvia do essencial
- Seja VPS, bare metal, on-premise ou colo, o nome não importa
- Os servidores precisam ficar em algum lugar, e a questão é se você ficou com mais dinheiro no bolso ou se entregou mais dinheiro aos acionistas da Amazon
- Quem faz esse argumento está, no fundo, atuando como gatekeeper
- "Você não está fazendo do jeito certo; tem que comprar os próprios switches, montar o próprio rack e conectar os cabos Ethernet você mesmo"
- É um argumento tóxico e preguiçoso, obcecado por detalhes superficiais para evitar o ponto central
O custo da nuvem é intrinsecamente caro
- A tentativa de gaslighting dos defensores da nuvem
- "Você está usando nuvem do jeito errado", "é caro porque você está fazendo errado", "você precisa aprender a usar nuvem"
- Essas pessoas nunca testaram seriamente as alternativas e não têm experiência real administrando servidores para seus próprios projetos
- Eu conheço bem a AWS e até estudei certificações dela
- Verifiquei se a infraestrutura não estava superdimensionada
- Confirmei se não estava pagando por serviços não utilizados
- Gastei incontáveis horas tentando otimizar custos da AWS e cheguei a reduzir uma conta mensal acima de US$ 5.000 pela metade
- Conheço computação serverless, instâncias reservadas e tudo mais
- Instâncias reservadas só pioram o problema: criam lock-in e prendem você a um contrato de 3 anos
- Se você está considerando sair da nuvem, um contrato de 3 anos é a pior escolha possível
- Depois de tentar de tudo, a conclusão foi: a nuvem é simplesmente cara demais
A origem da reação contrária
- Por que tanta gente se importa tanto com economizar custos?
- Duas conclusões principais
- O sustento delas depende disso: se pessoas como eu convencerem gente suficiente, elas podem perder o emprego
- Discussões irracionais movidas por medo: nos últimos 10 anos, construir tudo na nuvem virou tendência e criou milhões de vagas de "devops" e "cloud engineers"; se sair da nuvem virar tendência, a carreira de muitos especialistas em nuvem pode acabar
- Muitos desenvolvedores sabem secretamente que a nuvem não é tão boa quanto prometia no início
- Veem o empregador gastar 10 vezes mais do que seria razoável com AWS e ainda assim deixam passar como se fosse normal
- Não querem correr o risco de irritar gestores nem assumir responsabilidade
- Têm medo do custo político de discordar da pessoa mais barulhenta do time
- A AWS tem um forte culto em torno de si
- As certificações treinam pessoas a memorizar páginas de venda e descrições de produto
- Há evangelistas que defendem dogmas em vez de pragmatismo
- Existe uma injeção constante de medo do mundo externo (servidores são perigosos! não escalam!)
- "Cloud engineer" vira identidade: é fácil entrar, mas difícil sair
- Como o sustento está em jogo, seguidores da AWS repetem argumentos irracionais presos ao dogma
- Repetem ponto por ponto o discurso de landing pages de venda da AWS, sem pensar se aquilo é realmente necessário
- Como é uma disputa sobre um sistema de crenças, as pessoas se tornam irracionais
A história da nuvem
- Antigamente, todo mundo operava seus próprios servidores
- Em VPS, serviços de hospedagem, bare metal em data center, um quarto escuro na empresa ou em casa
- Todo mundo estava acostumado e confortável em acessar máquinas por SSH
- No começo da década de 2010, começou uma campanha de marketing/psyops da nuvem
- Foi um movimento deliberado para vender tecnologia enterprise para startups em estágio inicial
- A estratégia era criar dependência o mais cedo possível para explorá-las quando viessem os aportes
- A estratégia da AWS
- Começou a oferecer créditos específicos para startups
- Passou por aceleradoras tentando colocar todas as startups na plataforma
- O truque era simples: tornar a infraestrutura extremamente barata no começo (ou grátis!), e depois, quando a startup crescesse, tornar tudo extremamente caro, aproveitando-se do lock-in e da dificuldade de sair do ecossistema
- A IBM Cloud tinha estratégia parecida (evento de 2014)
- Na época, tudo rodava na Heroku e funcionava bem
- Ficava a dúvida: "o que é toda essa nuvem e como se usa isso?"
- Parecia uma tentativa de vender algo que não tinha sido pensado para nós
- Essas empresas gastaram milhões de dólares em campanhas de promoção da nuvem ao longo dos anos para levar startups em estágio inicial a adotar tecnologia enterprise
- A era de juros zero da última década ajudou a levar ao cenário atual
- Hoje existe um movimento de contracultura
- Liderado principalmente por @dhh e pela comunidade Rails
- Algo fundamentalmente mais fresco, correto e alinhado com a realidade da maior parte dos negócios de software do planeta
A maioria dos negócios não precisa de nuvem
- Algumas pessoas têm uma noção completamente desconectada do que é um negócio de software real
- Pensam a partir da perspectiva da Fortune 500 e acreditam que enterprise é o padrão
- Acham que um negócio médio precisa de alta disponibilidade, replicação multi-zona, failover automático, clusters Kubernetes distribuídos e todos os outros recursos da nuvem
- Na realidade, pouquíssimos negócios de software precisam disso
- A maioria dos negócios continuará pequena por uma lei de potência
- Nos EUA, pequenas empresas representam 99,9% de todos os negócios
- Na União Europeia, PMEs (menos de 250 funcionários) representam 99% de todos os negócios
- A maioria dos desenvolvedores superestima as necessidades de escala
- O padrão do que consideram "alto tráfego" é baixo demais
- Como referência: hoje uma configuração com 2 servidores atende milhões de requisições por dia para milhões de visitantes mensais
- Criadores independentes como @levelsio rodam tudo em um único servidor
- A maioria dos desenvolvedores nunca operou, em produção, um projeto próprio com usuários reais e tráfego real em um único servidor
- Os requisitos técnicos também são superestimados
- Só um grupo muito pequeno de negócios de software precisa desses recursos, e normalmente há boas razões técnicas para isso
- No caso da Netflix, por exemplo: é necessário transcodificar e transmitir enormes volumes de vídeo para clientes no mundo todo, então faz sentido usar sistemas distribuídos, CDN e edge computing
- Se você tem um app pequeno com mil usuários trocando apenas objetos JSON, nada disso é necessário
- Muitos desenvolvedores têm uma visão quase mágica e tratam seu projeto como se fosse a Netflix
- É um pensamento desejoso, compreensível, mas que leva a decisões técnicas erradas
- Acham que usuários notarão alguns milissegundos de diferença ao tocar em um botão, então acreditam precisar de servidores distribuídos pelo mundo inteiro
Servidores vão ficar bem
- Muita gente tem ideias quase mágicas sobre como data centers funcionam
- Imaginam que servidores em data center sejam frágeis, instáveis e possam desaparecer no ar
- Algumas pessoas chegam a achar que um raio poderia derrubar um data center inteiro
- Data centers modernos já levam tudo isso em conta e contam com muitas proteções
- Não só contra coisas comuns como raios, mas contra quase tudo que possa ameaçar o uptime
- Energia redundante, refrigeração redundante, links de internet redundantes, sistemas redundantes de combate a incêndio, sistemas redundantes de segurança, além de muita segurança física
- Tudo em um data center é projetado com resiliência e redundância em mente (no mínimo N+1, às vezes 2N) para garantir disponibilidade
- Isso é, em grande parte, uma opinião baseada em medo e resultado de campanhas de marketing e psyops muito bem-sucedidas da nuvem
- Onde a AWS guarda as máquinas? Em algum lugar mágico sob um arco-íris?
- Como apenas as máquinas da AWS estariam magicamente protegidas dos mesmos problemas que qualquer outro data center também enfrenta?
- Desastres podem acontecer (como o incêndio da OVH em 2021), então é preciso ter backups para recuperação
- Mas, em cerca de 15 anos operando servidores, isso foi raro, e eu nunca enfrentei mais do que alguns minutos de downtime
Administrar servidores não é trabalho em tempo integral
- Quem já administra servidores há bastante tempo sabe que a maior parte do tempo vai para a configuração inicial, e depois os servidores tendem a ficar relativamente estáveis
- Falhas de hardware são relativamente raras e, uma vez em produção, o servidor normalmente funciona perfeitamente por anos sem grandes intervenções
- Operar seus próprios servidores não é um trabalho em tempo integral
- Não é preciso contratar um time de 5 pessoas de devops
- Nem contratar alguém só para cuidar de servidores: você mesmo pode fazer isso, e não é tão difícil
- Claude e ChatGPT têm boa compreensão de sistemas Linux e de como administrá-los, então você pode pedir ajuda
- Depois que publiquei o tweet, algumas pessoas presumiram que era minha primeira vez operando um servidor e disseram que eu estava sendo otimista demais sobre o que isso significa na prática
- Tenho experiência administrando servidores desde 2006
- Comecei editando scripts em PHP e enviando-os por FTP para um servidor
- Aprendi a instalar WordPress, editar templates do WP, e o resto veio em seguida
- Foi uma experiência valiosa que me ensinou os fundamentos
- Aprendi o que é Linux e como navegar por ele
- Em 2007, pedi um CD-ROM do Ubuntu para a Canonical pelo correio e instalei no computador dos meus pais em uma partição separada para aprender Linux
- Essas experiências iniciais me ensinaram a base do desenvolvimento web, e todo o resto foi construído sobre isso
A importância de aprender Linux
- As novas gerações de desenvolvedores (Geração Z, Geração Alpha) estão completamente desconectadas do hardware que roda o software
- Falta esse tipo de experiência fundamental
- Elas nasceram em uma era em que alguma pessoa aleatória no YouTube ensina a rodar um comando específico que promove certo fornecedor e aparentemente resolve todos os problemas de infraestrutura como mágica
- É razoável que acabem com pressupostos quase mágicos sobre o que é um servidor e como ele funciona
- Dizem que conseguem fazer tudo com serverless, sem perceber que, no fim, ainda estão executando código em várias outras máquinas
- Claro, muitos aprendem mais sobre Linux e servidores, mas o graduado médio de bootcamp não tem a experiência prática com Linux que os "hackers de FTP" de 20 anos atrás tinham
- Não faço julgamento moral sobre isso, não digo que é bom nem ruim — é apenas o estado atual do desenvolvimento web
- O resultado é que empresas como a Vercel ganham milhões capitalizando em cima de uma nova geração de desenvolvedores que não sabe bem o que está fazendo e nunca operou servidores na vida
- Ignorância tem custo duplo: o custo da ignorância em si e o que você paga para que outras pessoas a explorem
- Não saber como as coisas funcionam realmente custa dinheiro
Agora é a melhor época para aprender sobre servidores
- Tudo bem se você nunca administrou seus próprios servidores e sente medo de qualquer coisa que tenha cheiro de backend
- Na prática, nunca houve momento melhor para aprender a lidar bem com servidores
- Claude e ChatGPT entendem muito de Linux e conseguem orientar passo a passo de uma forma sem precedentes na história da tecnologia
- Dá para aprender não só como configurar e entender como tudo funciona, mas também como fazer mudanças futuras sem precisar contratar ninguém: basta perguntar e seguir as etapas
- Não é tão assustador e nem algo que você precise fazer com tanta frequência
- Em uma era de IA em que geração de código é padrão e código pode virar commodity, saber colocar esse código em servidores de produção baratos e transformá-lo em algo realmente útil para usuários finais pode se tornar um grande diferencial para um desenvolvedor
- É verdade que você precisa se preocupar com coisas como segurança
- Ignore a ideia de que operar seu próprio servidor é menos seguro do que operar servidores na AWS como se uma instância EC2 fosse magicamente protegida de hackers
- Na prática, configurar isso corretamente não é tão difícil; basta consultar guias e scripts de configuração
- Muitos desenvolvedores com mais experiência do que você, mas sem IA, fazem um trabalho muito pior em produção
- Se você pedir ao ChatGPT como fazer hardening de um servidor Linux e seguir boas práticas de segurança (não usar autenticação por senha, usar apenas chaves SSH fortes), 90% do trabalho já estará feito
- O Cloudflare oferece uma camada extra de proteção
- Depois de travar bem a máquina Linux, rode tudo por trás do Cloudflare
- Se você fizer proxy do IP do servidor via DNS e não expuser esse IP diretamente, melhor ainda
- Você ganha proteção contra DDoS, edge caching e DNS de primeira, essencialmente de graça
24 comentários
Quando se considera o tempo e o esforço necessários para montar diretamente a infraestrutura necessária on-premises, os serviços de nuvem não parecem ser tão caros assim.
E os serviços de nuvem são usados pela alta disponibilidade, não pelo custo.
Acho que é um conceito tipo IKEA ou Daiso.
Provavelmente existem serviços de nuvem com ótimo custo-benefício e bem razoáveis.
Só que, quando você começa a usar isso, acaba passando a usar junto coisas que já parecem um pouco caras.
(é só um exemplo mais ou menos) se você usa Lambda, depois acaba usando API Gateway, e isso é meio caro e incômodo -_-^
É mais ou menos assim.
Aliás, com o que eu concordo muito é:
O motivo de a AWS ser conveniente para essas pessoas
é que ela parece tecnicamente complexa e faz você parecer inteligente na frente de outros desenvolvedores.
É essa frase.
Sinceramente, como os serviços da AWS existem há muito tempo e foram evoluindo, há várias funcionalidades que nem conseguiram descontinuar, e saber bem dessas coisas parecia algo legal, então eu também tirei a certificação de SA kkk.. concordo demais~~
Cloud, on-premises e IDC têm cada um suas vantagens e desvantagens; no fim, o essencial é escolher de acordo com o objetivo de uso e a escala.
A maior premissa é que "falhas de hardware quase não acontecem", mas...
Pela minha experiência, quando a empresa alugava um rack em um IDC e operava os servidores por conta própria, eu me lembro de ter que correr para trocar disco e reconstruir RAID porque um disco morria praticamente a cada três dias...
Sempre que possível, eu simplesmente digo para usar cloud. O valor de conseguir subir tudo de novo com um "clique" quando o hardware quebra é enorme.....
Um disco morrer a cada 3 dias é meio estranho... Não parece ser um caso comum.
É uma história de mais de 10 anos atrás, e provavelmente era a Seagate..
A Backblaze anunciou que 4.372 falharam no ano passado, então nessa escala realmente dá algo como um drive quebrando a cada 2 horas...
É uma frequência que pode ocorrer em uma escala extremamente grande.
Hmm, eu trabalhei por bastante tempo em um ambiente com um data center de cerca de 100 racks 42U, com HPC, HCI, um sistema de arquivos distribuído montado com Hadoop dos primórdios e todo tipo de armazenamento, mas nunca vi disco falhar a cada três dias.
Comentários do Hacker News
Há anos eu opero meus próprios servidores e, com isso, mantenho tudo simples e economizo muito tempo e dinheiro
Evito AWS e Azure porque a configuração é complexa e a interface também não é lá essas coisas
O importante é administrar seus servidores de forma que eles possam ser recriados a qualquer momento apenas com arquivos de configuração. Por isso, ferramentas como Ansible são essenciais
Se você realmente precisar usar nuvem, recomendo a DigitalOcean. É simples e intuitiva, faz bem até para a saúde mental
Eu só uso a DO para nível 3 de recuperação de desastres, e configuro o cluster automaticamente com Terraform e Ansible
A maior parte da comunidade de desenvolvedores tende a seguir modinhas, mas eu continuo implantando meu monólito Clojure baseado em JVM no meu cluster de servidores físicos e tendo uma receita estável mesmo nesse ambiente
configuração de
ulimit, problemas de desempenho com SYN cookies, atualizações de segurança, resposta a ataques de zero-day, envio de e-mails (aquecimento de IP, gestão de listas de spam), conformidade com GDPR etc.Tudo isso vira minha responsabilidade, e quem usa nuvem não é simplesmente um “enganado”
Eu odeio pensamento binário. A maioria das startups economizaria muito se trocasse EC2 por Hetzner, Linode ou DigitalOcean
Mas a nuvem também tem muitas vantagens — recursos como backup, banco de dados gerenciado e multi-AZ ficam disponíveis em poucos cliques
Não há investimento inicial em hardware e, em casos de pico de carga, pode até sair mais barato
Ainda assim, como o tempo de engenharia vale muito, na fase de crescimento rápido a nuvem pode ser uma escolha racional
No fim, a nuvem não é cara por si só, e sim porque você está usando recursos de que não precisa
Há muitos casos em que uma estratégia multi-cloud evitou desastres
VPS ou servidores dedicados também quase não têm custo inicial e, se o pico de carga não for extremamente fora da curva, a nuvem não é necessariamente mais barata
Bancos de dados gerenciados são práticos, mas têm muitos upgrades forçados e, se você não estiver em escala muito grande, acho melhor administrar por conta própria
Antigamente era difícil escalar hardware, mas hoje até um único servidor consegue entregar desempenho que antes exigia racks inteiros
Projetos de porte médio agora conseguem resolver por conta própria problemas que antes a nuvem resolvia
Só que, para obter suporte de terceiros, a nuvem é muito mais fácil, enquanto no self-hosting é difícil encontrar gente para dar suporte
Eu, pessoalmente, prefiro self-hosting, mas para quem não quer lidar diretamente com infraestrutura, acho melhor usar nuvem
No passado, cuidei da TI de uma startup de hedge fund
Rodávamos um programa de análise em C++ em um servidor dual Xeon (512 GB de RAM), mas o CEO ficou inseguro depois de ouvir num almoço a pergunta “por que vocês não usam AWS?”
Vi na prática como a “conformidade com buzzwords” pode ser considerada mais importante do que eficiência
Muitos CTOs acabam gastando orçamentos desnecessariamente grandes por causa desse clima, e estruturas eficientes acabam virando até uma fraqueza de marketing
A expressão “economizar 10x” está logicamente errada. 10x significa mais, não menos
O custo de mão de obra de manutenção é maior do que o custo dos servidores
Mesmo operando 10 instâncias EC2, dá para automatizar patches com Systems Manager, então não há necessidade de montar você mesmo toda a automação
O debate sobre nuvem não é preto no branco
Em pequena escala, Hetzner e AWS são parecidos, e para grandes empresas a questão central é se elas conseguem criar suas próprias ferramentas
A faixa das empresas de médio porte (SME) é a mais ambígua. Se você precisa de sistemas totalmente isolados por cliente, a AWS leva vantagem; se a carga é constante 24/7, servidores próprios são melhores
Usar a nuvem só como hospedagem de VM é desperdiçar dinheiro. Muitas vezes você paga sem usar os recursos de nuvem
Com servidores próprios, você paga o mês inteiro pela capacidade máxima; na nuvem, paga só pelos poucos dias em que precisa dela
A nuvem é muito útil para construir um MVP e validar o mercado
Com créditos para startups e free tiers, dá para experimentar rápido e, se o custo virar problema depois, é só migrar
Mas a arquitetura precisa ser pensada desde o início para ser independente de servidor, e é difícil reservar tempo para a migração
Nosso time usa Google Cloud, mas gastamos tão pouco que o vendedor da conta fica insatisfeito
A possibilidade de mudar entre nuvens funciona como poder de barganha
Além disso, a nuvem facilita lidar com SLA e exigências de proteção de dados, o que ajuda a ganhar a confiança de clientes corporativos
Fico curioso sobre por que a AWS cresceu tão explosivamente no começo
No início dos anos 2010, alugar rack e montar servidores era caro e lento, e uma configuração multi-região era praticamente impossível
A AWS resolveu esses problemas, mas agora o cenário mudou
Também houve o caso do Squarespace, que levou combustível pessoalmente para manter os servidores vivos durante o furacão Sandy
Na Hetzner, depois de pedir o servidor, em 10 minutos dá para instalar Ubuntu e aplicar a configuração com Ansible
Preço fixo, banda ilimitada, desempenho previsível — o charme está na simplicidade sem abstrações desnecessárias
O EC2 eliminou esse incômodo, e o Lambda foi além. Hoje, aluguel de bare metal está muito mais barato
No passado, a política de créditos grátis da AWS era, na prática, uma estratégia de lock-in
Colocar seus próprios servidores em um datacenter não é tão difícil quanto parece
Eu precisava de uma CPU de alto clock para um servidor de jogos, algo difícil de conseguir na nuvem, então montei tudo eu mesmo
Operava isso por cerca de £15 por mês, incluindo taxa de instalação, e funcionou bem por anos. No fim, gerou uma grande economia
Eu mantinha equipamentos em um datacenter em Seattle e fazia a gestão remota com KVM via modem
Nós migramos para a Hetzner há alguns anos e, com a economia obtida, dificilmente voltaremos para a nuvem
A exceção é o Cloudflare Workers, que tem ótima qualidade e uma cota gratuita generosa
Graças à IA, ficou muito mais fácil escrever scripts de automação, deploy e backup, então a gestão está mais simples do que antes
Só para constar: o Claude Code da Anthropic está oferecendo US$ 250 em créditos grátis para usuários Pro/Max até 18 de novembro
O anúncio relacionado pode ser visto neste tweet
Será que não dá para perceber o valor só de passar por uma recuperação de backup uma vez? Em ambiente on-premises, a recuperação de backup é de longe a parte mais complicada.
Bem... concordo 100% com "os custos da nuvem são mais altos do que o necessário" e "na maioria dos casos não há necessidade dos recursos de grandes provedores de nuvem", mas o tom do texto, quase como se estivesse dizendo que todos os serviços de nuvem são uma fraude, torna a leitura incômoda. Soa como dizer: "todo produto de seguro é uma fraude".
A nuvem é usada quando você não quer gerenciar servidores ou quando a demanda é difícil de prever e é preciso escalar rápido. Fora esses casos de uso, não sei se faz muito sentido.
Concordo com tudo, mas é uma pena que falte uma discussão sob a perspectiva de segurança quando se opera servidores diretamente por anos.
Também quero concordar com essa opinião.
É isso mesmo.
Concordo 100% que a nuvem é cara.
Mas, pensando que agora você teria que configurar e operar diretamente no bare metal, com Kubernetes, mais de 200 contêineres,
na situação de ser um único desenvolvedor backend, sem DevOps, se isso reduzir a carga de gerenciar e operar servidores por um custo equivalente à metade da metade do salário de uma pessoa, na verdade também não deixa de ser uma escolha razoável.
Se houver alguém dedicado apenas à gestão da infraestrutura de servidores, sair da nuvem certamente pode ser uma boa opção.
Pessoalmente, quando tentei montar um serviço evitando ao máximo a nuvem, quase enlouqueci.
Eu precisava de um repositório de imagens de contêiner, mas ao tentar montar isso vi que armazenamento local era pesado demais; então fui atrás de algo compatível com S3 por causa da praticidade de backup, subi também um serviço de VPN para bloquear acesso externo, além de gerenciar certificados HTTPS no proxy reverso e várias configurações de segurança para CI/CD... tudo isso em infraestrutura própria...
Se for usar só alguns serviços simples na nuvem, claro que bare metal sai mais barato e provavelmente faz mais sentido usar assim. Mas, se você precisa de integração com outros serviços e quer reduzir esse tipo de carga, mesmo que o custo do servidor seja mais alto agora, pode acabar valendo a pena pelo custo de instalação/gestão que você economiza por não ter que montar cada um desses serviços manualmente.
Existem muitos repositórios de imagens de código aberto.
Tem bastante. Eu estava falando do peso de ter que operar isso diretamente. Eu também uso Nexus ou Harbor.
Na minha experiência pessoal, isso não foi um peso nem um problema.
Como o critério do que é considerado um peso pode variar de pessoa para pessoa, talvez dê para entender por que alguém pensaria assim.
Que tipo de serviço você está desenvolvendo que exige um repositório de imagens de contêiner?
Isso acontece porque, independentemente do serviço que eu desenvolva, prefiro fazer deploy com contêineres. Também prefiro, sempre que possível, fazer o deploy sem conexão direta via
ssh. Se pensarmos só em custo... talvez existam formas de fazer deploy direto sem um registry, mas foi só um exemplo que pensei, e quero focar nas partes que acabam ficando um pouco inconvenientes, como serviço de e-mail e coisas do tipo.