Tudo numa conta
É o ponto de partida mais habitual: uma só conta (ou subscrição, ou projeto) onde convivem desenvolvimento, testes e produção, de várias aplicações e várias equipas. Funciona enquanto é pequeno. Depois, cada permissão que se dá é demasiado ampla, cada erro pode alcançar a produção e ninguém sabe que parte da fatura é de quem.
Uma hierarquia com intenção
Os três grandes fornecedores permitem organizar as suas contas numa hierarquia (com nomes diferentes em cada um: organizações e unidades, grupos de administração e subscrições, organização e pastas). A estrutura que funciona melhor costuma ter estes níveis:
- A organização, com as regras que valem para tudo.
- Unidades por propósito: plataforma partilhada (rede, identidade, registos), cargas de trabalho de negócio, espaços isolados para experimentar.
- Ambientes dentro de cada unidade: desenvolvimento, aceitação, produção, separados a sério.
- Contas por aplicação ou equipa, com o seu responsável.
O que se ganha sem escrever uma única regra
Isolamento. Um erro ou um ataque na conta de desenvolvimento de uma aplicação não alcança a produção de outra.
Permissões delimitadas. Dar acesso à «conta de aceitação de encomendas» é muito mais preciso do que dar acesso a uma conta partilhada.
Custo atribuído por construção. Tudo o que acontece numa conta já tem responsável (a forma mais robusta de atribuir o custo).
Políticas por nível. O que se aplica a uma unidade é herdado por todas as suas contas, como veremos dois artigos mais adiante.
Desenhá-la no início
Mover recursos entre contas depois é custoso e às vezes impossível sem os recriar. Por isso a estrutura desenha-se no início, escreve-se na norma e cria-se com infraestrutura como código, para que cada conta nova nasça no seu lugar e com as suas regras.
Uma estrutura de contas bem feita multiplica o número de contas. E isso traz a pergunta seguinte: como saber quem é quem em todas elas.
Como o aplicamos: Governo Multicloud.