Pular para o conteúdo principal

Objetivos e Não-Objetivos

Objetivos​

O1 — Caminhos Dourados para Todos os Fluxos Comuns​

Fornecer templates do Backstage Scaffolder para todas as operações padrão da plataforma: criação de domínio, sistema, serviço, recurso de nuvem, equipe e usuário. Um desenvolvedor nunca deve precisar escrever YAML do ArgoCD, manifestos Kubernetes ou Claims do Crossplane manualmente.

O2 — Uma Chave Semântica em Todos os Sistemas​

Todo recurso — namespace, aplicação ArgoCD, entidade Backstage, claim Crossplane — é endereçável pela mesma chave de três segmentos: {project}-{env}-{service}. Zero tradução manual entre sistemas.

O3 — Self-Service em Menos de 30 Minutos​

Do primeiro template no Backstage até o serviço rodando no cluster de dev: menos de 30 minutos, sem nenhuma intervenção da equipe de plataforma.

Todo serviço, recurso de nuvem, equipe e usuário está no catálogo do Backstage. Saúde, status de sincronização e propriedade de recursos são visíveis em uma única página por componente — em todos os ambientes e clusters.

O5 — Reconciliação Contínua de Recursos de Nuvem​

Infraestrutura de nuvem (bancos de dados, clusters, filas) é declarada como Claims do Crossplane no Git e reconciliada continuamente. O drift é detectado e corrigido automaticamente. A exclusão acidental é prevenida por deletionPolicy: Orphan em recursos de produção.

O6 — RBAC de Menor Privilégio Aplicado por Convenção​

O acesso ao Kubernetes e ao ArgoCD é concedido via sujeitos de Grupo, não indivíduos. O papel developer é bloqueado em namespaces de produção no nível de RBAC — não por convenção ou documentação. O acesso a produção exige elevação explícita de papel.

O7 — Validação de Convenção na CI​

Todo repositório GitOps de domínio executa um pipeline de validação em cada PR que verifica nomenclatura, labels obrigatórias, limites de recursos e conformidade do schema YAML. Violações de convenção reprovam o PR automaticamente.

Não-Objetivos​

  • Não substitui pipelines de CI — a plataforma gerencia CD (ArgoCD). CI (build, teste, publicação de imagem) permanece nos pipelines existentes.
  • Não gerencia código da aplicação — a plataforma possui repositórios GitOps, não repositórios de código-fonte de aplicação.
  • Não é uma oferta de serviço gerenciado — o IDP é apenas interno, não é infraestrutura voltada ao cliente.
  • Não é uma plataforma de gestão de custos — visibilidade de custos de nuvem é uma fase futura.
  • Não substitui todo o Terraform — o Crossplane gerencia recursos de nuvem de plataforma e de domínio. O Terraform existente para bootstrap de nível de conta (VPCs, raízes IAM) permanece em vigor.