Conceber software para um ambiente cloud native

Defina o comportamento de que precisa

As práticas cloud native apoiam o desenvolvimento e a operação repetíveis em ambientes públicos, privados ou híbridos. A CNCF destaca sistemas que permanecem geríveis, observáveis e resilientes à medida que mudam. Os contentores e a orquestração podem apoiar esta abordagem. Não estabelecem todas estas propriedades por si só.

Comece por um serviço fictício de relatórios. Uma ferramenta de IA cria um endpoint, um worker e uma imagem de contentor. Uma demonstração produz o PDF correto. Antes da produção, a equipa tem de responder a outra pergunta: o que acontece quando a plataforma substitui o worker durante uma tarefa?

Esta é uma questão de conceção da aplicação, além de infraestrutura. Um reinício pode repor um processo e perder o seu trabalho inacabado.

Separe um processo do estado duradouro

O protótipo guarda as tarefas em fila e os relatórios concluídos no disco do contentor. A substituição do contentor pode remover ambos. Acrescentar mais workers também pode produzir respostas diferentes consoante o worker que recebe um pedido.

A conceção revista usa um armazenamento duradouro de tarefas e um armazenamento de objetos aprovado. Um pedido regista a identidade de uma tarefa. Um worker assume a tarefa, cria o resultado e regista a localização desse resultado. As verificações de acesso continuam a aplicar-se quando um utilizador descarrega o relatório.

Mantenha os segredos fora da imagem. Forneça-os através do sistema aprovado de segredos. Registe que alterações de configuração exigem um novo lançamento ou o reinício de um processo.

Conceba as novas tentativas antes de acrescentar workers

Suponha que o worker guarda um PDF e depois para antes de confirmar a tarefa. A fila entrega novamente a tarefa. Uma segunda tentativa não deve criar uma segunda cobrança ao cliente nem enviar mensagens contraditórias de conclusão.

Use uma operação idempotente quando adequado. Repetir o mesmo pedido lógico deve preservar o efeito pretendido. Defina uma identidade estável do pedido, registe o resultado de forma duradoura e verifique o que acontece em cada ponto de falha. A AWS descreve esta técnica no seu guia de novas tentativas seguras.

As novas tentativas também precisam de limites. Use um timeout, um limite de tentativas e um intervalo que evite pedidos repetidos simultâneos. Preserve o trabalho falhado para inspeção em vez de o repetir indefinidamente.

Torne o estado pretendido passível de revisão

Uma configuração declarativa indica o deployment pretendido. Um controlador procura manter esse estado. Por exemplo, um Deployment de Kubernetes gere réplicas da aplicação e atualizações controladas. A aplicação continua a ter de tratar corretamente a substituição.

Mantenha a configuração da infraestrutura e da aplicação sob controlo de versões. Reveja as alterações através do processo normal de entrega. Observe a conclusão real das tarefas, o tempo de espera na fila, as falhas e os limites das dependências. Um processo em execução pode continuar a não conseguir produzir um relatório.

Escolha uma plataforma que a equipa consiga operar

Cloud native não exige transformar todas as aplicações em microsserviços. Uma aplicação modular num ambiente de execução gerido pode cumprir os seus requisitos. Mais serviços introduzem mais interfaces, decisões de deployment e trabalho operacional.

Forneça ao agente de desenvolvimento o contrato real da plataforma: ambiente de execução 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, além dos pedidos bem-sucedidos. Continue com a disponibilidade e os limites de falha.