Airframe em dez minutos

O Airframe é uma forma de operar infraestrutura na nuvem para muitas equipes de produto em que ninguém constrói nada à mão em um console e ninguém tem acesso de administrador permanente. Uma equipe descreve o que quer em arquivos, regras escritas como código verificam cada mudança, e os pipelines fazem o trabalho. Esta página acompanha um produto durante toda a sua vida, do dia em que uma equipe o pede até o dia em que ele é removido.

Os exemplos vêm de uma organização de demonstração, uma loja on-line fictícia, e do seu produto de pedidos. As palavras em negrito são as que o glossário explica.

1. Uma equipe quer um produto novo

Em muitas empresas, uma equipe que precisa de um serviço novo preenche um formulário ou abre um chamado, e espera enquanto alguém cria à mão os projetos na nuvem, um repositório de código, as regras de rede e os painéis. Cada um desses passos é uma chance de erro, e depois ninguém consegue ver com facilidade por que as coisas foram configuradas daquele jeito.

No Airframe, ninguém faz esses passos à mão. A equipe pede mudando um arquivo, e a plataforma faz o resto.

2. Ela escreve um arquivo no catálogo

O catálogo é um repositório git de pequenos arquivos YAML que descrevem a organização: como ela divide seu trabalho em jornadas, domínios e contextos, quais equipes e pessoas existem, e quais produtos estão a cargo de cada uma.

Para criar o produto de pedidos, a equipe adiciona um arquivo, products/shop.store.ordering.orders.yaml. Ele diz qual equipe é dona do produto, qual pilha ele usa (Java, Node ou Python), o quanto ele é crítico, em quanto tempo precisa se recuperar de uma falha, e seu orçamento mensal em dólares americanos. Esse arquivo é o pedido inteiro.

3. As regras verificam e os responsáveis aprovam

O arquivo novo chega como um merge request, como toda mudança no Airframe. O pipeline do catálogo o verifica contra o esquema do catálogo e suas regras de coerência, por exemplo, que a equipe dona pertence de fato ao contexto do produto.

Depois, as pessoas aprovam para que serve a mudança. O próprio catálogo diz quem é responsável pelo quê: um produto novo é aprovado pela sua equipe ou pelos líderes do seu contexto ou do seu domínio. Um serviço chamado controle de aprovação lê essas regras de propriedade e aprova o merge request só quando as pessoas certas já o aprovaram. A aprovação do próprio autor nunca conta.

4. Os pipelines constroem tudo

Depois do merge, o pipeline do catálogo inicia uma cadeia de reconciliadores: jobs automáticos que leem o catálogo e fazem o mundo real corresponder a ele. Juntos, eles criam:

• dois projetos do Google Cloud para o produto, um de produção e outro para todo o resto, cada um com suas próprias identidades de pipeline;
• um repositório de código, gerado a partir do template do golden path para a pilha escolhida;
• painéis para o serviço do produto, suas metas de confiabilidade e seu custo;
• um nome de host atrás de login único, assim que o primeiro pipeline do produto o implanta.

Os painéis ficam em um único stack do Grafana Cloud, aonde também chegam os logs, as métricas e os traces do produto; observabilidade acompanha esse caminho.

Uma nota no merge request já integrado acompanha a cadeia enquanto ela roda, para que a equipe veja seu produto sendo construído. Um passo fica separado de propósito: um produto novo só funciona quando seus projetos são vinculados ao faturamento, o que é um merge request próprio no repositório landing-zone.

5. A equipe muda seu produto com merge requests

A partir daí, a equipe trabalha no seu próprio repositório, que guarda a aplicação, sua infraestrutura como código Terraform e seu pipeline. Toda mudança é um merge request, e todo merge request passa pelos mesmos passos:

• jobs que a equipe não pode remover verificam a mudança, entre eles o pacote de políticas: regras testadas que recusam, por exemplo, um bucket de armazenamento aberto para a internet;
• os responsáveis pelo produto aprovam, e depois o controle de aprovação também;
• o executor, um pipeline confiável que o controle de aprovação inicia no runner confiável da plataforma, planeja a mudança com as identidades do próprio produto: calcula exatamente o que a mudança faria na nuvem e quanto custaria por mês;
• o executor também implanta uma prévia da mudança, uma cópia de curta duração do produto no seu próprio nome de host, para que quem revisa possa testá-la antes do merge;
• uma verificação mantém o merge fechado enquanto esse custo estiver acima do orçamento do produto.

Depois do merge, o pipeline da branch principal aplica a mudança. Ninguém roda um comando contra a nuvem a partir de um notebook. O merge também publica a página do produto no catálogo de arquitetura, um mapa de cada produto, seus eventos e seus responsáveis.

6. Ninguém tem acesso de escrita permanente

As contas de uso diário das pessoas podem ver a infraestrutura de produção, mas não mudá-la; a única exceção, bem restrita, é adicionar uma versão nova de um dos segredos do seu produto. Os pipelines recebem identidades de curta duração pela federação de identidade de carga de trabalho: um job prova a qual repositório pertence, em qual ambiente implanta e se sua branch é protegida, e só o job certo recebe a identidade certa.

Quando uma pessoa realmente precisa mudar algo à mão, ela pede uma concessão do Privileged Access Manager: com tempo limitado, registrada e, para papéis administrativos, aprovada por outro membro da equipe de plataforma. Ninguém pode criar uma chave de conta de serviço, a senha de longa duração de uma conta de máquina, para nenhum projeto da organização de demonstração.

7. Um agente de código trabalha com os mesmos controles

O Airframe foi projetado desde o início com um agente de código como colaborador. As skills do repositório platform-skills ensinam a um agente de código os padrões da plataforma, e airframe validate roda em um notebook a maior parte da validação do merge request, para que um agente de código corrija seus erros antes de abrir um merge request.

Depois, o merge request do agente de código passa exatamente pelos mesmos controles que o de uma pessoa. A aprovação que permite o merge precisa vir de uma pessoa nomeada no catálogo que não escreveu a mudança.

8. Quando o produto é aposentado, o mesmo arquivo diz

Encerrar um produto também é uma mudança no seu arquivo do catálogo. Mudar seu status para retiring tira seus serviços da borda compartilhada, de modo que deixam de responder nos seus nomes de host, e os leva a zero instâncias, mas mantém seus dados. Depois da data de aposentadoria escrita na entrada, removed exclui seus projetos e seu repositório. Cada mudança de status precisa de dois aprovadores além do autor.

O nome nunca é reutilizado: um produto removido deixa uma lápide no catálogo, de modo que um produto novo não pode usar seu nome no mesmo domínio. O produto de pedidos da organização de demonstração está sendo aposentado hoje.

Para onde ir agora

• O glossário define cada termo desta página em uma ou duas frases.
• A seção de Conceitos aprofunda um nível em cada ideia: o catálogo, os reconciliadores, as identidades e o acesso, o controle de aprovação e o executor, as políticas como código, as versões da plataforma, as prévias, a observabilidade e o catálogo de arquitetura.
• Como funciona acompanha passo a passo a vida de um produto e o caminho de uma mudança, com os tempos medidos pela própria plataforma.
• As nove páginas de “por quê” explicam o que distingue o Airframe, cada uma com o mecanismo que o torna verdade: comece por autosserviço por merge request e zero privilégio permanente.