Platform engineering: construindo a plataforma interna que seu time precisa

1. Fundamentos do Platform Engineering

Platform Engineering é a disciplina de projetar, construir e manter uma plataforma interna para desenvolvedores (Internal Developer Platform — IDP) que abstrai a complexidade da infraestrutura subjacente. Diferente do DevOps tradicional, que frequentemente delega responsabilidades operacionais a cada squad, o Platform Engineering centraliza a expertise em um time de plataforma que trata os desenvolvedores como clientes internos.

Os benefícios são claros: redução da carga cognitiva dos times de produto, aceleração das entregas (menos tempo configurando clusters ou pipelines) e padronização de ambientes, o que elimina o "funciona na minha máquina". O time de plataforma opera como um "produto interno", com backlog priorizado, métricas de adoção e ciclos de feedback contínuos.

2. Identificando as Necessidades do Time

Antes de construir qualquer componente, é essencial mapear as dores reais. As mais comuns incluem:

  • Complexidade de infraestrutura (Kubernetes, redes, IAM)
  • Falta de automação para provisionamento de ambientes
  • Ambientes inconsistentes entre dev, staging e produção
  • Dificuldade em gerenciar segredos e configurações

Técnicas de discovery eficazes incluem entrevistas com desenvolvedores, surveys estruturados e análise de logs de suporte (quantos tickets abertos para "meu pod não sobe"?). A priorização deve focar no que mais impacta o ciclo de desenvolvimento — por exemplo, reduzir o tempo de setup de um novo microsserviço de dias para minutos.

3. Arquitetura e Componentes da Plataforma Interna

Uma IDP bem construída possui três camadas principais:

  • Camada de abstração (IDP): interface self-service, catálogo de serviços e golden paths
  • Camada de orquestração: ferramentas como Crossplane ou Terraform para provisionamento
  • Camada de observabilidade: métricas, logs e tracing centralizados

Ferramentas populares incluem Backstage (portal do desenvolvedor), Port (catálogo de serviços) e Crossplane (orquestração declarativa). A base costuma ser Kubernetes, mas a plataforma deve abstrair isso do desenvolvedor.

O design de golden paths define templates padronizados que garantem boas práticas sem engessar a criatividade. Por exemplo:

# Exemplo de golden path para um microsserviço Node.js
# Template no catálogo da plataforma

service:
  name: "meu-servico"
  language: "nodejs"
  framework: "express"
  database: "postgresql"
  queue: "rabbitmq"
  observability:
    metrics: true
    tracing: true
    logs: structured
  ci_cd:
    branch_strategy: trunk-based
    deploy_environment: ["staging", "production"]

4. Construindo a Camada de Automação e Self-Service

O coração da plataforma é o catálogo de serviços, que oferece templates pré-definidos para aplicações, bancos de dados e filas. Cada template é um "pedaço de infraestrutura como código" que o desenvolvedor pode solicitar via portal.

A integração com GitOps e CI/CD garante que toda alteração seja rastreável. O fluxo típico é:

  1. Desenvolvedor acessa o portal e seleciona "Criar novo microsserviço"
  2. Preenche formulário com nome, linguagem e dependências
  3. Plataforma gera repositório Git com template, pipeline CI/CD e manifesto Kubernetes
  4. Pull request é aberto automaticamente para revisão
  5. Após merge, a pipeline deploya no ambiente de staging

Exemplo de fluxo simplificado:

# Fluxo de provisionamento via plataforma
Passo 1: Desenvolvedor solicita ambiente via portal
  -> Seleciona template: "API Node.js + PostgreSQL"
  -> Informa nome: "pedidos-api"

Passo 2: Plataforma executa:
  - Cria repositório: github.com/empresa/pedidos-api
  - Gera pipeline CI/CD no GitHub Actions
  - Provisiona banco PostgreSQL via Crossplane
  - Configura secrets e variáveis de ambiente

Passo 3: Desenvolvedor recebe notificação:
  "Ambiente staging pronto em pedidos-api.staging.empresa.com"

5. Governança, Segurança e Compliance na Plataforma

Sem governança, a plataforma vira um "farol". É essencial implementar políticas como código usando ferramentas como OPA (Open Policy Agent) ou Kyverno. Essas políticas controlam custos (ex: proibir instâncias muito caras), segurança (ex: exigir criptografia em repouso) e compliance (ex: logs de auditoria).

RBAC e multi-tenancy garantem isolamento entre times — cada squad só vê seus próprios recursos. A auditoria deve rastrear cada ação: quem criou, quando, qual template usou.

Exemplo de política como código:

# Política OPA: proibir bancos sem backup automático
package platform.deny

deny[msg] {
  input.kind == "PostgreSQLInstance"
  input.spec.backup.enabled == false
  msg := "Bancos PostgreSQL devem ter backup automático habilitado"
}

6. Métricas, Observabilidade e Evolução Contínua

Para saber se a plataforma está cumprindo seu papel, monitore indicadores-chave:

  • Tempo de provisionamento: quanto tempo leva para criar um novo ambiente
  • Taxa de adoção: quantos times usam a plataforma vs. fazem manual
  • DORA metrics: frequência de deploy, lead time, MTTR, taxa de falha

Coleta de feedback via NPS interno e análises de uso (quais templates são mais usados, onde há abandono) alimenta o ciclo de melhoria. A plataforma deve ter versões e changelogs, comunicando novidades aos times.

# Dashboard de métricas da plataforma
Métrica                    | Valor Atual | Meta
Tempo médio de provisionamento | 4 min      | < 5 min
Taxa de adoção (times)     | 78%         | > 90%
Deploy frequency (semanal) | 12 deploys  | > 10 deploys
Lead time (horas)          | 2.3h        | < 3h

7. Adoção Cultural e Superação de Resistências

A tecnologia é a parte fácil; a cultura é o desafio. Estratégias de onboarding incluem workshops práticos, documentação interativa (ex: playbooks com exemplos reais) e um canal de suporte dedicado.

Para lidar com resistência de times acostumados a "controlar tudo", mostre que a plataforma não tira autonomia — ela remove toil. Celebre vitórias: publique casos de sucesso mostrando redução de tempo de setup ou diminuição de incidentes.

Um exemplo concreto: um time que levava 2 dias para configurar um novo microsserviço passou a fazer isso em 15 minutos usando a plataforma. Esse tipo de resultado é o melhor argumento para adoção.

Referências