Nos últimos anos, a engenharia de plataformas passou rapidamente de conceito de nicho a tema central nas conversas de TI.
Tornou-se também, infelizmente, um dos temas mais mal entendidos.
Dependendo de quem responde, a engenharia de plataformas é descrita como:
- “DevOps com Kubernetes”
- Uma nova equipa de CI/CD ou de ferramentas internas
- SRE com outro nome
- Uma PaaS interna que se compra ou se constrói
- Ou simplesmente “a equipa que é dona da plataforma”
A maioria destas definições é incompleta. Algumas são francamente prejudiciais. E é esse mal-entendido uma das principais razões por que tantas iniciativas de plataforma falham.
Não é um conjunto de ferramentas
Comecemos por ser explícitos.
A engenharia de plataformas não é:
- Kubernetes com uma interface mais bonita
- Um conjunto de ferramentas de CI/CD atadas umas às outras
- Um produto de fornecedor que se compra e instala
- Uma equipa de suporte com um título novo
- Um atalho para a maturidade organizacional
As ferramentas são facilitadores, não o alicerce.
As organizações que começam o seu percurso pela escolha de ferramentas acabam quase sempre com:
- Mais complexidade
- Maior carga cognitiva para os engenheiros
- Responsabilidades fragmentadas
- Pouca adoção interna
Porque o problema de fundo nunca foram as ferramentas.
É um modelo operacional
Na sua essência, a engenharia de plataformas é um modelo operacional.
Existe para resolver um problema muito concreto:
Como permitir que as equipas avancem depressa sem sacrificar fiabilidade, segurança e controlo operacional?
A resposta não é a descentralização total. Nem a centralização rígida.
A resposta é abstração com responsabilização.
A engenharia de plataformas define:
- Fronteiras claras
- Caminhos normalizados
- Predefinições com opinião
- Responsabilidades explícitas
Tudo isto sem retirar autonomia às equipas.
As plataformas internas são produtos, não projetos
Uma plataforma não é algo que se “entrega” e se deixa para trás.
Uma plataforma interna a sério:
- Tem utilizadores claramente definidos (programadores, SRE, operadores)
- Oferece interfaces e contratos estáveis
- Otimiza a experiência de quem desenvolve, não os diagramas de arquitetura
- Evolui em função do que é usado e do que é dito
- Mede-se pela utilização, não pelo número de funcionalidades
As equipas de plataforma bem-sucedidas funcionam como equipas de produto, não como equipas de infraestrutura.
Se as equipas só usam a sua plataforma porque são obrigadas, não tem uma plataforma. Tem uma imposição.
Esconder a complexidade sem esconder a responsabilidade
Um dos equívocos mais comuns é pensar que a engenharia de plataformas serve para “esconder a complexidade”.
Serve, mas só em parte.
As boas plataformas:
- Escondem os detalhes de implementação
- Expõem resultados e limites
- Tornam a responsabilidade explícita
- Preservam a consciência operacional
As más plataformas:
- Criam caixas negras
- Ocultam as formas como as coisas falham
- Transferem responsabilidade sem clareza
O objetivo não é a ignorância. O objetivo é menos carga cognitiva com responsabilidades claras.
Exige escala e complexidade
Não é toda a organização que precisa de engenharia de plataformas.
Se tem:
- Poucas equipas
- Âmbito operacional limitado
- Requisitos baixos de disponibilidade ou conformidade
Criar uma equipa de plataforma cedo demais vai provavelmente atrasá-lo.
A engenharia de plataformas torna-se necessária quando:
- As equipas se multiplicam
- Os ambientes divergem
- O conhecimento fica na cabeça de poucos
- A fiabilidade depende de heroísmos
- A governação passa a ser manual e frágil
Em suma: quando a complexidade se torna sistémica.
Observabilidade e operação não são acessórios
Uma plataforma sem observabilidade é cega. Uma plataforma sem fluxos operacionais está incompleta.
As plataformas a sério incorporam:
- Monitorização e observabilidade por omissão
- Normas e limites operacionais
- Respostas automáticas a falhas conhecidas
- Modelos claros de escalamento e responsabilidade
É aqui que a engenharia de plataformas converge naturalmente com:
- SRE
- Observabilidade
- Automação
- E, mais tarde, AIOps
Não como palavras da moda, mas como uma evolução imposta pela realidade operacional.
Porque falham a maior parte das iniciativas
A maior parte das iniciativas de plataforma falha por razões previsíveis:
- São guiadas por ferramentas em vez de problemas
- Otimizam a arquitetura em vez da experiência
- Não têm responsabilidade de longo prazo nem alinhamento com a gestão
- Tentam resolver tudo de uma vez
- Ignoram a operação do dia a dia
A engenharia de plataformas não é uma transformação que se “termina”. É uma disciplina contínua.
É engenharia aplicada à operação
No seu melhor, a engenharia de plataformas é apenas isto:
Princípios de engenharia aplicados à realidade operacional.
Trata-se de:
- Fazer do caminho certo o caminho mais fácil
- Inscrever as boas práticas na própria plataforma
- Reduzir a carga cognitiva à escala
- Permitir autonomia sem caos
Sem hype. Sem atalhos. Apenas engenharia disciplinada.
