O platform engineering é a prática de construir ferramentas internas e infraestrutura em autosserviço que tornam os programadores produtivos. Bem feito, elimina o estrangulamento de "abre um ticket e espera 3 semanas" entre desenvolvimento e operações. Mal feito, cria mais uma camada de burocracia que ninguém usa.
Porquê platform engineering, porquê agora
A promessa do DevOps era "you build it, you run it". A realidade é que a maioria dos programadores não quer gerir manifestos de Kubernetes, módulos de Terraform e pipelines de CI/CD. Quer entregar funcionalidades.
O platform engineering preenche essa lacuna: uma equipa dedicada constrói os golden paths que os programadores seguem, abstraindo a complexidade da infraestrutura e preservando a flexibilidade para as equipas que dela precisam.
O gatilho costuma ser a escala. Com 5 engenheiros, toda a gente pode entrar no servidor por SSH. Com 50 engenheiros, precisas de ambientes padronizados. Com 200, precisas de autosserviço.
O que faz uma equipa de plataforma
Uma equipa de plataforma é normalmente responsável por:
Portal de autosserviço para programadores — Uma UI ou CLI onde os programadores podem aprovisionar ambientes, bases de dados, filas de mensagens e monitorização sem abrir tickets. "Preciso de um ambiente de staging" deve demorar 5 minutos, não 5 dias.
Modelos de golden path — Modelos de projeto com convenções já definidas que incluem CI/CD, monitorização, logging e predefinições de segurança. Os novos serviços arrancam com as boas práticas incorporadas de raiz, não acrescentadas depois.
Plataforma Interna para Programadores (IDP) — A camada que liga Git, CI/CD, registo de contentores, Kubernetes, monitorização e gestão de segredos num fluxo de trabalho coerente. O Backstage (do Spotify) é o framework open source mais popular para isto.
Abstração da infraestrutura — Em vez de expor Terraform em bruto aos programadores, a equipa de plataforma disponibiliza abstrações de nível mais alto: "dá-me uma base de dados PostgreSQL" em vez de "aprovisiona uma instância RDS com estes 47 parâmetros".
Base de observabilidade — Logging, métricas e tracing centralizados que todos os serviços recebem automaticamente. Os programadores não deviam ter de configurar o scraping do Prometheus nem a recolha de logs do Loki para cada serviço.
Como começar: os primeiros 90 dias
Dias 1-30: Descoberta - Entrevista 10-15 programadores: o que os atrasa? O que gostariam que existisse? - Mapeia o percurso atual do programador: do commit à produção. Onde estão os estrangulamentos? - Audita as ferramentas existentes: que ferramentas já usam as equipas? O que está duplicado? - Identifica os 3 principais pontos de dor por frequência e impacto
Dias 31-60: Ganhos rápidos - Resolve o ponto de dor #1 com a solução mais simples possível - Padroniza os modelos de CI/CD para os 3 tipos de serviço mais comuns - Monta um ambiente de desenvolvimento partilhado que os programadores possam aprovisionar sozinhos - Documenta tudo num portal para programadores (mesmo que, para começar, seja só uma wiki no Notion)
Dias 61-90: Fundações - Faz o deploy do Backstage (ou equivalente) como portal central para programadores - Constrói o primeiro modelo de golden path (p. ex., "novo microsserviço" com CI/CD, monitorização e implementação) - Implementa o aprovisionamento de bases de dados em autosserviço - Mede: inquérito de satisfação dos programadores + tempo até ao primeiro deploy dos novos serviços
Composição da equipa
Uma equipa de plataforma inicial (4-6 pessoas) deve incluir:
- 1 Tech Lead de plataforma — Define a direção técnica, toma as decisões de arquitetura e protege a equipa do ruído organizacional
- 2 engenheiros de backend/infraestrutura — Constroem os componentes da plataforma (módulos de Terraform, operadores de Kubernetes, camada de API)
- 1 engenheiro DevOps/SRE — Gere o CI/CD, a observabilidade e a infraestrutura da própria plataforma
- 1 engenheiro de frontend (opcional) — Constrói a UI do portal de autosserviço se fores além das ferramentas CLI
Não comeces com 1 pessoa. Um "platform engineer" sozinho torna-se um estrangulamento, não uma plataforma. Precisas de pelo menos 3 pessoas para manter o ritmo enquanto lidas com interrupções.
Erros comuns
Construir antes de ouvir. Se construíres um portal de autosserviço que ninguém pediu, ninguém o vai usar. Começa por entrevistas aos programadores, não por diagramas de arquitetura.
Impor a adoção. As melhores plataformas são adotadas porque facilitam a vida aos programadores, não porque a gestão as impôs. Se os programadores estão a contornar a tua plataforma, o problema é a plataforma.
Abstrair em excesso. Não tentes abstrair tudo. Começa pelos 3 fluxos de trabalho mais comuns e fá-los excecionalmente bem. Podes sempre acrescentar mais depois.
Ignorar a operação. Uma plataforma difícil de depurar, atualizar ou escalar é um passivo. Trata a tua plataforma com o mesmo rigor dos serviços de produção: monitorização, SLO, resposta a incidentes.
Sem ciclo de feedback. Agenda sessões mensais de feedback com os teus utilizadores (os programadores). Acompanha o NPS. Prioriza com base na dor real, não em funcionalidades imaginadas.
Medir o sucesso
Acompanha estas métricas trimestralmente:
- Tempo até ao primeiro deploy — Quanto tempo vai de "novo projeto" a "a correr em produção"? Objetivo: menos de 1 dia.
- Satisfação dos programadores (NPS) — Faz inquéritos aos teus programadores. Uma pontuação acima de 30 significa que estás a ir bem.
- Taxa de adoção do autosserviço — Que percentagem do aprovisionamento de ambientes passa pela plataforma, em vez de tickets manuais?
- Volume de tickets — Os tickets de infraestrutura estão a diminuir à medida que o autosserviço aumenta?
- Lead time das alterações — A organização de engenharia no seu todo está a entregar mais depressa?
Conclusão
O platform engineering não é uma escolha tecnológica — é um investimento organizacional na produtividade dos programadores. As empresas que acertam veem melhorias drásticas na frequência de implementação, na satisfação dos programadores e na retenção de engenheiros. Começa pequeno, ouve os teus utilizadores, mede tudo e itera depressa. O objetivo não é uma plataforma perfeita — é uma plataforma 10x melhor do que aquilo que os programadores tinham ontem.