Defina a infraestrutura além do protótipo

Comece pelo sistema gerado

Considere uma plataforma fictícia de prototipagem. Ela cria um contêiner web, um banco de dados PostgreSQL gerenciado e uma URL pública. O fluxo funciona corretamente com registros de exemplo. É um resultado útil: as pessoas podem avaliar a funcionalidade antes de financiar uma implementação maior.

Agora a empresa quer armazenar contratos confidenciais e usar seu provedor de identidade de funcionários. O sistema necessário mudou. Um deployment bem-sucedido de contêiner não comprova autorização, tratamento aprovado de dados, capacidade de recuperação nem responsabilidade pelo serviço.

Plataformas diferentes de desenvolvimento oferecem capacidades diferentes. Inspecione o serviço e a configuração reais. Não presuma que toda ferramenta de prototipagem tenha os mesmos limites ou que um nome conhecido de nuvem atenda à política da empresa.

Faça sete perguntas sobre produção

As respostas podem usar serviços corporativos existentes. Não é necessário construir um novo sistema de identidade ou plataforma de monitoramento para cada aplicação. Conecte-se às capacidades aprovadas e registre as lacunas restantes.

O AWS Well-Architected considera operação, segurança, confiabilidade, desempenho, custo e sustentabilidade em conjunto. Isso ajuda a lembrar que um deployment funcional é apenas uma parte da avaliação de arquitetura. Leia o framework.

Defina limites entre ambientes

Identifique os recursos de desenvolvimento, teste e produção. Defina quais identidades podem atravessar esses limites. Não copie registros de produção para um ambiente conveniente de preview sem um processo aprovado de tratamento.

Inspecione conexões de saída e acesso de entrada. Um banco de dados privado ainda pode enviar dados a um serviço público de logs por meio da aplicação. As chamadas do agente de programação ao modelo são outro fluxo a avaliar separadamente.

Registre quem é responsável pela conta de nuvem, pelo DNS, pelo certificado, pelas chaves de criptografia e pela relação de cobrança. Um projeto que depende da conta pessoal de um funcionário que está saindo tem um problema de responsabilidade, mesmo que o código da aplicação esteja disponível.

Teste a divisão de responsabilidades

Um provedor de banco de dados gerenciado pode operar o serviço subjacente enquanto sua organização controla usuários, acesso a dados, alterações de schema e configurações de retenção. A divisão exata depende do serviço e do contrato. Solicite-a explicitamente.

Para a aplicação de contratos, execute um exercício fictício de restauração. Meça o tempo real de recuperação e identifique a possível perda de dados. Compare o resultado com o requisito do negócio. Uma caixa marcada como “backups ativados” não é a mesma evidência.

Teste também o desligamento de acesso. Remova um funcionário fictício da fonte de identidade e verifique a alteração de acesso pretendida. Inclua sessões ativas, papéis de administrador e identidades de automação no projeto.

Conecte a infraestrutura ao sistema de entrega

Definições de infraestrutura, configuração de ambientes, pipelines e código da aplicação precisam de alterações coordenadas. Um agente deve planejar com base no ambiente de destino real. Caso contrário, pode gerar um deployment que contrarie requisitos de rede, identidade ou responsabilidade.

É nesse ponto que engenharia de plataforma e fábrica de software se encontram. A plataforma fornece capacidades suportadas e limites. O sistema de entrega deve usá-los, produzir evidências e preservar uma transferência clara de responsabilidade operacional. Continue com engenharia de plataforma.