Para Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia, migrar uma aplicação para a nuvem e escrevê-la para nascer na nuvem são coisas diferentes, mesmo que o resultado final rode no mesmo provedor de cloud. No primeiro caso, o software continua pressupondo um servidor fixo, com memória e disco que sobrevivem entre reinicializações. No segundo, cada decisão de código já assume que a máquina por baixo pode desaparecer a qualquer momento, sem aviso, e que isso não deveria derrubar nada.
É nessa diferença que mora o que se chama de cloud nativa: não o lugar onde o sistema roda, mas o conjunto de premissas com que ele foi projetado. Essa confusão entre “estar na nuvem” e “ser cloud nativo” ainda gera projetos que pagam a conta da nuvem sem colher o ganho real de elasticidade e resiliência que ela oferece.
Statelessness deixa de ser boa prática e vira exigência
Em arquiteturas tradicionais, manter estado em memória local era um atalho aceitável, já que o servidor raramente mudava. Em ambientes cloud nativos, esse hábito quebra o sistema na primeira vez que uma instância é substituída, o que acontece com frequência em escalonamento automático.
Por isso, aplicações cloud nativas precisam externalizar estado para bancos de dados, caches distribuídos ou filas, tratando cada instância de código como descartável. Jean Pierre Lessa e Santos Ferreira destaca que essa mudança de mentalidade costuma ser mais difícil de implantar do que qualquer ferramenta nova, porque exige reescrever suposições que estavam implícitas no código há anos.
Design para falha muda o que o desenvolvedor testa
Quando o servidor pode morrer a qualquer momento, testar apenas o caminho feliz deixa de ser suficiente. O desenvolvedor cloud-nativo precisa simular timeouts, reinícios abruptos e indisponibilidade parcial de dependências como parte normal do ciclo de testes, não como exceção rara.
Padrões como circuit breaker e retry com backoff exponencial passam a ser parte do código de negócio, não um detalhe de infraestrutura. Jean Pierre Lessa e Santos Ferreira aponta que ignorar esses padrões costuma gerar sistemas frágeis, que passam despercebidos até o primeiro pico real de tráfego, quando um único componente lento derruba toda a cadeia em cascata.
Deploy contínuo exige decisões que antes eram raras
Em ciclos de deploy mensais, um erro de compatibilidade entre versões tinha tempo de ser descoberto e corrigido antes de afetar muitos usuários. Em pipelines cloud nativos, com múltiplos deploys por dia, versões antigas e novas do mesmo serviço convivem simultaneamente durante a transição.
Jean Pierre Lessa e Santos Ferreira avalia que isso obriga times a projetar compatibilidade retroativa em contratos de API como regra, não como cortesia ocasional. Uma mudança que quebra um contrato de dados pode derrubar serviços que dependem dele, mesmo sem qualquer erro de código na nova versão, apenas pela incompatibilidade entre o que foi publicado e o que ainda está em uso.
Orquestração assume o que antes era responsabilidade manual
Ferramentas de orquestração, como Kubernetes, tiraram do operador humano a tarefa de decidir, em tempo real, quantas instâncias de um serviço devem existir e onde. Essa automação só funciona bem, porém, quando o código informa corretamente seu próprio estado de saúde.
Jean Pierre Lessa e Santos Ferreira reforça que declarar sondas de prontidão e vivacidade de forma precisa é parte do trabalho de desenvolvimento, não um ajuste de configuração feito depois. Um serviço que reporta estar saudável quando, na verdade, está travado engana o orquestrador e prolonga uma falha que poderia ter sido isolada em segundos. Essa disciplina, mais do que qualquer ferramenta, costuma distinguir times de alta performance de equipes que apenas replicam configurações prontas sem entender o motivo de cada limite declarado.
O que sobra quando a infraestrutura deixa de ser o centro da decisão?
Cloud nativa desloca o centro de gravidade da engenharia de software. Menos tempo dedicado a administrar servidores individuais, mais tempo dedicado a projetar como o sistema se comporta quando algo dá errado, porque algo sempre dá errado em escala. Essa mudança de foco explica por que equipes que apenas trocam de provedor sem revisar essas premissas continuam sofrendo os mesmos problemas de sempre, só que em um ambiente mais caro.
Jean Pierre Lessa e Santos Ferreira resume essa transição como um deslocamento de prioridade dentro da arquitetura de soluções da empresa, não uma questão de ferramentas isoladas: o ganho verdadeiro aparece quando o time para de tratar a resiliência como responsabilidade da infraestrutura e passa a tratá-la como parte do design do software desde a primeira linha de código.
