Engenharia de plataforma com o Fury do Mercado Livre

Com Julia Pedrosa, Juliano Martins e Marcelo Quadros

Como transformar uma infraestrutura massiva em um produto de plataforma que os times realmente queiram usar? No Kubicast #190, abrimos a caixa-preta do Fury, a plataforma do Mercado Livre que nasceu há quase 12 anos e hoje concentra mais de 80% da tecnologia da companhia. Nesta conversa, falamos sobre DX na veia (templates, SDKs e Backstage), operação sem “kubectl em produção”, multicloud com parcimônia, governança, segurança e os trade-offs que só aparecem quando a escala é continental.

Por que o Fury existe

Quando o Mercado Livre começou a migrar de VMs para um modelo mais cloud native, ficou claro que não dava para escalar pedindo que cada equipe montasse sua própria plataforma. O Fury nasce desse incômodo: oferecer autonomia com guardrails, de forma opinativa, para que centenas de squads consigam publicar e operar serviços com o mesmo baseline de segurança, observabilidade e confiabilidade.

Um dos dados que mais nos chamou atenção no episódio: cerca de 85% do stack do Meli roda no Fury. Esse número sozinho explica por que Platform Engineering virou disciplina central lá dentro.

DX como produto: templates, SDKs e Backstage

Nada de “framework da plataforma” que obriga o time a decorar YAML para começar. No Fury, a experiência do desenvolvedor começa por templates: a partir do Backstage, o time gera um esqueleto de serviço (React, Go, etc.), já com pipelines, testes, políticas e guardrails prontos para uso. A partir daí, é “git commit e segue o jogo”.

Mais do que provisionar, a plataforma oferece SDKs e CLIs que embutem boas práticas (deploy, configuração, observabilidade mínima, segredos com Vault, e por aí vai). O objetivo é cristalino: reduzir o atrito cognitivo sem esconder o suficiente a ponto de impedir a evolução dos times.

Operar sem “kubectl em produção”

A plataforma assume de vez o papel de orquestradora de operações. Fluxos de deploy e rollout contam com estratégias pré-empacotadas (blue/green, canary), e ferramentas como Argo reduzem drasticamente o “trabalho de cola” que todo mundo já fez um dia. O resultado? Menos toque manual, menos ticket, menos pager por besteira.

Multicloud (mesmo) ou “muitas clouds”?

O papo desromantiza o termo multicloud. A equipe é direta: multicloud só quando há valor claro. O Fury abstrai onde faz sentido (recursos que precisam existir em GCP e AWS, por exemplo), mas evita prometer portabilidade universal. O foco é confiabilidade e velocidade para os produtos do Meli, não “checkbox de buzzword”.

Observabilidade e segurança na prática

Escala sem observabilidade é loteria. O Fury fornece telemetria padrão (logs, métricas e tracing) e integrações prontas para os times não precisarem “aprender PromQL às 3 da manhã”. No eixo de segurança, os guardrails entram cedo (checagens, cobertura, segredos, policies), e a plataforma puxa responsabilidades para o centro onde isso economiza esforço global e reduz risco.

Clusters e criticidade

Nem todo serviço é igual. O desenho leva em conta níveis de criticidade, isolamento e limites de explosão, escolhendo onde vale separar clusters e quando multitenancy resolve. Essa segmentação evita pagar caro por padrões “tamanho único” e cria caminhos claros para times com demandas especiais.

Dicas de carreira dos convidados

Para quem quer trilhar Platform Engineering: comece entendendo as dores dos times; aprenda a dizer “não (ainda)” com bons motivos; e não subestime habilidades de produto (descoberta, métricas, feedback). O brilho de uma plataforma está em quanto ela some do dia a dia dos devs — e não no número de componentes novos que ela exibe.

Curtiu? Assine o Kubicast, compartilhe com o time de plataforma e marque a gente com suas perguntas. E se seu time está nessa jornada, conte pra nós.

Ouça também no Spotify.