4 pontos por GN⁺ 2024-09-15 | 1 comentários | Compartilhar no WhatsApp

Será que uma infraestrutura de nuvem complexa é realmente necessária?

  • Ao ouvir Pieter Levels falando no Lex Friedman Podcast, surgiram muitos insights
  • Pieter opera aplicações em um único servidor e construiu um negócio de micro SaaS bem-sucedido
  • É importante evitar a complexidade da infraestrutura de nuvem e focar no product-market fit
  • Isso pode não servir para todas as startups, mas é preciso evitar complexidade pela complexidade

Observações recentes

Projeto 1: sobrecarga de Lambda

  • Operação de vários serviços com 20 a 30 funções Lambda
  • Tarefas em background usando SQS e Lambda
  • Logs espalhados no CloudWatch

Resultado: difícil de depurar, difícil de mudar e com deploy complexo. Isso poderia ter sido simplificado com um único contêiner NodeJS ou um app Python Flask/FastAPI e Redis

Projeto 2: caos de microsserviços

  • Operação de 7 pequenos microsserviços no Kubernetes (EKS)
  • Serviços separados para CRUD e lógica de negócios

Resultado: mais tempo gasto gerenciando infraestrutura. Fica a dúvida se esse nível de separação era realmente necessário

O poder de uma configuração com servidor único

  • Servidores modernos são poderosos. Hetzner e latitude.sh oferecem VMs potentes por preços baixos
  • VMs do GCP e instâncias EC2 também têm preços razoáveis
  • Oferecem forte poder computacional com 40 GB de RAM e múltiplos núcleos
  • Tudo fica centralizado, facilitando a gestão
  • O problema de escalar para milhões de QPS pode ser resolvido depois

O que é necessário para uma configuração com uma única VM:

  1. Uma máquina poderosa (EC2, GCP VM, Hetzner etc.)
  2. Acesso seguro (HTTPS, SSH com restrição por IP ou SSM)
  3. CI/CD para deploy sem downtime
  4. Configuração de DNS
  5. Backups regulares do banco de dados
  6. Redundância com uma VM em espera

Docker Compose

  • Docker Compose é excelente para desenvolvimento local
  • Permite gerenciar vários serviços com um único comando
  • É menos usado em produção
  • Pode haver downtime durante atualizações

Docker Compose Anywhere: um projeto de fim de semana

  • O Docker Compose Anywhere foi desenvolvido ao longo de um fim de semana
  • Oferece os seguintes recursos:
    • Configuração de servidor Linux com um clique via GitHub Actions
    • Deploy sem downtime usando GitHub Container Registry e Docker Rollout
    • Gerenciamento de variáveis de ambiente e segredos (considerando uso de age ou sops)
    • Backup automatizado do Postgres via GitHub Actions
    • Suporte a múltiplos apps em uma única VM
    • SSL automático com Traefik e Let's Encrypt

Alguns pontos a considerar

Para segurança:

  • Definir regras rígidas de firewall (abrir apenas as portas necessárias)
  • Proteger as chaves SSH (na AWS, preferência por SSM; no GCP, por CLI)
  • Usar um bastion host para reforçar a segurança
  • Considerar proteção de segredos e uso de WAF ou Cloudflare

Proteção de dados:

  • Enviar backups criptografados do banco de dados para um armazenamento em nuvem seguro (ex.: S3)
  • Criar snapshots de disco regularmente para redundância adicional
  • Implementar políticas de retenção para backups e snapshots

Resumo do GN⁺

  • O texto enfatiza que startups devem evitar infraestrutura de nuvem complexa e focar no product-market fit com uma configuração simples
  • Apresenta as vantagens de uma configuração com servidor único e um método simples de deploy usando Docker Compose
  • É importante focar no desenvolvimento do produto principal, sem desperdiçar tempo com gestão de infraestrutura complexa
  • Projetos com funções semelhantes incluem Heroku e DigitalOcean

1 comentários

 
GN⁺ 2024-09-15
Comentários do Hacker News
  • Em vários projetos, equipes que tentam usar as tecnologias mais recentes frequentemente acabam entregando resultados de baixa qualidade

    • Há equipes imaturas que querem usar Kubernetes sem realmente entendê-lo
    • Montam processos automatizados com Puppet para executar serviços Docker em várias VMs ou rodar backends em Python
    • Startups estão gastando muito na nuvem e ainda assim produzindo resultados piores do que os pioneiros de DevOps de 2017
    • Post de blog relacionado: The Emperor's New clouds
  • Em startups pequenas, usam uma única VM para rodar nginx, webapp, postgres, redis etc.

    • Os desenvolvedores conseguem trabalhar localmente com a mesma configuração, o que facilita o debugging
    • Escala vertical é possível, então isso é adequado na fase inicial
  • Um SaaS começou em um único servidor e depois expandiu para vários servidores

    • Operam um banco de dados distribuído sem usar Kubernetes
    • Usam servidores bare metal mais potentes do que as máquinas virtuais dos provedores de nuvem
    • Gerenciam os servidores com ansible e terraform como ferramentas de automação
  • Recursos centrais do Kubernetes, como deploys, serviços de pods e blue-green deployments, são úteis

    • Em ambientes cloud native, usar vários sistemas open source pode tornar tudo mais complexo
  • Muitas pessoas constroem infraestruturas complexas para aprender Kubernetes

    • Isso pode ser útil ao escalar para clientes de grande porte
    • Pode ser menos útil para fundadores ou CTOs
  • Até livros sobre microsserviços recomendam: "primeiro, construa um monólito"

    • No começo, usar um monólito facilita o debugging
    • Usam Docker para simplificar a fase inicial
    • Migram para Kubernetes conforme as necessidades do negócio
  • Não é recomendável escolher frameworks complexos desde o início

    • Usar ferramentas próprias nem sempre é mais eficiente
    • Usar ferramentas padrão pode ser mais eficiente no longo prazo
  • Na nuvem, usam apenas VM, block e blob storage, DNS, IdP e registrador de domínio

    • Serviços como FaaS são complexos e difíceis de depurar
    • Uma única VM e uma codebase monolítica são o ideal
  • Um projeto foi operado por 6 anos em um único VPS de US$ 10/mês

    • A tecnologia de VPS evoluiu muito e hoje tem alta confiabilidade
    • A infraestrutura de nuvem é usada por causa dos recursos de colaboração e gestão operacional
  • Preferem soluções baseadas em nuvem, mas de forma seletiva

    • Usam Google Cloud Platform (GCP) para reduzir custos
    • Não usam Kubernetes
    • Usam Docker para simplificar o deploy
    • Os serviços gerenciados do GCP economizam tempo