Em 2022, fizemos uma pergunta provocativa neste blog: o DevOps deveria ser rebatizado como platform engineering? Nosso argumento era que “DevOps” havia deixado de ser uma forma de trabalhar para virar um cargo vago, e que o time que constrói a base sobre a qual as aplicações rodam merecia um nome mais claro. De lá para cá, o platform engineering se tornou uma disciplina própria, com white papers, conferências e times dedicados. Este post atualizado explica o que é platform engineering, como ele se relaciona com o DevOps e quando uma startup realmente precisa dele.

O que defendemos em 2022

O DevOps nasceu como uma filosofia: desenvolvimento e operações trabalhando juntos, dividindo a responsabilidade pelo que roda em produção. Conforme o mercado o adotou, a palavra virou uma lista de ferramentas e um cargo. Quando alguém diz “time de produto” ou “time de aplicação”, todo mundo entende o que esse time faz. Diga “time de DevOps” e a resposta depende de quem você pergunta.

Sugerimos ligar o DevOps à stack que entrega o produto, como o time que constrói e opera a plataforma da qual as aplicações dependem. Isso preservaria os benefícios da filosofia DevOps e daria ao time um mandato claro. Essa ideia hoje tem um nome, e o setor em grande parte o adota.

O que é platform engineering

Platform engineering é a prática de construir e operar uma plataforma interna que os times de produto usam para entregar e operar seu software sem precisar ser especialistas em infraestrutura.

O white paper Platforms, da Cloud Native Computing Foundation, define uma plataforma para computação cloud native como “an integrated collection of capabilities defined and presented according to the needs of the platform’s users” (um conjunto integrado de capacidades definido e apresentado de acordo com as necessidades dos usuários da plataforma). Ele também cita uma descrição muito usada, de Evan Bottcher e Martin Fowler, que define uma plataforma digital como “a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product” (uma base de APIs de autosserviço, ferramentas, serviços, conhecimento e suporte, organizada como um produto interno atraente).

Duas palavras nessas definições fazem a maior parte do trabalho.

Autosserviço. Um desenvolvedor deve conseguir criar um novo serviço, obter um pipeline, provisionar um banco de dados ou ver seus logs sem abrir um chamado e esperar alguém do time de infraestrutura.

Produto. A plataforma tem usuários (os seus desenvolvedores), e o time de plataforma trata a experiência deles como um time de produto trata os clientes. Se os desenvolvedores dão a volta na plataforma, ela falhou, por mais elegante que seja.

Ferramentas e blocos de construção de platform engineering

Na prática, uma plataforma para uma empresa de SaaS na AWS costuma incluir:

Templates para novos serviços, com pipeline, logs e health checks funcionando desde o primeiro dia
Módulos de infraestrutura como código para recursos comuns, como bancos de dados, filas e buckets, com padrões de segurança sensatos
Um caminho de deploy padrão, muitas vezes GitOps, para todos os ambientes
Observabilidade que funciona de fábrica: dashboards, alertas e traces para qualquer serviço da plataforma
Guardrails: limites de IAM, políticas de rede, tags de custo e verificações de política que rodam automaticamente
Documentação e uma forma clara de pedir ajuda

As ferramentas de platform engineering por trás disso são, em sua maioria, conhecidas: Terraform ou CloudFormation para os módulos, um sistema de CI/CD para o pipeline padrão e uma stack de observabilidade para os padrões. Organizações maiores costumam acrescentar um portal do desenvolvedor, como o Backstage, um framework open source para construir portais de desenvolvedores que o Spotify criou e que hoje é um projeto em incubação da CNCF. As ferramentas importam menos do que o caminho pavimentado que elas formam juntas.

Platform engineering vs. DevOps

O platform engineering não substitui o DevOps. É uma das formas de colocar o DevOps em prática quando a organização cresce.

O DevOps descreve o objetivo e a cultura: responsabilidade compartilhada pela produção, feedback rápido, automação, mudanças pequenas e frequentes. O platform engineering é uma resposta organizacional a um problema que surge à medida que os times se multiplicam. Quando todo time de produto precisa virar especialista em Kubernetes, Terraform, IAM e observabilidade para entregar, a carga cognitiva atrasa todo mundo. Um time de plataforma absorve essa complexidade uma vez e a oferece a todos os outros como um caminho pavimentado.

A ideia já é mainstream. O programa de pesquisa DORA, do Google, relatou em seu relatório de 2025 sobre desenvolvimento de software assistido por IA que 90% das organizações adotaram pelo menos uma plataforma, e encontrou uma correlação direta entre uma plataforma interna de alta qualidade e a capacidade de uma organização de extrair valor da IA. À medida que as ferramentas de IA aumentam o volume de mudanças, uma plataforma sólida é o que mantém essas mudanças seguras.

Quando uma startup precisa de platform engineering

A maioria das startups em estágio inicial não precisa de um time de plataforma, e montar um cedo demais é um jeito comum de gastar tempo de engenharia com a coisa errada. Alguns sinais indicam que você está se aproximando:

Você tem vários times de produto, não um só, e cada um resolve os mesmos problemas de infraestrutura de um jeito diferente.
Criar um novo serviço leva dias ou semanas, porque cada pipeline, ambiente e alerta é montado à mão.
O conhecimento de infraestrutura mora em uma ou duas cabeças. Quando elas estão ocupadas ou ausentes, os outros times esperam.
Os incidentes vêm da inconsistência: um serviço sem health checks, outro sem alertas, um terceiro publicado por um script que ninguém lembra de ter escrito.
O compliance está chegando. Os controles de SOC 2 ou HIPAA são muito mais fáceis de comprovar quando todos os serviços seguem os mesmos padrões.
Você está migrando para várias contas AWS ou para Kubernetes, e o número de peças móveis está prestes a disparar.

Se nada disso se aplica, algumas convenções bem escolhidas e um bom pipeline bastam. Se vários se aplicam, você precisa de alguém pensando na plataforma como um produto.

Como ter uma plataforma sem montar um time de plataforma

Um time de plataforma dedicado normalmente significa vários engenheiros seniores, o que é um compromisso grande para uma empresa com três ou quatro times de produto. Existem opções mais leves:

Comece pelo caminho pavimentado, não por um portal. Um template de serviço, um pipeline padrão e módulos Terraform compartilhados entregam a maior parte do valor. Um portal do desenvolvedor pode vir depois, se vier.
Padronize primeiro o que mais dói. Se os incidentes vêm da falta de observabilidade, comece por aí. Se o gargalo é colocar um serviço no ar, comece pelos templates.
Trate a plataforma como código nos seus repositórios, para que quem a mantenha, dentro de casa ou fora, trabalhe a partir da mesma fonte de verdade.
Traga um time que já faz isso. Um time externo pode construir as bases e operá-las enquanto seus engenheiros as aprendem, e depois passar o bastão conforme você contrata.

Para uma visão mais ampla da decisão entre contratar e terceirizar, veja quando contratar um time de DevOps em tempo integral.

Perguntas frequentes

Platform engineering é o mesmo que DevOps?

Não, mas os dois estão muito relacionados. O DevOps é o objetivo e a cultura: responsabilidade compartilhada pela produção, automação e feedback rápido. O platform engineering é uma forma de colocar o DevOps em prática à medida que a organização cresce, com um time construindo uma plataforma interna de autosserviço que os times de produto usam como um caminho pavimentado.

Que habilidades um platform engineer precisa ter?

Os platform engineers precisam das habilidades centrais de DevOps, como infraestrutura como código, CI/CD, serviços de nuvem, contêineres e observabilidade, além de noções básicas de segurança, como IAM e políticas de rede. Igualmente importante é o raciocínio de produto: tratar os desenvolvedores como usuários, descobrir o que os atrasa e construir ferramentas de autosserviço que eles escolham usar. Uma plataforma que os desenvolvedores contornam falhou, por melhor que seja a engenharia.

Quando uma startup precisa de platform engineering?

Em geral, não no estágio mais inicial. Os sinais são vários times de produto resolvendo os mesmos problemas de infraestrutura de formas diferentes, novos serviços que levam dias para ser configurados, conhecimento de infraestrutura concentrado em uma ou duas pessoas, incidentes causados por inconsistência e trabalho de compliance ou de várias contas a caminho. Se vários desses se aplicam, alguém deve ser dono da plataforma como um produto.

Onde a Webera entra: o plano Platform

A Webera é uma assinatura de DevOps para times de SaaS na AWS, com engenheiros seniores trabalhando ao lado de nove agentes de IA. Nosso plano Platform, a US$ 14.999 por mês, foi feito para o estágio que este post descreve: um time trabalhando dentro das suas sprints, operação multi-conta e de Kubernetes, e transferência de conhecimento para os seus engenheiros, além de tudo o que está no Elite (um engenheiro designado, um gerente de sucesso do cliente e um concierge de compliance para SOC 2, HIPAA e PCI). O Warden, o agente responsável pelos padrões, verifica se todo repositório está documentado e se todo alerta tem um runbook, o que explica grande parte do que torna uma plataforma utilizável por quem não a construiu.

Se você ainda não está nesse estágio, o Pro (US$ 4.999 por mês) e o Elite (US$ 9.999 por mês) cobrem as solicitações, o monitoramento e a resposta a incidentes de um único time de produto. Todos os planos têm mínimo de três meses e depois seguem mês a mês, e todo o código é seu. Compare os planos na nossa página de preços.

Platform engineering vs. DevOps: o DevOps deveria mudar de nome?