divisão do monólito
Monólito para microsserviços: o primeiro serviço no ar até o dia 20
Quatrocentas tabelas num schema só, e um release por trimestre porque ninguém consegue fazer deploy de uma parte sozinha. Engenheiros que entregam em produção há mais de 25 anos dividem tudo: primeiro serviço no ar até o dia 20, o resto até o dia 30.
Mande hoje o tamanho do repositório e a cadência de releases. Em 48 horas você sabe onde estão as costuras e quanto custa.
Um repositório, um schema, um release por trimestre e imports que andam em círculo.
- one deployable11 years of commits
- shared schema400+ tables
- release trainquarterly
- circular importscycles
Primeiro serviço até o dia 20, divisão concluída até o dia 30
Serviços com schema e pipeline próprios, uma pequena biblioteca compartilhada, deploy quando cada time estiver pronto.
- billingGo · own schema
- catalogueGo · own schema
- shared kernellibrary
- deploysper service
Primeiro o schema se divide, depois o código se move
- 01dias 1–4
Achar as costuras nos dados
Os logs de consulta mostram quais tabelas são lidas juntas na mesma requisição. É ali que ficam as fronteiras, diga o que disser a estrutura de pacotes.
- 02dias 3–9
Dividir o schema primeiro
As tabelas se separam e os joins entre fronteiras somem enquanto tudo ainda é um deploy só. A maior parte do risco mora neste passo, e aqui ele ainda é reversível.
- 03dias 8–20
Extrair o primeiro serviço
Pegamos o que tem menos dependências de entrada, que raramente é o que mais irrita as pessoas. Ele roda em produção atrás da mesma interface até o dia 20.
- 04dias 18–30
Pipeline próprio, depois o próximo
O serviço ganha repositório, deploy e escala de plantão próprios. Os próximos vêm mais rápido pelo mesmo método, e a partir do dia 30 os seus times fazem release sem esperar a janela de ninguém.
A plataforma mede, os engenheiros escolhem o corte
Mapear o acesso conjunto às tabelas e o acoplamento de módulos
Plataforma
A partir dos logs de consulta e do grafo de chamadas, num período longo o bastante para incluir um fechamento de mês.
Propor as costuras
Os dois
A plataforma ranqueia as candidatas. Um engenheiro confere cada uma contra as fronteiras dos seus times.
Quebrar os joins entre fronteiras
Plataforma
Trabalho mecânico, revisado como pull request, entregue em pedaços pequenos que o seu time consegue acompanhar.
Escolher qual serviço sai primeiro
Engenheiro
Quem decide isso, mais vezes do que o código, é a divisão de responsabilidades entre os times.
Fronteiras de transação
Engenheiro
Onde uma transação atravessava a costura, decidimos o que acontece em caso de falha e deixamos por escrito.
Pipelines, deploys e plantão
Os dois
Montamos cada pipeline e cada escala com o seu time, para que eles operem os serviços desde o primeiro deploy.
Uma costura está certa quando a maioria das mudanças depois da divisão toca um lado só. Medimos isso antes de dar o trabalho por encerrado.
Quem corta a costura
Os nossos engenheiros colocam código em produção há mais de 25 anos, e são os melhores que você pode pôr nesta divisão. Monólitos em Rails, Django, Spring, .NET, Node, PHP e Go, schemas com quatrocentas tabelas e uma década de joins entre fronteiras: dezenas de migrações. A costura nunca está onde o diagrama de arquitetura diz, e eles acham a verdadeira.
Preço fechado antes do corte, e o dia em que o primeiro serviço faz deploy sozinho vai para o contrato. Serviço que não bate com o monólito no seu tráfego não é aceito.
O que os líderes de engenharia perguntam antes de dividir
Com quantos serviços devemos terminar?
Tantos quantos times você tiver para serem donos deles, o que dá menos do que mostra a apresentação de arquitetura. Extraímos o primeiro, rodamos em produção, e os dados mostram onde vai o próximo corte. Mande o repositório hoje e receba o mapa de costuras com preço em 48 horas.
Temos que reescrever em Go?
Só onde compensa. Extrair e reescrever são decisões separadas, e muitos serviços ficam na linguagem original. Onde o monólito queima memória em Java ou Python, uma reescrita em Go corta a conta de instâncias no mesmo cronograma. Diga quais módulos custam mais para rodar.
Dá para continuar entregando funcionalidades durante a divisão?
Sim. O passo que protegemos é a separação do schema, dias 3–9, e planejamos o seu calendário de releases em volta dele com você. Todo o resto anda enquanto o seu time entrega. Mande a sua cadência de releases e encaixamos o plano nela.
E o banco compartilhado de que todo mundo avisa?
É por isso que o schema se divide primeiro. Dois serviços no mesmo schema são um monólito distribuído que falha de jeitos piores do que aquele com que você começou, e nunca entregamos isso. Peça o orçamento e veja o plano do schema antes de qualquer código se mover.
O que acontece com o código compartilhado?
Vira uma biblioteca versionada com superfície pequena. Se essa biblioteca cresce a cada sprint, a costura está no lugar errado, e a mudamos durante o projeto, enquanto ainda é barato. Mande o repositório e apontamos as costuras em 48 horas.
Tire o primeiro serviço do monólito
Passe para nós o tamanho do repositório, a cadência de releases e o que está forçando a mudança. Em 48 horas você tem as costuras, um preço fechado e uma data. Até o dia 20 o primeiro serviço faz deploy sozinho.
Um engenheiro com mais de 25 anos em produção lê o formulário. A primeira pergunta é sobre a sua cadência de releases.