Bem-vindos a mais um episódio do Microsoft Knowledge Nuggets no M306.5 FM. Eu sou seu anfitrião, Mirko Peters. O tópico de hoje é algo que quase todos já ouviram falar, mas poucos realmente entendem. Engenharia de plataforma. Você provavelmente já ouviu falar sobre DevOps e a ideia de que desenvolvedores e equipes de operações trabalhem juntos perfeitamente, mas essa promessa acabou se tornando confusa no caminho. Desenvolvedores acabaram fazendo trabalho de operações e o sistema quebrou. Ao final deste episódio, você entenderá o que deu errado com o DevOps, o que é realmente uma plataforma interna de desenvolvedor. Como os caminhos dourados oferecem uma rota clara para as equipes seguirem e porque as equipes de engenharia mais inteligentes já estão construindo um. A bagunça que o DevOps deixou pra dar. Vamos voltar ao início. O DevOps foi uma ótima ideia com um objetivo simples, derrubar os muros entre desenvolvedores e operações.

Cheia de jogar código por cima do muro e torcer pelo melhor. Shift-Left. Mover testes, segurança e operações para o início do processo. Entrega mais rápida, menos transferências, mais responsabilidade. No papel parecia perfeito. Na prática, algo deu errado. O Shift-Left não apenas deslocou responsabilidades, ele as acumulou. O desenvolvedor que costumava escrever código e abrir um chamado agora é dono da infraestrutura, segurança, monitoramento, Kubernetes, pipelines de CI e CD, gerenciamento de segredos e cerca de 15 serviços em nuvem que nunca tinha ouvido falar antes. Uma pessoa lida com tudo isso enquanto ainda constrói o produto propriamente dito. Veja como isso funciona na vida real. Uma equipe quer criar um novo ambiente para testar uma funcionalidade. Antes do DevOps, eles abriram um chamado e esperariam. Depois do DevOps, eles são responsáveis por isso, que parece ótimo na teoria.

Mas agora eles precisam escrever módulos Terraform e configurar um cluster Kubernetes, definir regras de rede, conectar o monitoramento, entender o gerenciamento de segredos e garantir que as políticas de segurança sejam aplicadas. O que costumava ser um chamado que levava uma hora para outra pessoa, agora toma três dias do tempo de um desenvolvedor. Três dias em que não estão escrevendo código e produto. Eles estão lutando com arquivos e eu, e depurando porque o balanceador de carga não está roteando o tráfego corretamente. A carga mental aqui é enorme. Cada equipe acaba construindo seus próprios pipelines, scripts de implantação e painéis de monitoramento. Como todos estão sobrecarregados, atalhos são tomados. A segurança é ignorada, porque o prazo é sexta-feira. As contas de nuvem dobram sem ninguém notar, porque ninguém se lembrou de desligar o ambiente de teste. E quando algo quebra às 2 da manhã, o desenvolvedor que construiu é o único que pode consertar.

Isso não é sustentável e aqui está o porquê de ser mais importante do que nunca. A complexidade da nuvem continua crescendo. A cada ano há mais serviços, mais ferramentas e mais decisões a serem tomadas. Agora, ferramentas de codificação de IA permitem que desenvolvedores entreguem código mais rápido do que nunca, 10, 20, até 30 vezes mais código por dia. Mas todo esse código ainda precisa de infraestrutura, segurança e monitoramento. Mais código sem um sistema melhor apenas significa um caos mais rápido. Se você sente que está se afogando em IA e Terraforma, você não está sozinho. Isso não é uma falha pessoal. É sistema. O modelo quebrou que a engenharia de plataforma realmente é. Então qual é a solução? Chama-se engenharia de plataforma, e aqui está a forma mais simples de pensar sobre isso. Essa disciplina cria uma camada interna que absorve a complexidade pelos desenvolvedores. Imagine entrar em um grande prédio e escritórios.

Você não precisa se preocupar com quem tem acesso, a qual andar, qual crachá funciona, ou onde estão as saídas de emergência. A recepção cuida de tudo isso para você e você apenas entra e vai trabalhar. É exatamente isso que a engenharia de plataforma faz para os seus desenvolvedores. Em vez de cada desenvolvedor precisar se tornar um especialista em Kubernetes, Terraforma e rede de segurança, uma equipe central de plataforma cria uma camada que gerencia toda essa complexidade. O desenvolvedor recebe uma interface simples, clica em um botão, executa um comando, preenche um formulário, e a plataforma cuida de tudo o resto. Mas aqui está o detalhe, isso não é o mesmo que DevOps. O DevOps dizia para cada equipe ser dona da sua própria infraestrutura, mas a engenharia de plataforma diz que isso é receita para o esgotamento possível. Em vez disso, a equipe de plataforma fornece caminhos pavimentados, formas padrão, testadas e seguras de lidar com tarefas comuns.

Eles constroem e mantêm a estrada, enquanto as equipes de produto apenas dirigem na época. O resultado central da engenharia de plataforma é algo chamado Plataforma Interna de Desenvolvedor, ou IDP, para abreviar. Pense nela como um sistema de autoatendimento que automatiza todo esse trabalho repetitivo. Provisionamento de infraestrutura, pipelines de C e CD, verificações de segurança, monitoramento, tudo integrado e padronizado. Questão é um exemplo concreto. Quando um desenvolvedor quer implantar um novo serviço em uma plataforma, ele levaria dias configurando infraestrutura, escrevendo pipelines e configurando monitoramento. Com uma IDP, ele apenas clica em implantar em uma interface ou executa um único comando. E a plataforma cuida de tudo. Provisionamento, testes, monitoramento, implantação, tudo em minutos em vez de dias. Então o que isso significa para você? Você para de ser um faz-tudo da infraestrutura e começa a ser um especialista no seu produto real.

Seu trabalho volta a ser construir funcionalidades que importam para seus clientes em vez de depurar porque seu arquivo de estado do Terraforma está corrompido. Esse é o ponto principal. A plataforma interna do desenvolvedor em termos simples. Então vamos analisar o que é uma plataforma interna do desenvolvedor realmente. É um motor que combina tudo em um único sistema. Seus pipelines de C e CD, modelos de infraestrutura, políticas de segurança, monitoramento e logs. Em vez de seis ferramentas separadas que você precisa conectar. E vai uma analogia. Pense nisso como cozinhar do zero, versus usar uma máquina de venda automática. Cozinhar do zero significa comprar ingredientes, picar vegetais, medir temperos, vigiar o fogão, vigiar o fogão. Muitas decisões, muitos passos, muitas chances de algo dar errado. Uma máquina de venda automática te dá um resultado com apertar de um botão. Menos decisões, resultado mais rápido, qualidade consistente.

Um IDP é essa máquina de venda automática. O desenvolvedor não precisa saber como a infraestrutura é provisionada ou onde o segredo só é armazenado. Eles apenas apertam o botão. O que há dentro dessa máquina? Os componentes principais são bem padrões. Modelos de C e CD para build consistente, provisionamento de infraestrutura para criação automática de ambientes, gerenciamento de segredos para que credenciais não fiquem soltas em arquivos de configuração, e logs com observabilidade integrada para solucionar problemas sem desespero. Tudo pré-configurado, testado e mantido pela equipe de plataforma. E aqui vai um exemplo concreto. Um desenvolvedor digita criar novo serviço na linha de comando ou clica em um botão no portal. Nos bastidores, o IDP cria um novo repositório com a estrutura correta, configura um pipeline de build que executa testes automaticamente, implanta o serviço em um ambiente de desenvolvimento e adiciona endpoints de health check com logs.

Tudo isso acontece em minutos. O desenvolvedor nunca tocou em um único arquivo terraform ou configurou um manifesto Kubernetes. Apenas digitou um comando e obteve a sua execução. Por que se importa? Consistência é o motivo principal. Quando cada equipe constrói seus próprios pipelines e escreve seus próprios scripts de implantação, você acaba com configurações únicas e complexas. 50 serviços diferentes, 50 formas diferentes de fazer as coisas. Quando algo quebra, ninguém consegue depurar, exceto quem o construiu. E se essa pessoa saiu da empresa, boa sorte. Um IDP elimina isso, fazendo com que cada serviço siga os mesmos padrões, cada implantação use o mesmo pipeline e cada equipe receba os mesmos padrões. Quando algo quebra, os padrões são familiares e a correção está documentada. Então, eis o que isso significa para você. Se a organização tem 50 equipes fazendo implantações de 50 formas diferentes, um IDP é a solução.

Isso não significa que as equipes pedem o todo. Significa que as partes chatas, repetitivas e propensas a erro são padronizadas para que o trabalho criativo e interessante possa variar. Essa é uma troca e vale a pena. Caminhos dourados, o caminho não é uma jaula. Vamos falar sobre caminhos dourados. Você provavelmente já ouviu o nome, mas a ideia é simples. Um caminho dourado é um fluxo de trabalho recomendado e pré-construído, que torna a coisa certa a coisa mais fácil de se fazer. Sua equipe de plataforma diz, veja como sugerimos que você faça aí. Nós testamos, funciona e daremos suporte se algo der errado. Observe a palavra sugerindo. Os caminhos ideais, Golden Paths, não são obrigado. Os desenvolvedores podem sair do caminho se precisarem, mas ele é o padrão rápido e seguro. Ele já está em execução com o suporte documentado. Você não precisa descobrir tudo do zero. Pense nisso como trilhos de trem, em vez de guardrails.

Guardrails te seguram quando você vai. Eles reagem e impedem que você caia de um precipício, mas não ajudam a dirigir. Trilhos de trem te guiam suavemente pelo caminho sem que você precise decidir para onde virar. Caminhos ideais são como trilhos. Eles te levam para frente e não apenas te seguram quando você faz. É aqui que muitas equipes erram. Elas criam caminhos ideais para a equipe de plataforma, não para os desenvolvedores. Elas otimizam para a pureza arquitetural, conformidade e segurança ou alguma regra interna que ninguém fora da plataforma entende. O resultado parece ótimo no quadro branco, mas é horrível de usar. E desenvolvedores encontram soluções alternativas silenciosamente, a adoção cai e a equipe de plataforma se pergunta por que ninguém esforça. A solução é simples, mas difícil de executar. Você precisa sair das emergências. Se o caminho não atende ao caso de uso dos desenvolvedores, precisam de uma saída.

Uma forma de substituir um padrão, trazer seu próprio pipeline ou sair completamente da plataforma. E aqui está a parte importante. Quando eles saem do caminho, isso não é uma falha, é um feedback. Cada vez que um desenvolvedor deixa o caminho ideal, ele te diz algo real. Ou falta um recurso que deveria estar lá, ou o caso de uso realmente não pertence àquele caminho. Ambos os sinais são valiosos. Um bom caminho ideal na prática funciona assim. Uma equipe quer implantar um novo serviço de backend. Eles o caminho. Ele fornece um repositório modelo com a estrutura correta, um pipeline de CI, CD padrão já testado, login e monitoramento integrados, e rollback com um clique se algo der errado. Tudo leva minutos em vez de dias, e como a equipe de plataforma mantém o caminho, se algo quebrar, eles consertam. O desenvolvedor não precisa se tornar um especialista em depuração de pipeline. O que isso significa para você?

Menos surpresas. Você entrega mais rápido que o caminho atestado. Você entrega com mais segurança porque a segurança e o monitoramento são integrados. Você entrega com confiança porque o rollback é feito com um clique. O caminho existe para te ajudar, não para te atrasar. Use. Reduzindo a carga initiva. É aqui que o verdadeiro retorno aparece. Quando uma plataforma cuida do trabalho pesado, os desenvolvedores podem focar realmente no código. Eles não precisam saber qual versão do Kubernetes está rodando. Não precisam atualizar módulos terraform toda vez que um provedor de nuvem muda uma API. Eles apenas esquecem a realidade. A anti-plataforma absorve essa complexidade. Eles decidem o que os desenvolvedores precisam ver e o que deve permanecer o... Isso é uma escolha de design real, não apenas técnica. Trata-se de descobrir quais detalhes importam para quem usa a plataforma e quais apenas adicionam ruído.

Este é um exemplo concreto. Um desenvolvedor implantando um novo serviço não se importa com tamanhos de nós de cluster, tipos de instâncias ou limite de escalonamento automático. Eles se importam se o serviço deles roda e quão rápido ele responde. Portanto, a plataforma pré-configura tudo isso com base na camada da aplicação. Serviço pequeno é que está a configuração correta. Serviço de alto tráfego é que está uma configuração diferente. O desenvolvedor não faz essas escolhas porque não precisa. Por que isso importa? Porque o esgotamento cai quando os desenvolvedores não estão equilibrando 15 preocupações diferentes ao mesmo tempo. Algumas equipes de plataforma maduras reduziram a carga cognitiva em quase metade. 40 a 50% menos sobrecarga mental. Isso é uma mudança enorme. É a diferença entre sair do trabalho com energia e encarar um terminal às 22 horas pensando porque seu pipeline falhou.

Mas aqui vai o aviso. Não crie ilusões. Algumas equipes de plataforma caem lá, mas... Elas escondem configurações sem dar aos desenvolvedores qualquer meio de entender o que acontece por baixo do capô. Isso não é abstração, é truque e sai pela culatra no momento em que algo dá errado. Desenvolvedores batem um muro que não conseguem ver através e de repente a plataforma parece uma caixa preta trabalhando contra ele. O tempo para isso é abstração com vazamento. Se esconde a complexidade, mas eventualmente ela vaza. Um banco de dados fica lento. Um deploy falha, uma política de segurança bloqueia algo inesperado. E o desenvolvedor não tem um modelo mental do que está acontecendo porque a plataforma nunca lhes deu um. Transparência importa. Mostre aos desenvolvedores o que eles precisam saber quando precisam saber. Não esconda tudo e espere pelo melhor. Isso significa para você menos troca de contexto e mais estado de fluxo.

Você não começa sua manhã pensando se o cluster Kubernetes precisa de upgrade, você começa trabalhando a funcionalidade com prazo para a próxima semana. Seu emprego volta a ser seu trabalho de verdade. Tratando a plataforma como produto. Hoje estamos falando de algo que muda, como as ferramentas internas realmente funcionam. A maioria das pessoas pensa que uma equipe de plataforma é apenas uma equipe de infraestrutura. Uma equipe de plataforma é uma equipe de produto e os desenvolvedores que usam essa plataforma são seus clientes, não pessoas abrindo chamada. Isso muda tudo. Uma equipe de produto conversa com seus clientes, descobre o que é realmente doloroso, prioriza funcionalidades com base em necessidades reais, mede a adoção, não constrói algo e vai embora e eles continuam iterando. Então como é uma equipe de produto na prática? Eles não operam como um suporte técnico. Um desenvolvedor abre um chamado e a equipe de plataforma faz manualmente.

Isso não é engenharia de plataforma, é apenas operações centralizadas com um novo nome. Isso não escala, não reduz a carga cognitiva, apenas move o gargalo de uma equipe para outra. Eis o que eles fazem em vez disso, eles medem as coisas certas. Tempo para o primeiro deploy, velocidade de integração para novos membros da equipe, pontuações de satisfação dos desenvolvedores. Essas são as métricas que dizem se a plataforma está realmente ajudando as pessoas ou apenas adicionando outra camada de complexidade. Spotify é um bom exemplo. A equipe de plataforma deles funciona como uma organização de produto adequado. Eles têm wordmaps, eles têm OKRs, eles conversam com desenvolvedores sobre o que está funcionando e o que não está. Eles tratam a plataforma como algo que precisa conquistar sua adoção todos os dias e essa é a ideia principal. Uma plataforma que ninguém usa é apenas um projeto, está juntando poeira em um canto.

A adoção é a validação definitiva. Se os desenvolvedores escolhem sua plataforma em vez de criar suas próprias ferramentas, você conseguiu. Se eles a evitam, nenhuma quantidade de excelência técnica pode consertar isso. Isso significa para você. Significa que se você está construindo uma plataforma, não comece com diagramas de arquitetura, não comece com clusters, kubernetes ou módulos terraform, comece com entrevistas com usuários, converse com os desenvolvedores que usaram sua plataforma. Descubra o que é realmente doloroso. Construa uma coisa que resolva um problema real. Então, itere. É assim que você constrói algo que as pessoas realmente querem usar. Por que agora a onda da IA? Então, por que estamos falando sobre isso agora? Porque não há cinco anos. A resposta é IA. Ferramentas de codificação por IA, como o GitHub e o Copilot, permitem que desenvolvedores entreguem código a um ritmo que nunca vimos antes.

Dez vezes, vinte vezes mais código por dia do que era possível apenas alguns anos atrás. Isso parece incrível e é. Aqui está a pegadinha. Todo esse código ainda precisa de infraestrutura. Ainda precisa de segurança. Ainda precisa ser implantado, testado e operado. Mais código sem um sistema melhor não torna você mais rápido. Isso apenas torna o caos mais rápido. Se seus desenvolvedores já estão se afogando em IA e Terraform, a IA não conserta isso. Isso apenas significa que eles se afogam mais rápido enquanto produzem mais código que precisa exportar. Neste momento, cerca de 55% das organizações já adotaram engenharia de plataforma de alguma forma. Bertner prevê que esse número chegará a 80% até o final de 2026. Isso é uma tendência lenta. Essa é uma mudança que está acontecendo agora. Se empresas estão percebendo que não conseguem escalar suas equipes de engenharia sem uma camada de plataforma.

A abordagem antiga de cada equipe fazer tudo por conta própria simplesmente não funciona quando se entrega código na velocidade da IA. O que muitas pessoas não percebem. A IA não apenas cria necessidade de plataforma. Ela também ajuda a construir. Equipes de plataforma estão usando IA para gerar módulos Terraform, escrever documentação e depurar pipelines. A mesma tecnologia que cria urgência também fornece as ferramentas para resolvê-la. Agora uma palavra de cautela. A IA amplifica tudo o que você já possui. Se seus fundamentos são sólidos, como uma boa arquitetura e uma plataforma bem projetada, a IA torna você duas a três vezes mais produtivo. Mas se suas bases são fracas, a IA apenas ajuda você a cometer erros maiores mais rapidamente. Configurações ruins, brechas de segurança, infraestrutura quebrada, tudo entregue em produção antes que alguém perceba. A IA não conserta bases ruins.

Ela as expõe. Aqui está um exemplo real. Uma empresa com uma boa plataforma interna de desenvolvedor pode permitir que um não-engenheiro implante ferramentas de aquossegurança. A plataforma fornece proteções. Ela impõe políticas de segurança. Ela cuida da infraestrutura. Assim, um gerente de produto pode criar um protótipo com IA sem precisar entender de Kubernetes ou redes em nuvem. Isso é poderoso. Esse é o tipo de coisa que separa equipes prontas para a era da IA daquelas que ficarão para trás. O que significa para você? A janela para construir uma plataforma está se fechando. Não porque a tecnologia vai desaparecer, mas porque a diferença entre equipes com plataformas e equipes sem elas está aumentando rapidamente. A cada mês que você espera, as equipes que já possuem plataforma se distanciam ainda mais. Elas entregam mais rápido, sofrem menos esgotamento e se adaptam a novas ferramentas com mais agilidade.

As equipes sem plataformas estão ficando cada vez mais para trás. A escolha é sua. Comece com o caminho dourado. Então por onde você realmente começa? Se você está pensando que precisa construir uma plataforma interna de desenvolvedor do zero, pare. Essa é a maneira mais rápida de matar seu projeto antes mesmo de começar. O maior erro que as equipes cometem é tentar construir tudo de uma vez. Elas passam meses projetando a plataforma perfeita, inserindo cada funcionalidade que conseguem imaginar. Então elas lançam e não ouvem nada. Ninguém a utiliza. Porque resolve problemas que ninguém pediu. E só para começar é preciso ler um pequeno manual. O ponto é, não faça isso em vez de isso com mais pequeno. Converse de fato com os desenvolvedores. Não com os arquitetos, nem com os gestores, nem com suas próprias oposições. Encontre as pessoas que escrevem funcionalidades todos os dias. Pergunte onde dói.

Encontre o fluxo de trabalho que mais demora, que mais frustra as pessoas ou que é mais ignorado do que deveria. Então construa exatamente um caminho dourado e ponto a ponto. Talvez seja criar e implantar um novo microserviço. Talvez seja configurar um ambiente de desenvolvimento do zero. Talvez seja enviar uma correção para a produção sem quebrar nada. Escolha o que mais incomoda e construa um caminho que faça essa dor desaparecer. Construa. Teste com usuários reais. Colete feedback e íter. Depois adicione outro caminho, outro depois desse. Não tente resolver todos os problemas de vez. Resolva um problema muito bem e deixe o impulso te levar adiante. Vamos saber se está funcionando. Essas coisas certas. O tempo da ideia é o primeiro deploy. Número de tapas manuais eliminadas e taxas de adoção voluntária. Se os desenvolvedores escolhem seu caminho, em vez de criar o deles, você está ganhando.

Se eles estão evitando, escute e mude a direção. Aqui está a armadilha evitar. Não torne a plataforma obrigatória. Force os desenvolvedores a seguir seu caminho e eles vão se ressentir. Eles encontrarão formas de contornar. Eles criarão seus próprios scripts e os esconderão. Em vez disso, torne o caminho fácil. Torne-o mais rápido que a alternativa. Torne-o a escolha óbvia, mas nunca única. O primeiro caminho é sempre o mais difícil. Ele te ensina tudo sobre pensamento de produto. Você aprende a falar com usuários, a priorizar e que construir algo que as pessoas realmente querem é bem mais difícil do que construir algo que apenas funciona. Uma vez que você fez isso, o segundo caminho fica mais fácil e o terceiro ainda mais. Você não está construindo a plataforma de uma só vez. Você está construindo um caminho de cada vez. Esse é o sistema. Engenharia de plataforma é sobre construir a estrada pavimentada para que os desenvolvedores foquem em dirigir em vez de consertar buracos.

Se você está cansado de lutar com a infraestrutura, comece encontrando um caminho dourado na sua equipe apenas um. Compartilhe isso com alguém que precise ouvir e inscreva-se para mais análises como esta. Obrigado.