Solucionado (ver solução)

Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

Solucionado
(ver solução)
1
resposta

[Dúvida] Grupo de Recursos

Uma duvida sobre os grupos de recursos, o ideal é criar um grupo pro projeto? exemplo se eu tenho um projeto chamada 'CRM' e outro chamado 'supplies', devo criar um grupo para cada um deles ou é um único grupo para todos os projetos que eu trabalhe dentro da empresa?

1 resposta
solução!

Olá, Eduar! Como vai?

A recomendação da própria Microsoft é agrupar recursos por ciclo de vida, e na prática isso quase sempre significa um grupo por projeto. No seu exemplo, CRM e supplies teriam grupos separados. O raciocínio é: se um dia o projeto de supplies for descontinuado, você exclui o grupo inteiro sem correr o risco de derrubar algo que o CRM ainda precisa. Um grupo único para tudo transforma cada exclusão em uma operação delicada.

E aém do ciclo de vida, a separação traz três ganhos imediatos: permissões via RBAC aplicadas por projeto em vez de por recurso individual, custos visíveis por grupo no Cost Management sem precisar cruzar tags manualmente, e limites de blast radius quando alguém aplica uma política ou um lock.

Uma dica interessante para o futuro é combinar a separação com uma convenção de nomes que já indique projeto e ambiente. Assim:

az group create --name rg-crm-prod --location eastus2
az group create --name rg-crm-dev --location eastus2
az group create --name rg-supplies-prod --location eastus2

Isso faz com que produção e desenvolvimento de um mesmo projeto também fiquem isolados, o que evita que um teste em dev afete o que está no ar e permite dar acesso ao ambiente de desenvolvimento sem abrir produção para o time inteiro.

Se quiser aprofundar ainda mais, algumas boas práticas são:

  • Ciclo de vida como critério: recursos que nascem e morrem juntos ficam no mesmo grupo; um banco de dados compartilhado por vários projetos merece um grupo próprio, tipo rg-shared-data.
  • Tags complementares: mesmo com grupos separados, marcar projeto, ambiente e centro-de-custo facilita relatórios que cruzam projetos.
  • Hierarquia acima do grupo: quando a empresa cresce, assinaturas e grupos de gerenciamento entram como camadas superiores para aplicar políticas em escala, e os grupos de recursos continuam sendo a unidade mais granular.

Ah, uma pergunta: no seu cenário, o que pesaria mais na hora de decidir a separação: a facilidade de excluir tudo de um projeto de uma vez ou o controle de custos separado por área?

Alguns materiais podem estar em inglês, mas é possível compreendê-los usando o recurso de tradução de páginas do próprio navegador.

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!