Quase todas as decisões de infraestrutura que aprovei ou das quais me arrependi após 4 anos operando infraestrutura em uma startup

 (cep.dev)
87 pontos por xguru 2024-02-28 | 4 comentários | Compartilhar no WhatsApp
  • Todas as escolhas são marcadas como Endorse (aprovo) e Regret (arrependimento)

Escolha da AWS

  • AWS em vez de Google Cloud: Aprovo ter escolhido a AWS. A AWS é focada no cliente. O Google Cloud passa a sensação de depender de robôs e automação.
  • EKS: Aprovo usar EKS. O EKS oferece integração profunda com os serviços da AWS, e o Kubernetes também alcançou um bom nível em vários aspectos (como a integração com o Route53 usando externaldns).
  • Add-ons gerenciados do EKS: Me arrependo de usar add-ons gerenciados do EKS. Houve necessidade de customizar a instalação, e depois de migrar para charts Helm a operação ficou melhor.

Banco de dados e cache

  • RDS: Aprovo usar RDS. Os dados são a parte mais importante da infraestrutura, e o custo de usar RDS vale a pena.
  • Redis ElastiCache: Aprovo usar Redis. O Redis é muito eficaz tanto para cache quanto para uso geral.
  • ECR: Aprovo a migração de quay.io para ECR. O ECR é mais estável e tem integração de permissões mais profunda.

Rede e suporte

  • AWS VPN: Aprovo usar AWS VPN. A VPN é muito simples de configurar e entender. Estamos usando Okta para gerenciar o acesso à VPN, e a experiência tem sido muito boa.
  • Suporte premium da AWS: Me arrependo. O suporte premium da AWS é muito caro e não vale a pena se você não tiver falta de conhecimento interno sobre AWS.
  • Control Tower Account Factory for Terraform: Aprovo a integração com AFT. Ela automatiza a criação de contas e ajuda a padronizar tags.

Automação de processos

  • Automação de postmortem com bot do Slack: Aprovo automatizar o processo de postmortem. Isso ajuda a incentivar as pessoas a escreverem os postmortems.
  • Uso de templates de incidente no PagerDuty: Aprovo o uso de templates quando um incidente acontece. Dá para aproveitar a flexibilidade do Notion e fazer alguma customização.
  • Revisão periódica de tickets do PagerDuty: Aprovo revisar regularmente as configurações de alertas. Isso ajuda a garantir que até alertas menos importantes não sejam simplesmente ignorados.
  • Gerenciar postmortems no Datadog ou PagerDuty: Me arrependo de usar uma ferramenta centralizada para gerenciar postmortems. Em ambos os casos, é difícil customizar o processo posterior. Acho melhor usar uma ferramenta mais poderosa como o Notion.

Outros

  • Reunião mensal de acompanhamento de custos: Aprovo fazer uma reunião mensal para revisar custos de SaaS. Isso ajuda a verificar se os gastos fazem sentido e a tomar ações quando necessário. Na AWS, agrupamos itens por tag e separamos por conta. Recomendo olhar não só para a AWS, mas para todas as principais fontes de gasto da empresa.
  • Não usar mais FaaS: Me arrependo de não ter conseguido usar FaaS de forma mais ampla, já que não havia opção de FaaS para workloads com GPU. Muitos workloads de CPU poderiam ter sido tratados com FaaS. Outro benefício oculto do Lambda é que fica muito fácil acompanhar custos com alta precisão.
  • GitOps: Aprovo usar GitOps. Estamos usando GitOps em boa parte da infraestrutura e investimos no desenvolvimento de ferramentas para ajudar a entender o estado dos deploys.
  • Priorizar a eficiência da equipe: Aprovo priorizar o aumento da eficiência da equipe. Nunca me arrependi de investir tempo em automação ou documentação.
  • Vários aplicativos compartilhando um único banco de dados: Me arrependo de vários aplicativos compartilharem um único banco de dados. Isso causou vários problemas.

Adoção de SaaS

  • Adoção tardia de uma plataforma de identidade: Usávamos o Google Workspace para atribuir permissões, mas me arrependo de não ter adotado antes uma solução de identidade como o Okta. O Okta se integra bem e ajuda a resolver questões de segurança e conformidade.
  • Notion: Aprovo usar o Notion para documentação. Foi uma ótima escolha e funcionou com muito mais facilidade do que ferramentas usadas no passado (Wikis, Google Docs, Confluence etc.). O conceito de banco de dados para organizar páginas é útil.
  • Slack: Aprovo usar Slack. É eficaz como ferramenta principal de comunicação.

Ferramentas e serviços de desenvolvimento

  • Migrar de JIRA para Linear: Aprovo usar Linear em vez de JIRA. Acho o JIRA complexo e pesado demais.
  • Não usar Terraform Cloud: Não me arrependo de não usar Terraform Cloud, porque não dava para justificar o custo. Migramos para Atlantis e adicionamos a automação necessária ao pipeline de CI/CD.
  • GitHub Actions para CI/CD: Aprovo mais ou menos (Endorse-ish) usar GitHub Actions. As actions do marketplace e a sintaxe são fáceis de usar. O ponto fraco é o suporte limitado para workflows self-hosted.

Escolhas técnicas

  • Datadog: Me arrependo de usar Datadog. É muito caro, e o modelo de custos não é adequado para clusters Kubernetes e para uma empresa de IA.
  • PagerDuty: Aprovo usar PagerDuty. O produto é bom e o preço é razoável.
  • Migrações de schema por diff: Aprovo em parte usar ferramentas para migrações de schema. Os dados são importantes, e migrações de schema podem ser arriscadas.
  • Ubuntu para servidores de desenvolvimento: Aprovo usar Ubuntu em servidores de desenvolvimento. Tem bom suporte e inclui a maioria dos pacotes necessários.
  • AppSmith: Aprovo usar AppSmith para automação de processos para engenheiros internos. Hospedamos por conta própria e o resultado é suficientemente satisfatório. No começo tentamos usar o retool para buscar integrações mais profundas, mas na época não dava para justificar o preço por apenas algumas integrações.
  • helm: Aprovo usar Helm v3. Há problemas com deploy de CRD e com o treinamento de desenvolvedores, mas é bom o suficiente para empacotar e fazer deploy de objetos do Kubernetes.
  • Charts Helm no ECR (oci): Aprovo armazenar charts Helm em um repositório OCI. Dá menos problema do que a abordagem anterior com S3 e plugins.
  • bazel: Não tenho certeza sobre bazel. Parece exagerado para deploy de serviços em Go, e o GitHub Actions é mais fácil de usar para mais engenheiros.
  • Não usar OpenTelemetry: Me arrependo de enviar métricas usando diretamente a API do DataDog. Recomendo começar com OpenTelemetry desde o início.
  • Escolher renovatebot em vez de dependencyabot: Me arrependo de não ter pensado antes em manter as dependências atualizadas. O Renovatebot é customizável, mas a configuração e o debug são complexos.
  • Kubernetes: Aprovo usar Kubernetes. Era preciso um meio de hospedar serviços de longa duração, e o Kubernetes é popular e funciona bem.
  • Comprar IP próprio: Aprovo comprar um bloco de IP próprio ao trabalhar com parceiros externos. Isso ajuda a fornecer um bloco CIDR maior para whitelist por parte de parceiros externos.
  • Escolher Flux para GitOps em k8s: Não me arrependo de ter escolhido o Flux como ferramenta de GitOps para Kubernetes. Foi necessário desenvolver ferramentas para ajudar a entender o estado dos deploys.
  • Karpenter para gerenciamento de nós: Aprovo usar Karpenter ao usar EKS. É mais confiável e mais eficiente em custo do que outros autoscalers.
  • Usar SealedSecrets: Me arrependo de usar SealedSecrets. Isso é complexo para os desenvolvedores e faz perder a automação existente da AWS para rotação de senhas.
  • Usar ExternalSecrets: Aprovo usar ExternalSecrets para sincronizar senhas da AWS -> Kubernetes. É mais fácil para os desenvolvedores entenderem, e com Terraform é simples gerar/atualizar senhas dentro da AWS.
  • Usar ExternalDNS: Aprovo usar ExternalDNS. Ele sincroniza entradas de DNS do Kubernetes -> Route53 e quase não apresentou problemas nos últimos 4 anos.
  • Usar cert-manager: Aprovo usar cert-manager para gerenciar certificados SSL. É muito intuitivo para gerar certificados do Let's Encrypt e não trouxe problemas.
  • Bottlerocket para EKS: Me arrependo de operar clusters EKS com Bottlerocket. Problemas de CSI de rede aconteciam com frequência e eram difíceis de debugar.
  • Escolher Terraform em vez de CloudFormation: Aprovo usar Terraform. É fácil expandir para outros provedores SaaS e a sintaxe é mais legível do que a do CloudFormation.
  • Não usar uma solução de IaC em código: Não me arrependo. Enquanto Terraform e CloudFormation usam arquivos de dados, Pulumi e CDK descrevem infraestrutura com código. A natureza mais restrita do HCL do Terraform ajuda a reduzir a complexidade.
  • Não usar service mesh: Não me arrependo. Service mesh é algo interessante, mas as empresas tendem a subestimar a complexidade. Um conselho geral para infraestrutura é: “menos é melhor”.
  • Load balancer Nginx para ingress no EKS: Não me arrependo e aprovo usar Nginx. É antigo, mas estável e uma tecnologia já comprovada.
  • homebrew para scripts da empresa: Aprovo usar homebrew para distribuir scripts da empresa. É bom o suficiente para distribuir scripts e binários tanto para usuários de Linux quanto de Mac.
  • Go para serviços: Aprovo usar a linguagem Go para serviços. É fácil para novos engenheiros aprenderem e, no geral, é uma boa escolha.

Leituras relacionadas

4 comentários

 
nicewook 2024-02-28

Tanto o texto principal quanto os comentários têm conteúdo muito valioso.
 
mhj5730 2024-02-28

Nossa... isso é uma informação prática que é difícil de encontrar em qualquer lugar.
 
xguru 2024-02-28

Comentários do Hacker News

  • O custo extra de usar RDS vale a pena

    • O custo adicional de usar RDS parece tão irrealisticamente caro toda vez que se considera substituí-lo por um cluster de SQL Server em colocation que só dá para rir. O valor excede em muito o que eu estaria disposto a pagar, a ponto de cobrir rack em colocation, AWS Direct Connect, servidores, SAN, licenças de SQL Server, contratos de manutenção e até o salário de um DBA interno em tempo integral.
    • Custo total em 12 meses: 547.441,85 USD
    • Quando o ágio fica grande o suficiente para pagar o salário de um ou mais funcionários em tempo integral, vale considerar contratar pessoas em vez de continuar escalando RDS sem pensar. Você está realmente pagando muito para usar RDS, e é preciso reavaliar as decisões tomadas no início da empresa.

  • Pode ser uma opinião impopular dizer que o Google Cloud é melhor que a AWS, mas com o Google Cloud Run dá para rodar contêineres Docker na nuvem como em um sonho. Os nomes dos serviços são simples, há menos serviços importantes do que no conjunto complexo da AWS, e a interface é mais intuitiva. As desvantagens são a falta de tutoriais por causa da comunidade menor, a dificuldade de encontrar gente experiente e a menor disponibilidade de ferramentas de terceiros. Recomendo experimentar.

  • Usar EC2 + ASG é muito prazeroso. Conceitualmente é simples: você lança uma imagem no ASG e configura políticas de auto scaling. Quase não há com o que se preocupar. Em comparação, usar k8s é sempre uma grande operação. Monta-se uma equipe inteira para gerenciar k8s. Introduzem-se dezenas de conceitos do k8s ou investem-se pessoa-anos em “engenharia de plataforma” para esconder esses conceitos. Publicam-se diretrizes, SDKs e vários validadores para permitir usar k8s “do jeito certo”. Mesmo assim, acabam escrevendo dezenas de milhares de linhas de YAML e código para implementar operators. Às vezes fico pensando se o k8s não é intrusivo demais.

  • Opiniões sobre produtos SaaS

    • Não entendo a migração do JIRA para o Linear. O Linear é ok, mas com frequência encontro coisas que ele não consegue fazer ou que eu não sei como fazer.
    • Em geral recomendo usar Terraform Cloud. Fazer seu próprio sistema crescer dentro de casa pode ser aceitável nos primeiros anos, mas no longo prazo isso pode sair caro.
    • Apoio até certo ponto o uso de GitHub Actions para CI/CD. Em vez disso, sugiro usar GitLab.
    • Discordo fortemente sobre o Datadog. É a melhor ferramenta de monitoramento/observabilidade do mercado. O custo é a reclamação mais comum, mas na maioria dos casos os custos explodem porque o Datadog foi configurado de forma errada.
    • Concordo sobre o Pagerduty. O Pagerduty custa cerca de 10 vezes mais que o Opsgenie e não oferece recursos melhores. Ao renovar contrato com o Pagerduty, perguntei ao vendedor quais funcionalidades eles tinham que o Opsgenie não tinha, e a resposta foi que eles queriam se posicionar como a marca premium do mercado. Então estou satisfeito em usar a marca comum para relatórios de incidentes.

  • Consigo imaginar um desenvolvedor dos anos 90/2000 lendo esta lista e ficando confuso com tanta complexidade e terminologia.

  • Leitura interessante, mas não tenho certeza de que seja alguém com arrependimentos suficientes para justificar escrever um post de blog.

  • Sinto vontade de experimentar voltar para um único servidor gigantesco de US$ 100 mil e rodar tudo em uma única máquina.

  • Consegui aprender o básico de Kubernetes / EKS, mas estou pensando em migrar para ECS. O Kubernetes é complexo demais para as nossas necessidades. É difícil controlá-lo com algo como CloudFormation. Os load balancers provisionados pelos add-ons são difíceis de referenciar fora do Kubernetes. No EKS Fargate, o logging para o Cloudwatch não parece funcionar mesmo seguindo a documentação. As métricas de CPU/memória também não funcionam como no EKS EC2, e parece que é preciso usar ADOT. No ECS, reconfigurei o ambiente em um décimo do tempo e tudo funcionou bem.

  • Gosto da forma como este texto foi escrito e do conteúdo. Discordo de algumas decisões e recomendações, mas mesmo nesses casos é excelente ler os motivos. Seria bom ver mais textos parecidos sendo publicados e ter uma forma de compará-los. Fiquei inspirado a escrever algo semelhante.

  • O banco de dados “pia de cozinha” que todo mundo usa é um problema comum, mas continua se repetindo. Quando a empresa cresce, isso vira uma dívida técnica considerável e um gargalo de desempenho. Com um banco gerenciado como o RDS, fica fácil operar clusters de banco de dados separados para cada aplicativo principal.