Projete software para um ambiente cloud native

Defina o comportamento necessário

Práticas cloud native apoiam desenvolvimento e operação repetíveis em ambientes públicos, privados ou híbridos. A CNCF enfatiza sistemas que continuam gerenciáveis, observáveis e resilientes conforme mudam. Contêineres e orquestração podem apoiar essa abordagem. Não estabelecem todas essas propriedades sozinhos.

Comece com um serviço fictício de relatórios. Uma ferramenta de IA cria um endpoint, um worker e uma imagem de contêiner. Uma demonstração produz o PDF correto. Antes da produção, a equipe precisa responder a outra pergunta: o que acontece quando a plataforma substitui o worker durante um job?

Essa é uma questão de projeto da aplicação e de infraestrutura. Uma reinicialização pode restaurar um processo e perder seu trabalho incompleto.

Separe o processo do estado durável

O protótipo mantém os jobs na fila e os relatórios concluídos no disco do contêiner. Substituir o contêiner pode remover ambos. Acrescentar workers também pode produzir respostas diferentes dependendo de qual recebe a requisição.

O projeto revisado usa um armazenamento durável de jobs e um armazenamento de objetos aprovado. Uma requisição registra a identidade de um job. Um worker assume o job, cria seu resultado e registra a localização desse resultado. As verificações de acesso continuam valendo quando um usuário baixa o relatório.

Mantenha segredos fora da imagem. Forneça-os pelo sistema aprovado de segredos. Registre quais alterações de configuração exigem um novo release ou uma reinicialização do processo.

Projete as novas tentativas antes de acrescentar workers

Suponha que o worker salve um PDF e pare antes de confirmar o job. A fila entrega o job novamente. Uma segunda tentativa não deve gerar uma segunda cobrança ao cliente nem enviar mensagens conflitantes de conclusão.

Use uma operação idempotente quando for adequado. Repetir a mesma requisição lógica deve preservar o efeito pretendido. Defina uma identidade estável de requisição, registre o resultado de forma durável e verifique o que acontece em cada ponto de falha. A AWS descreve essa técnica no guia de novas tentativas seguras.

Novas tentativas também precisam de limites. Use tempo limite, limite de tentativas e um intervalo que evite requisições repetidas simultâneas. Preserve o trabalho que falhou para inspeção em vez de repeti-lo indefinidamente.

Torne o estado desejado fácil de revisar

Uma configuração declarativa informa o deployment pretendido. Um controlador trabalha para manter esse estado. Por exemplo, um Kubernetes Deployment gerencia réplicas da aplicação e atualizações controladas. A aplicação ainda precisa lidar corretamente com a substituição.

Versione a infraestrutura e a configuração da aplicação. Revise alterações pelo processo normal de entrega. Observe a conclusão real dos jobs, o tempo que permanecem na fila, as falhas e os limites das dependências. Um processo em execução ainda pode ser incapaz de produzir um relatório.

Escolha uma plataforma que a equipe consiga operar

Cloud native não exige transformar toda aplicação em microsserviços. Uma aplicação modular em um runtime gerenciado pode atender aos seus requisitos. Mais serviços introduzem mais interfaces, decisões de deployment e trabalho operacional.

Dê ao agente de desenvolvimento o contrato real da plataforma: runtime suportado, método de identidade, serviços de dados, regras de deployment e evidências exigidas. Teste o comportamento de interrupção e substituição junto com as requisições bem-sucedidas. Continue com disponibilidade e limites de falha.