1~
2À medida que os sistemas de software se tornam mais complexos  -  microsserviços, Kubernetes, multi-cloud, pipelines CI/CD, stacks de observabilidade  -  os desenvolvedores gastam mais tempo em infraestrutura e menos tempo construindo produtos. O **Platform Engineering** resolve isso criando uma plataforma interna que abstrai a complexidade e fornece aos desenvolvedores ferramentas de self-service para entregar mais rápido.
3~
4O Gartner prevê que até 2027, **80% das organizações de engenharia de software** estabelecerão equipes de plataforma. Neste guia, exploraremos o que é Platform Engineering, por que importa e como construir uma Internal Developer Platform do zero.
5~
6## O que é Platform Engineering?
7~
8Platform Engineering é a disciplina de projetar e construir toolchains e workflows que habilitam capacidades de self-service para organizações de engenharia de software. O resultado é uma **Internal Developer Platform (IDP)**  -  uma camada que fica entre os desenvolvedores e a infraestrutura.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering vs DevOps
45~
46Platform Engineering não é um substituto para DevOps  -  é a próxima evolução. DevOps disse "você constrói, você opera." Platform Engineering diz "vamos tornar construir e operar algo sem esforço."
47~
48| Aspecto | DevOps | Platform Engineering |
49|---------|--------|---------------------|
50| **Foco** | Cultura e práticas | Produtos e self-service |
51| **Abordagem** | Cada equipe gerencia a infra | Equipe de plataforma abstrai a infra |
52| **Carga Cognitiva** | Alta (cada equipe aprende tudo) | Baixa (golden paths fornecidos) |
53| **Resultado** | Pipelines CI/CD, scripts IaC | Internal Developer Platform |
54| **Usuários** | Toda engenharia | Equipe de plataforma serve a engenharia |
55~
56## Por que Platform Engineering Importa
57~
58### O Problema da Carga Cognitiva
59~
60Em uma organização moderna típica, um desenvolvedor precisa entender:
61~
62- Workflows Git e estratégias de branching
63- Configuração de pipelines CI/CD
64- Construção de containers e gerenciamento de registros
65- Manifestos Kubernetes e Helm Charts
66- Serviços do provedor cloud (AWS/GCP/Azure)
67- Networking, DNS, certificados TLS
68- Configuração de monitoramento, logging e alertas
69- Provisionamento e migrações de bancos de dados
70- Políticas de segurança e conformidade
71~
72Isso é uma carga cognitiva enorme que desvia o foco do produto real.
73~
74### O Golden Path
75~
76Platform Engineering introduz o conceito de **golden paths**  -  caminhos opinados, bem suportados e documentados para tarefas comuns. Um golden path não é um mandato; desenvolvedores *podem* desviar, mas a plataforma torna a coisa certa a coisa fácil.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**Exemplo de golden path para criar um novo microsserviço:**
901. O desenvolvedor seleciona "Novo Serviço Backend" no portal
912. Escolhe linguagem/framework (Node.js, Go, Python)
923. A plataforma cria automaticamente: repositório Git, pipeline CI/CD, namespace Kubernetes, dashboards de monitoramento e regras de alerta
934. O desenvolvedor clona o repositório e começa a programar imediatamente
94~
95## Construindo uma Internal Developer Platform
96~
97### Camada 1: Developer Portal
98~
99O portal é o ponto de entrada único para desenvolvedores. A opção open-source mais popular é o **Backstage** (criado pelo Spotify, agora um projeto CNCF).
100~
101Funcionalidades principais:
102- **Catálogo de serviços**: Cada serviço, seu proprietário, documentação e dependências
103- **Templates de software**: Scaffolding para novos serviços com melhores práticas integradas
104- **Documentação técnica**: Documentação como código, renderizada e pesquisável
105- **Ecossistema de plugins**: Extensível com funcionalidades personalizadas
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### Camada 2: Abstração de Infraestrutura
129~
130Desenvolvedores não deveriam escrever Terraform ou YAML Kubernetes diretamente. A plataforma deveria fornecer abstrações.
131~
132**Ferramentas:**
133- **Crossplane**: Provisionamento de infraestrutura nativo do Kubernetes
134- **Terraform com módulos**: Módulos de infraestrutura pré-construídos e testados
135- **Pulumi**: Infraestrutura como código real (TypeScript, Python, Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150Em vez de configurar parâmetros RDS, sub-redes VPC, grupos de segurança e políticas de backup, o desenvolvedor simplesmente especifica `size: small` e `backup: daily`. A plataforma cuida do resto.
151~
152### Camada 3: Padronização CI/CD
153~
154Padronize CI/CD para que as equipes não construam cada uma seus próprios pipelines.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**Práticas fundamentais:**
174- Templates CI/CD compartilhados que as equipes incluem (não copiam)
175- Varredura de segurança automática (SAST, auditoria de dependências)
176- Estratégias de deploy padronizadas (canary, blue/green)
177- Rollback automático em caso de health checks falharem
178~
179### Camada 4: Observabilidade
180~
181Monitoramento pré-configurado para que desenvolvedores obtenham dashboards e alertas prontos para usar.
182~
183- **Métricas**: Prometheus + Grafana com dashboards padrão por serviço
184- **Logging**: Logging estruturado com coleta centralizada (Loki, ELK)
185- **Tracing**: Tracing distribuído com OpenTelemetry
186- **Alertas**: Integração PagerDuty/Opsgenie com padrões sensatos
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## Medindo o Sucesso
201~
202Como saber se sua plataforma está funcionando? Acompanhe estas métricas:
203~
204### Métricas DORA
205- **Frequência de deploy**: Com que frequência o código chega à produção
206- **Lead time para mudanças**: Tempo do commit até a produção
207- **Taxa de falha de mudanças**: Percentual de deploys causando falhas
208- **Tempo médio de recuperação**: Tempo para restaurar o serviço após um incidente
209~
210### Métricas Específicas da Plataforma
211- **Tempo até o primeiro deploy**: Quanto tempo do "novo serviço" até o primeiro deploy em produção
212- **Satisfação do desenvolvedor (NPS)**: Pesquise seus usuários regularmente
213- **Taxa de self-service**: % de requisições de infraestrutura resolvidas sem tickets
214- **Adoção do golden path**: % de serviços seguindo o caminho recomendado
215~
216## Erros Comuns
217~
218### 1. Construir Demais, Cedo Demais
219Comece pelo maior ponto de dor, não por uma grande visão. Se deploys são dolorosos, comece por aí. Se provisionamento leva semanas, comece por aí.
220~
221### 2. Não Tratar a Plataforma como um Produto
222A equipe de plataforma precisa de um product manager, pesquisa de usuários e ciclos de feedback. Desenvolvedores são seus clientes  -  entenda suas necessidades.
223~
224### 3. Impor em Vez de Atrair
225As melhores plataformas são adotadas voluntariamente porque facilitam a vida dos desenvolvedores. Se você precisa impor o uso, sua plataforma não é boa o suficiente.
226~
227### 4. Ignorar a Developer Experience
228Uma plataforma com UX terrível não será usada. Invista em documentação clara, mensagens de erro úteis e ciclos de feedback rápidos.
229~
230## Como Começar
231~
232Um roadmap prático para construir sua primeira IDP:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### Plataforma Mínima Viável
258~
2591. **Catálogo de serviços** (Backstage)  -  saber o que existe e quem é o responsável
2602. **Um template de serviço**  -  golden path para seu tipo de serviço mais comum
2613. **CI/CD padronizado**  -  pipeline compartilhado que as equipes incluem
2624. **Documentação básica**  -  como usar a plataforma, onde conseguir ajuda
263~
264Você pode construir este MVP em 2-3 meses com uma equipe de 2-3 engenheiros.
265~
266## Conclusão
267~
268Platform Engineering não é sobre construir a plataforma perfeita desde o primeiro dia. É sobre reduzir incrementalmente a carga cognitiva dos desenvolvedores para que possam focar em construir produtos. Comece pequeno, meça o impacto e itere com base no feedback dos desenvolvedores.
269~
270As organizações que investirem em Platform Engineering terão uma vantagem competitiva significativa: entrega mais rápida, desenvolvedores mais satisfeitos e sistemas mais confiáveis.
271~
272**Recursos:**
273- [Team Topologies](https://teamtopologies.com/)  -  o livro que popularizou equipes de plataforma
274- [Backstage](https://backstage.io/)  -  o portal de desenvolvedores open-source do Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  definição da comunidade e melhores práticas
276- [platformengineering.org](https://platformengineering.org/)  -  comunidade, eventos e recursos
277~