Após quatro anos liderando a infraestrutura de uma startup que precisou escalar rapidamente, compartilho algumas decisões cruciais e suas consequências. Entre elas, a escolha da AWS em detrimento do Google Cloud se mostrou acertada, principalmente pelo suporte e estabilidade oferecidos pela Amazon, o que foi essencial na avaliação de novos serviços AWS. Ainda que o Google Cloud fosse a preferência inicial para clusters Kubernetes, a AWS superou as expectativas com integrações adicionais, tornando a escolha por EKS vantajosa, apesar de alguns arrependimentos relacionados ao uso inicial de addons gerenciados do EKS.

A utilização do RDS para gerenciamento de dados se confirmou como uma decisão sábia, considerando o alto custo de perda de dados. Redis destacou-se como uma escolha eficaz para cache e outras funções rápidas de dados. A migração para o ECR a partir do quay.io também foi uma decisão que trouxe maior estabilidade e integração com os serviços AWS. Em relação à VPN, a simplicidade de configuração e a gestão pelo Okta provaram ser eficientes, apesar dos altos custos.

A adoção do AFT facilitou a automação e padronização de tags para contas AWS, enquanto que a integração de processos de pós-morte com bots do Slack otimizou a responsabilização e seguimento dos procedimentos. A utilização de templates de incidentes do PagerDuty e a revisão regular dos tickets ajudaram a priorizar alertas críticos. As reuniões mensais para rastreamento de custos mostraram-se essenciais para o controle financeiro e técnico.

Falhas foram reconhecidas na gestão de pós-mortes através de integrações com DataDog e PagerDuty, assim como na abordagem inicial de não adotar uma plataforma de identidade como a Okta e na resistência em utilizar FaaS para workloads de CPU. A escolha do GitOps foi altamente endossada por sua flexibilidade, e a eficiência da equipe foi sempre priorizada em detrimento de demandas externas.

Compartilhar uma base de dados entre múltiplas aplicações foi um erro, criando débitos técnicos e responsabilidade difusa. No campo do SaaS, a adoção tardia de uma plataforma de identidade e a escolha do Notion e do Slack foram decisões bem-sucedidas, enquanto que o JIRA foi criticado por sua complexidade. A migração para o Atlantis e a escolha do GitHub Actions sobre o CircleCI foram movimentos estratégicos.

O Datadog, apesar de ser um bom produto, revelou-se caro, especialmente para clusters Kubernetes e empresas de IA. O PagerDuty, por outro lado, teve uma boa relação custo-benefício. No desenvolvimento de software, a gestão de esquemas por diff, a escolha do Ubuntu para servidores de desenvolvimento e a automação de processos internos com AppSmith foram endossados.

O helm v3 e o armazenamento de helm charts em ECR(oci) provaram ser eficientes, enquanto que o uso do Bazel foi questionável. A não adoção precoce do Open telemetry foi um arrependimento, mas o uso do Renovatebot para manter as dependências atualizadas foi positivo. No que tange à infraestrutura, o Kubernetes foi a escolha certa, e a compra de IPs próprios foi vantajosa para parceiros externos.

A decisão entre ArgoCD e Flux para GitOps no Kubernetes favoreceu o Flux, enquanto que o Karpenter se destacou na gestão de nós. A gestão de segredos por meio de ExternalSecrets e de DNS com ExternalDNS foi bem-sucedida, assim como o uso do cert-manager para gerenciamento de certificados SSL. A escolha de AMIs otimizadas para EKS em vez de Bottlerocket foi mais confiável, e o Terraform foi preferido ao CloudFormation para IaC.

A escolha contra o uso de uma malha de rede como istio/linkerd foi justificada pela complexidade desnecessária, e a utilização do Nginx como balanceador de carga para ingressos EKS foi considerada confiável. A distribuição de scripts e binários pela empresa com o Homebrew foi eficaz, e a linguagem Go foi recomendada para serviços de IO de rede. Em suma, as experiências compartilhadas servem como um guia para outras startups em seus caminhos de crescimento e infraestrutura.