Estou construindo uma nuvem
(crawshaw.io)- As abstrações de nuvem existentes dificultam combinar CPU, memória e disco da forma desejada, e tanto VMs quanto PaaS impõem mais restrições do que um computador comum
- O armazenamento remoto em bloco e os altos custos de egress mantêm uma estrutura presa a premissas da era dos HDDs, ampliando ainda mais os problemas de desempenho e custo em ambientes com SSDs e redes modernas
- O Kubernetes encobre APIs de nuvem difíceis de lidar, mas não consegue mudar a abstração básica errada, carregando consigo os limites de VM, disco e rede
- À medida que agents aumentam a demanda por software e execução, espaço privado de execução, compartilhamento fácil e baixo overhead operacional se tornam ainda mais importantes, e os gargalos estruturais da nuvem atual também crescem junto
- A exe.dev tenta se aproximar da nuvem que as pessoas realmente gostariam de usar, alocando primeiro CPU e memória e permitindo executar VMs diretamente sobre isso, combinando TLS proxy, proxy de autenticação, NVMe local, replicação assíncrona e posicionamento baseado em anycast
Por que construir uma nova nuvem de novo
- As abstrações de nuvem existentes dificultam usar computadores da forma desejada, e isso se tornou a razão direta para começar uma nova empresa
- O computador em si é bom, mas as nuvens de hoje repetem restrições em quase todos os produtos, e o cerne do problema está menos em UX ou erros de design de API e mais no formato das unidades básicas de composição
- VMs são fornecidas como instâncias individuais atreladas a CPU e memória, mas o modelo desejado se parece mais com reservar primeiro recursos de CPU, memória e disco e então subir quantas VMs forem necessárias sobre eles
- Uma VM Linux é um processo rodando dentro do cgroup de outro Linux, mas na nuvem atual isso não é fácil de tratar
- Para contornar isso, é preciso rodar gVisor ou virtualização aninhada dentro de uma única VM de nuvem, assumindo perda de desempenho e, no mínimo, a operação de um reverse proxy
- PaaS também não resolve esse problema e, na verdade, força abstrações proprietárias do provedor que são menos poderosas do que um computador comum
- É preciso aprender uma nova forma de desenvolvimento para cada provedor de computação
- Às vezes só depois que o projeto já avançou bastante fica claro que algo simples em um computador comum é quase impossível por limitações profundas da plataforma
- Repetidas vezes parece que “agora vai”, mas tudo volta a emperrar em abstrações implementadas pela metade
Limites estruturais expostos em disco e rede
- No disco, os provedores de nuvem preferem armazenamento remoto em bloco ou opções ainda mais restritas e lentas como S3, o que fazia algum sentido na era dos HDDs
- O armazenamento remoto não sofria uma grande perda em leituras e escritas sequenciais, e como o seek aleatório de HDD ficava na casa de 10ms, um RTT de 1ms por Ethernet era um custo aceitável
- Do ponto de vista do provedor, isso também facilita a operação ao remover um eixo dos tipos padrão de instância
- Mas essa premissa deixou de valer com a transição para SSDs
- O tempo de seek caiu de 10ms para 20 microssegundos
- O RTT de rede dos sistemas remotos em bloco melhorou, mas o overhead de IOPS cresceu de algo em torno de 10% na era dos HDDs para mais de 10x na era dos SSDs
- Na EC2, para montar uma configuração de 200k IOPS, a configuração já é complicada e custa US$ 10 mil por mês, enquanto um MacBook entrega 500k IOPS
- A tecnologia de rede em si já é boa o suficiente, mas os custos de egress e a estrutura de negócios acabam trabalhando contra a usabilidade
- As redes dos hyperscalers são excelentes, mas muito caras e também dificultam a integração com outros fornecedores
- O preço de egress cobrado pelos provedores de nuvem é apresentado como algo na ordem de 10x por GB em relação a colocar servidores em rack em um datacenter comum
- Quando o uso sobe um pouco, esse multiplicador piora ainda mais
- Clientes que gastam dezenas de milhões de dólares por mês conseguem preços melhores, mas isso não serve para projetos de dezenas ou centenas de dólares por mês
- Nessa faixa, qualquer coisa que se construa acaba sendo difícil de operar de forma barata
Kubernetes e APIs escondem o problema, mas não o resolvem
- APIs de nuvem são dolorosas de usar, e o Kubernetes surgiu como uma forma de encobrir isso e reduzir o sofrimento dos engenheiros
- Porém, VMs continuam difíceis de lidar mesmo sobre Kubernetes, porque a nuvem basicamente empurra a virtualização aninhada para o usuário
- Com disco acontece algo parecido: quando o Kubernetes foi projetado, do lado do Google praticamente não havia dispositivos remotos em bloco realmente utilizáveis e, mesmo hoje, ao tentar encaixar tudo em padrões comuns, ainda é fácil acabar preso a armazenamento lento
- Na rede também há pouco incentivo para facilitar demais, porque se fosse simples conectar alguns sistemas em datacenters abertos próximos por meio de private link, seria possível apagar um zero do custo da nuvem
- Em vez de tratar Kubernetes como trabalho artificial, ele é visto como o produto de uma tentativa de enfrentar o problema impossível de criar uma nuvem portátil e utilizável
- No fundo, não dá para resolver isso empilhando uma nova abstração sobre uma abstração de nuvem errada, e até os esforços para tornar Kubernetes melhor esbarram em limites claros
- Já são 15 anos convivendo com essa nuvem incômoda e, nesse período, a estratégia foi suportá-la como outras partes desagradáveis da pilha de software: minimizando o contato sempre que possível
Agora é a hora de corrigir isso
- O motivo de este ser um ponto de virada é o surgimento dos agents
- Como no paradoxo de Jevons, quanto mais fácil fica escrever código, mais a quantidade total de software aumenta, e mais programas cada pessoa passa a usar tanto no trabalho quanto no lazer
- Para executar esse volume crescente de programas, são necessários espaços privados de execução, compartilhamento fácil e baixo overhead operacional
- Quanto maior a quantidade total de software, mais os problemas de nuvem, antes apenas irritantes, se transformam em gargalos sérios
- Será preciso mais computação e também uma gestão mais simples
- Agents ajudam a operar no lugar de APIs da AWS, mas exigem entregar credenciais e às vezes podem até apagar um banco de dados de produção
- Acima de tudo, agents também batem nas mesmas limitações fundamentais das abstrações de nuvem atuais
- Eles acabam consumindo mais tokens do que o necessário e entregando resultados piores do que o esperado
- Quanto mais a janela de contexto de um agent é desperdiçada tentando encaixar a nuvem clássica à força, menos sobra para resolver o problema real
O que a exe.dev começou a corrigir primeiro
- O primeiro lançamento da exe.dev foi uma solução para o problema de isolamento de recursos de VM
- Em vez de provisionar VMs individuais, a estrutura fornece primeiro CPU e memória e permite executar diretamente as VMs desejadas sobre esses recursos
- Partindo da premissa de que ninguém quer expor uma nova VM diretamente à internet, o serviço cuida em conjunto de TLS proxy e proxy de autenticação
- Para disco, usa NVMe local, com replicação assíncrona dos blocos para fora da máquina
- Também permite colocar máquinas em várias regiões do mundo para executar mais perto dos usuários
- As máquinas são posicionadas atrás de uma rede anycast, oferecendo um ponto de entrada de baixa latência para usuários do mundo todo
- Essa base também foi desenhada para permitir novos recursos em breve
- Ainda há muita coisa a construir
- Itens relativamente claros, como IP estático, ainda faltam
- Também restam desafios como a UX de acesso a snapshots históricos de disco gerados automaticamente
- Ao mesmo tempo, o trabalho está voltando à etapa de colocar computadores diretamente em rack em datacenters, reavaliando todas as camadas da pilha de software, inclusive a forma de conexão de rede
- O objetivo final é construir uma nuvem que as pessoas realmente queiram usar
6 comentários
Fiquei pensando “por que agora?”, mas...
Quando vi que o autor é cofundador da Tailscale, por algum motivo passei a querer torcer por isso.
Façam um ótimo trabalho!
A tabela de preços é muito confusa, porque está escrita algo como 2 núcleos, 8 GB, 50 VMs. Acho que dá para entender como: você recebe uma VM e pode rodar 50 contêineres nela.
Há uma razão para a nuvem ser complexa.
Não estou vendo a opção de excluir a conta; alguém conseguiu encontrar?
Seria ótimo se fosse possível conectar serviços só com arrastar e soltar
Comentários no Hacker News
Kubernetes no começo pode até parecer ok para rodar alguns contêineres de webapp, mas logo você coloca SDN por cima, vai acoplando todo tipo de serviço, e ele acaba ficando descontroladamente inchado
Quanto mais “otimizavam” e “endureciam” o cluster, mais os custos de cloud, incidentes, downtime e esforço de depuração aumentavam, tudo em 2 ou 3 vezes
No fim, abandonaram essa inércia de DevOps, eliminaram o cluster e passaram a fazer deploy de Docker com Kamal em uma VM única com Debian e firewall ativado; com isso, a estabilidade e a confiabilidade da infraestrutura ficaram melhores do que nunca, e o custo caiu bastante
A maioria dos apps de negócio atende de centenas a poucos milhares de usuários, então um único VM grande muitas vezes basta, e como clouds como a do Google já lidam com falhas de hardware, quando necessário é só subir uma segunda VM e trocar o IP no Cloudflare
É comum enfiarem k8s em escalas pequenas demais, e nesse caso provavelmente nem existe escala que justifique k8s
Por isso é preciso uma camada superior que simplifique padrões comuns de deploy, e Knative é um exemplo disso
Soluções que tentam expor todos os primitives de base inevitavelmente acabam tão complexas quanto o próprio Kubernetes
O que eu criei, https://github.com/openrundev/openrun, faz deploy declarativo de webapps internos para equipes, adiciona SAML/OAuth e RBAC, e suporta tanto Docker em máquina única quanto Kubernetes
Uma mentalidade excessivamente complexa, cara e difícil de depurar pode ser reproduzida do mesmo jeito em VMs
A diferença é que agora a VM Debian única talvez esteja fora do radar das políticas deles, então ainda está livre
Quando alguém começar a se meter, há grandes chances de tentarem enfiar HA, rollout/rollback, 3 a 5 VMs, políticas de rede virtual, 4 scanners de segurança, 2 processadores de logs, watchdog, monitor de rede, mTLS e ferramentas de visibilidade de tráfego em sequência
Ter mais uma reduz bastante a ansiedade quando ocorre alguma falha durante upgrade ou mudança
O que estou criando, https://github.com/psviderski/uncloud, inspirado no Kamal, tenta tornar configuração multimáquina tão simples quanto uma VM única, usando overlay WireGuard sem configuração e Docker Compose padrão para deploy em várias VMs
Você começa com 1 máquina, sem complexidade de orquestrador ou control plane, e depois pode expandir quando precisar, até misturando VMs de cloud com on-prem
Usei em produção e foi ótimo em todos os momentos; parecia algo no nível de redefinir a própria computação
Então provavelmente estou deixando passar algo na perspectiva de quem o odeia tanto
A OP é uma das cofundadoras do Tailscale, o que torna isso ainda mais interessante em contexto
A observação de que empresas tradicionais de Cloud 1.0 entregam algo como 3000 IOPS por padrão em VMs, enquanto um notebook chega a 500 mil IOPS, parece bastante precisa
A visão é realmente ótima e sinto que sou exatamente o cliente-alvo, mas preocupa pensar que, quanto maior for o sucesso, mais a pressão por receita pode acabar superando o ideal, seguindo aquele caminho já conhecido
Preços de cloud muitas vezes não são baseados em custo, e costumam ser desenhados para gerar grande margem justamente em itens como bandwidth ou NAT gateway, que explodem de preço quando o cliente já está profundamente preso
Não acho que a OP desconheça essa estrutura
Mas esse storage é basicamente ephemeral por natureza e também não tem redundância suficiente
Dá para reduzir falhas de hardware com RAID1, mas isso diminui a quantidade de NVMe utilizável, e também não há uma forma elegante de lidar com a situação em que a VM precisa ser movida por problemas de RAM/CPU do host
No fim, esse tipo de VM precisa ser tratado quase como bare metal, com redundância na camada da aplicação, como replicação de banco de dados
Na Azure, você precisa assumir que eles podem mover a VM e apagar dados ephemeral quando quiserem, mas no OpenStack era possível desligar a VM e copiar também os dados do NVMe para outro host via migração local em nível de bloco, quando necessário
Ainda assim, se o host travasse, a VM ficava fora do ar até ele voltar, então a redundância no nível da aplicação continuava sendo um pré-requisito
Mas a latência no percentil 99,9 foi de cerca de 5ms na Hetzner e 18ms na DO, e a latência máxima ficou na faixa de 7ms na Hetzner contra 85ms na DO, então a diferença é bem grande
No dd sequencial, a Hetzner fez 1,9GB/s e a DO 850MB/s
O preço também difere muito: 4 euros na Hetzner contra 18 dólares na instância da DO
Escrevi isso antes de terminar o texto e, por coincidência, a OP apontava exatamente esses dois itens
Seria uma forma de induzir lock-in ao dificultar até o uso de um banco de dados local simples na máquina
A ideia de que algo custa X para produzir e então o preço vira 1,y*X está bem distante da forma como precificação de mercado realmente funciona
Na prática, top-down costuma ser mais realista que bottom-up
Assim como o debate sobre IA vai para extremos, Kubernetes parece estar igualmente polarizado
Já operei clusters de vários tamanhos por anos, e nunca tive um incidente cuja causa fosse o próprio k8s
Uma vez houve uma interrupção de uma hora com cara de apagão total, e quem odiava k8s tentou imediatamente culpar “esse maldito sistema k8s”
A causa real foi um serviço que, em certa condição, abriu dezenas de milhares de portas de uma vez e causou um auto-DOS
Não acho que k8s seja o futuro de tudo, nem que seja lixo; acho que é um bom sistema quando realmente é necessário
Uma é que ele é complexo demais para aprender, desnecessário para o meu problema e que formas antigas de deploy já bastam; a outra é que ele tem eficiência de custo/energia pior do que bare metal
Em geral, as duas coisas andam juntas
Posturas moderadamente neutras ou indiferentes estão ficando raras, e a política dos EUA vem logo à cabeça
Eu mesmo não entendo muito de k8s e fico com olhar vazio quando um staff engineer começa a falar de pod e cluster, mas para o nosso time ele funciona bem e de fato entrega
Para quem só tem um martelo, tudo parece prego; quem está com um machado estranha ver tanta gente tentando cortar madeira com martelo
E, se o machado seria a ferramenta certa mas alguém com martelo toma seu emprego, fica ainda mais fácil odiar o martelo
No k8s, as best practices já estão razoavelmente consolidadas para muitos casos de uso, mas no mundo de LLM ainda nem sabemos direito o que seria best practice
Concordo muito com a crítica de que, como VMs ficam atreladas a CPU/memória, você acaba pagando pelo tempo, não pelo trabalho
Por isso comprei um servidor de leilão barato da Hetzner e o uso em cima de um orquestrador self-hostable de Firecracker que eu mesmo fiz
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
O que eu queria era comprar hardware, dividi-lo em VMs à vontade e não me preocupar com provisionamento nem lifecycle
VMs ociosas fazem snapshot do estado da memória em disco e devolvem toda a RAM, então o hardware é meu, as VMs são disposable, e quando nada está rodando o custo é quase zero
Principalmente a ideia de memory-state snapshot acabou sendo muito mais poderosa do que eu esperava, porque tudo passa a ser retomável
Eu posso fazer snapshot de uma sessão já autenticada no Chromium e subir instantaneamente cópias dela quando preciso; agentes trabalham dentro do sandbox e o docker compose para ambientes de preview também roda ali
Quando nada está rodando, o servidor fica praticamente idle, e uma única máquina de 100 dólares por mês dá conta de tudo isso
Há mais detalhes em https://shellbox.dev/blog/race-to-the-bottom.html
A documentação é completa e útil, mas em várias partes tem uma cara muito evidente de texto escrito por IA, então eu gostaria que fosse um pouco mais concisa
Ainda assim, a seção “design decisions” ficou especialmente boa, e aprendi coisas novas ali
Se ainda não fez isso, valeria a pena postar no Show HN
Já existe software demais que nunca é usado, então não entendo por que há tanta obsessão com produzir ainda mais código
Basta olhar a app store para ver um monte de software que ninguém usa
O uso mais óbvio para LLMs não deveria ser criar mais software, e sim criar software melhor
Espero que o foco saia dessa fixação em geração de código e vá para outras direções, porque há muitas formas de LLM ajudar a escrever código melhor
A imagem de um sistema determinístico que você projeta com cuidado, mantém e atualiza vai continuar existindo, mas a IA já está mudando a forma como o usuário interage com o computador
Como resultado, provavelmente veremos um software muito mais descartável
Neste momento ainda estamos na fase do “como a IA pode ajudar engenheiros a escrever software”, mas aos poucos parece que estamos migrando para “o que engenheiros devem fazer para ajudar a IA a escrever software melhor”
Quando isso acontecer, vai entrar em cena um grupo novo de engenheiros com uma visão completamente diferente sobre o que é software e como devemos construir interações com computadores
Acho que vai surgir uma quantidade enorme de software sob medida que jamais vai parar numa app store
Para ser Jevons paradox, o custo unitário de produzir software teria que cair, mas o aumento de demanda precisaria ser tão grande que superasse a economia e elevasse o gasto total
Esse conceito vale para mercados em que a quantidade demandada responde fortemente a mudanças de preço, isto é, com alta elasticidade da demanda
Tirando jogos, talvez no futuro a gente olhe para trás e ache estranhíssimo esse modelo de criar um único software para milhões ou bilhões de pessoas
Agora as pessoas podem passar a construir software que faz exatamente o que elas realmente querem, sem depender tanto de prioridades conflitantes ou modelos de receita distorcidos
Por definição, esse tipo de software também pode ser visto como de qualidade mais alta
Isso facilitava previsibilidade de custo e receita para ambos os lados, mas o ponto central era construir software o mais genérico possível
Como consequência, UX ou funcionalidades importantes só para parte dos usuários acabavam continuamente cortadas
Vibe coding e desenvolvimento acelerado por LLM podem inverter isso
Agora todos podem bancar software customizado para suas próprias necessidades e preferências, e dá para imaginar um mundo em que, em vez de 150 mil clientes da Salesforce usarem o mesmo CRM, existam 150 mil CRMs personalizados
O espaço para expansão do software neste momento é enorme
Se você não entende o ciclo de inchaço do software, vai continuar repetindo os mesmos erros
Começa-se com software lean, vão sendo adicionadas funcionalidades pedidas pelos usuários, ele vira uma bagunça bloated, depois surge a necessidade de um rewrite menor, e então o ciclo retorna a software lean
Reboots normalmente fracassam ou então acertam algo tão fundamental que avançam a ponto de ameaçar os incumbentes
Essa visão de DevOps como algo para encher currículo ou como a origem de toda complexidade excessiva me parece mais uma mentalidade de startup
Em empresas pequenas, talvez uma pessoa de DevOps toque toda a infraestrutura, mas especialmente no setor financeiro quem de fato dita a direção costuma ser a liderança de engenharia de plataforma
Essas pessoas dividem engenheiros de software em vários grupos pequenos e querem que cada time controle seu próprio repo, seu próprio deploy, seu próprio tudo, acreditando que microsserviços dão essa autonomia
Posso garantir que o pessoal de DevOps odeia complexidade
São eles que ficam de plantão à noite e no fim de semana, e tudo sempre começa com a suposição de que “é problema de infraestrutura”
Os logs de deploy estão todos no sistema de agregação de logs, mas ainda assim é raro que o próprio desenvolvedor investigue seu problema de deploy olhando os logs; logo isso vira um incidente
Talvez já esteja na hora de tratar microsserviços como a moda passada
Gostei do exe.dev e acho que existe, sim, oportunidade em algo que suavize o fluxo de desenvolvimento com LLM e ao mesmo tempo ofereça a flexibilidade de uma máquina Linux com root
Mas, ao ler a frase “fui traído repetidamente por abstrações meio implementadas e meio pensadas”, de forma irônica senti que isso descreve exatamente a minha experiência com Tailscale
A promessa era simplificar redes, mas por que a bateria acaba tão rápido, por que as regras de firewall são alteradas de um jeito que conflita com outras ferramentas, e por que o bug tracker é tão silencioso a ponto de eu acabar tendo que entender a implementação interna?
Aí minha reação acaba sendo “No thank you”
O serviço em si parece realmente muito bom
A ideia não é escrever ACL de roteador, e sim compor uma camada de rede peer-to-peer; é aí que sinto falta
Eu simplesmente uso Hetzner
Tudo que as empresas de cloud oferecem é caro demais, e meu Postgres HA com backup operado por mim mesmo ficou no ar por 10 anos sem interrupção, custando algo como um décimo do preço de produção de RDS ou CloudSQL
Eu mesmo faço autoscaling das instâncias com métricas coletadas no Grafana, e um autoscaler baseado em webhook funciona de forma muito simples e nunca me causou problemas
Então já nem sei por que eu usaria GCP ou AWS
Todos os serviços são HA e os backups diários funcionam muito bem
Na época, o objetivo era recriar de forma barata a experiência de um dedicated server, mantendo o máximo de flexibilidade, e o UML possibilitava isso
Mas durante toda a década de 2010 eu errei completamente ao achar que a maioria dos desenvolvedores jamais trocaria isso por um mundo onde cada pedaço da stack é cobrado por medição só por um pouco mais de conveniência
Fico me perguntando se engenheiros de software na faixa dos 20 e poucos anos hoje ainda saberiam montar uma plataforma de webapp de alto tráfego usando servidores e roteadores comprados no eBay
Eu mesmo fiz isso no ano passado para construir um datastore de mais de 50PiB, e sinceramente queria saber o quanto essa abordagem ainda é usada em projetos médios e grandes
A Hetzner remove grande parte da dor operacional do físico e ainda preserva quase toda a vantagem econômica, então me surpreende que ela não seja a rainha absoluta do mundo de hospedagem e tenha ficado em algo como 367 milhões de euros de receita em 2021
Também me custa acreditar que o conhecimento necessário para operar um conjunto de dedicated servers tenha se tornado tão especializado a ponto de as pessoas ignorarem uma economia tão grande
Ainda assim, se você consegue achar a equipe adequada, operar por conta própria pode sair muito mais barato
A cada minuto, o cron roda
docker pullpara buscar a imagem mais recente, e só quando há uma nova versão ele substitui comdocker up -dNa frente, uso o caddy para HTTPS, e isso roda há anos de forma muito barata e estável
Pareceu um provedor do Reino Unido com filosofia parecida; ainda não usei, mas já criei conta como candidato ao meu próximo VPS
Como já dá para começar com um servidor 5 vezes mais rápido, muitas vezes nem há necessidade real de autoscaling
Já existem várias alternativas, e eu criei o https://shellbox.dev
Diferente do exe, ele cobra só pelo uso, faz scale-to-zero e permite subir VMs instantaneamente por SSH
É Linux comum, então também funciona com VSCode Remote e Zed Remote, e ainda permite nested virtualization
Se alguém quiser investir, 5 milhões de dólares já servem
Não há portas expostas para fora, e todos os frontends web são protegidos por senha
Não pretendo publicar isso; é o meu ambiente de desenvolvimento isolado rodando num Raspberry Pi pessoal atrás da TV
O custo é praticamente zero
Espero que o serviço também dê certo
Não está claro onde fica a infraestrutura subjacente nem quais garantias de segurança existem, e isso dificulta confiar nele