Mercado Livre Fury: do monólito Oracle a cerca de 30 mil deploys por dia

01 · CONTEXTO

O Marketplace de 1999: um monólito

Em 1999 o Mercado Livre lançou a primeira versão do Marketplace como um monólito. A plataforma tinha algumas centenas de servidores físicos, um único banco Oracle e um único repositório, no qual mais de 200 desenvolvedores trabalhavam todos os dias.

1. O diagrama mostra usuários falando com uma única aplicação, que por sua vez fala com um único banco.

2. Em 1999 o Marketplace nasceu como monólito: algumas centenas de servidores físicos, um único banco Oracle e um único repositório, usado por mais de 200 desenvolvedores todos os dias.

3. Os deploys eram semanais e exigiam congelamento de código para entregar a solução à equipe de qualidade.

4. Como todos mexiam na mesma base, mudanças podiam gerar funcionalidades em conflito: uma funcionava e as outras quebravam.

Os deploys eram semanais e exigiam congelamento de código para entregar a solução à equipe de qualidade. Como todos alteravam a mesma base, as mudanças podiam gerar funcionalidades em conflito.

02 · MELICLOUD

Microsserviços sem plataforma: liberdade caótica

Por volta de 2010 a empresa tomou uma decisão crítica: adotar uma infraestrutura mais escalável baseada em microsserviços. A migração foi para uma plataforma chamada MeliCloud, que trouxe infraestrutura como serviço.

Nessa fase a fonte cita 17.500 instâncias. Mas a flexibilidade veio com um preço: as equipes passaram a gastar muito tempo resolvendo problemas operacionais de produção em vez de melhorar o produto, e havia diferenças substanciais entre os ambientes de desenvolvimento, stage e produção.

03 · FURY

Fury: a plataforma interna nasce em 2015

A necessidade era ter um lugar único para infraestrutura, build, deploy, métricas e serviços, e colocar uma aplicação no ar em três cliques. Foi assim que nasceu a Fury, em 2015: uma plataforma interna de desenvolvimento (IDP) feita em casa, para criar, implantar, gerenciar e monitorar aplicações.

Criar uma aplicação já gera o repositório com as permissões da equipe, monta o pipeline de CI/CD e entrega um scaffolding com imagem containerizada. Para garantir confiabilidade, aplicações críticas são divididas em escopos separados, e a falha em um escopo não afeta os outros.

1. No diagrama, a equipe fala com a plataforma interna, que aciona o pipeline de CI e o orquestrador de deploy.

2. Ao criar uma aplicação, a plataforma gera o repositório com as permissões da equipe, monta o pipeline de CI/CD e entrega um scaffolding com imagem containerizada.

3. O build produz um artefato, tipicamente uma imagem Docker, publicado no registry interno; uma versão gerada não muda mais.

4. O orquestrador usa o artefato já gerado e orquestra sua execução em um ou mais escopos, sem precisar reconstruí-lo.

5. Toda mudança significativa passa por ao menos um ambiente de validação antes de afetar usuários finais ou sistemas críticos.

6. A plataforma mede cada etapa do ciclo de deploy; em produção crítica o alerta exige atenção imediata, tratada por rotações de on-call.

O processo de release, em vigor desde 2018, roda sete validações de qualidade sobre mais de 26 mil repositórios; se uma verificação falha, o fluxo inteiro é interrompido até a correção.

04 · DEPLOY

Construir é uma coisa, implantar é outra

A Fury separa explicitamente o build, que cria a versão, do deploy, que a executa. Uma versão gerada é imutável, e a mesma versão pode ser implantada várias vezes em escopos ou configurações diferentes, sem rebuild.

Não existe abordagem única de deploy: a estratégia varia com a criticidade do cenário. Estratégias que reutilizam infraestrutura existente são rápidas e baratas, porém difíceis de reverter; já o Blue-Green, que cria um ambiente novo, é indicado para escopos produtivos que exigem recuperação rápida em caso de erro. Entre as estratégias suportadas estão Blue-Green, Canary-Safe, Rolling Update e All-In.

1. O diagrama mostra um controle de tráfego que reparte os usuários entre a versão atual e a versão nova.

2. No Blue-Green a versão nova é implantada no ambiente passivo sem afetar o tráfego real; depois de validada, o tráfego é redirecionado e a troca é instantânea.

3. No Canary a versão nova recebe só uma pequena parte do tráfego, enquanto o resto segue na versão anterior.

4. A versão nova é monitorada em produção real com usuários reais e, se tudo funciona como esperado, o tráfego é aumentado aos poucos.

5. Com rollback programável, em caso de falha ou métricas anômalas o deploy pode ser revertido automaticamente.

Cada escopo é categorizado por nível de criticidade, e essa classificação define o risco de qualquer mudança. A plataforma também oferece rollbacks programáveis, que revertem automaticamente em caso de falha ou métricas anômalas.

05 · ESCALA E OPERAÇÃO

Os números, sempre com o ano ao lado

Os números do caso vêm de três fontes de anos diferentes, e por isso cada um aparece com o ano da sua fonte.

A Fury conta como deploy qualquer ação que atualiza o estado de uma aplicação em um ambiente. Isso inclui mudar variáveis de ambiente ou configuração, e também re-deploys automáticos, como o disparado quando um sidecar é atualizado ou quando o monitoramento sugere reduzir CPU e memória. A própria fonte aponta a automação como um dos habilitadores de rodar 30 mil deploys por dia.

Os sidecars dão mais controle de segurança, conformidade e NoOps em cada microsserviço; a palestra cita proxy de MySQL, middleware de tráfego e agentes de logs e de métricas. A diversidade de linguagens, por outro lado, aumenta a complexidade de operar em escala.

Cada passo do deploy é idempotente e pode ser repetido sem deixar o sistema inconsistente. Alertas de escopos de teste têm SLA de baixa prioridade; em produção crítica o alerta exige atenção imediata, tratada por rotação de on-call.