Definir a infraestrutura para além do protótipo

Comece pelo sistema gerado

Considere uma plataforma fictícia de prototipagem. Cria um contentor web, uma base de dados PostgreSQL gerida e um URL público. O fluxo funciona corretamente com registos 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 o seu fornecedor de identidade dos trabalhadores. O sistema necessário mudou. Um deployment bem-sucedido do contentor não estabelece autorização, tratamento de dados aprovado, capacidade de recuperação nem responsabilidade pelo serviço.

As plataformas de desenvolvimento oferecem capacidades diferentes. Examine o serviço e a configuração reais. Não presuma que todas as ferramentas de prototipagem têm os mesmos limites nem que um nome cloud conhecido satisfaz a política da empresa.

Faça sete perguntas de produção

As respostas podem recorrer a serviços empresariais existentes. Não precisa de criar um novo sistema de identidade nem uma plataforma de monitorização para cada aplicação. Ligue-se às capacidades aprovadas e registe as lacunas restantes.

O AWS Well-Architected considera em conjunto operação, segurança, fiabilidade, desempenho, custo e sustentabilidade. É um lembrete útil de que um deployment funcional é apenas uma parte da avaliação da arquitetura. Leia o referencial.

Defina os limites entre ambientes

Identifique os recursos de desenvolvimento, teste e produção. Defina que identidades podem atravessar estes limites. Não copie registos de produção para um ambiente de pré-visualização conveniente sem um processo de tratamento aprovado.

Examine as ligações de saída e o acesso de entrada. Uma base de dados privada pode ainda alimentar um serviço público de logs através da aplicação. As chamadas do agente de programação ao modelo são outro fluxo a avaliar separadamente.

Registe quem é responsável pela conta cloud, pelo DNS, pelo certificado, pelas chaves de cifra e pela relação de faturação. Um projeto que depende da conta pessoal de um trabalhador que sai da empresa tem um problema de responsabilidade, mesmo quando o código da aplicação está disponível.

Teste a divisão de responsabilidades

Um fornecedor de base de dados gerida pode operar o serviço subjacente enquanto a sua organização controla os utilizadores, o acesso aos dados, as alterações do esquema e as definições de retenção. A divisão exata depende do serviço e do contrato. Peça que seja explícita.

Para a aplicação de contratos, execute um exercício fictício de restauro. Meça o tempo real de recuperação e identifique possíveis perdas de dados. Compare o resultado com o requisito do negócio. Uma caixa de seleção com o rótulo «cópias de segurança ativas» não constitui a mesma evidência.

Teste também a remoção do acesso quando um trabalhador sai. Remova um trabalhador fictício da fonte de identidade e verifique a alteração de acesso pretendida. Inclua as sessões ativas, as funções de administrador e as identidades de automação na conceção.

Ligue a infraestrutura ao sistema de entrega

As definições de infraestrutura, a configuração dos ambientes, os pipelines e o código da aplicação precisam de alterações coordenadas. Um agente deve planear tendo em conta o ambiente de destino real. Caso contrário, pode gerar um deployment incompatível com os requisitos de rede, identidade ou responsabilidade.

É aqui que a engenharia de plataformas e uma fábrica de software se encontram. A plataforma fornece capacidades suportadas e limites. O sistema de entrega tem de os usar, produzir evidências e preservar uma passagem clara de responsabilidades para a operação. Continue com a engenharia de plataformas.