Do Spinnaker ao Temporal Como a Netflix Reduziu Falhas de Deploy de 4% para 0.0001%

Em sistemas distribuídos de grande escala, falhas transitórias são uma realidade inevitável. Na Netflix, que implanta milhares de microsserviços globalmente, o Spinnaker tem sido o motor central de entrega contínua (CD). No entanto, limitações no serviço Clouddriver do Spinnaker — particularmente sua lógica interna complexa de orquestração e gerenciamento de estado — levaram a aproximadamente 4% dos deploys falhando devido a problemas de Operação em Nuvem (Cloud Operation). Este post explora a jornada da Netflix ao adotar o Temporal, uma plataforma de Execução Durável (Durable Execution), para resolver esse problema fundamentalmente e reduzir drasticamente as taxas de falha de deploy de 4% para 0.0001%. Para a fonte original, consulte o artigo do Netflix Tech Blog.

O Calcanhar de Aquiles do Clouddriver do Spinnaker

Dentro do Spinnaker, o Clouddriver era responsável por executar mutações na infraestrutura de nuvem (ex.: criar/deletar grupos de servidores). Quando o Orca (o motor de orquestração) solicitava trabalho ao Clouddriver, este tinha um processo interno complexo para decompor e executar essas operações como AtomicOperations de nível inferior. Essa arquitetura tinha várias falhas fundamentais:

1. Orquestração Interna Complexa: O Clouddriver precisava implementar sua própria lógica para rastreamento de estado de tarefas, retentativas e rollbacks (um padrão Saga). Isso era um "trabalho indiferenciado (Undifferentiated Lifting)" não relacionado ao seu objetivo principal de executar mudanças na infraestrutura.
2. Estado Local à Instância: O estado de execução da tarefa era armazenado na memória de uma instância específica do Clouddriver. Se essa instância caísse, o estado da tarefa em andamento era completamente perdido.
3. Acoplamento Forte (Tight Coupling): O Orca precisava ter conhecimento íntimo da API específica de polling de status e dos padrões de tratamento de erros do Clouddriver.

Apesar dessa complexidade, fornecer um tratamento robusto para falhas transitórias — como instabilidade de rede ou interrupções do provedor de nuvem — permanecia desafiador, manifestando-se finalmente em uma taxa de falha de deploy de 4%.

A Mudança de Paradigma com o Temporal: Programando 'Como Se Falhas Não Existissem'

O Temporal fornece Execução Durável (Durable Execution). Os desenvolvedores simplesmente estruturam sua lógica de negócio em Workflows (uma série determinística de etapas) e Activities (trabalho externo não determinístico, ex.: chamadas de API). O servidor Temporal então armazena e gerencia de forma durável o estado de execução. Se um processo Worker morrer, ou mesmo se estiver no meio de um sleep de 30 dias, o Temporal pode preservar o estado e retomar a execução em outro Worker.

Arquitetura Pós-Migração com Temporal:

1. Em vez de fazer requisições diretas ao Clouddriver, o Orca usa um cliente Temporal para iniciar um Workflow UntypedCloudOperationRunner.
2. Um Worker do Clouddriver pega a tarefa do Workflow, interpreta o payload e executa o Child Workflow CloudOperation apropriado.
3. O Child Workflow executa Activities que fazem as chamadas reais à API do provedor de nuvem.
4. O Orca aguarda de forma assíncrona a conclusão do Workflow via seu cliente Temporal.

Essa mudança significou que o Clouddriver não precisava mais implementar orquestração complexa, gerenciamento de estado ou lógica de retentativa por conta própria — tudo isso se tornou responsabilidade da plataforma Temporal.

Resultados e Principais Aprendizados

Principais Resultados:

• Taxa de Falha de Deploy: 4% → 0.0001% (uma melhoria de aproximadamente 40.000x).
• Redução de Acoplamento: Orca e Clouddriver tornaram-se acoplados de forma frouxa via Temporal como intermediário.
• Stateless (Sem Estado): As instâncias do Clouddriver tornaram-se stateless, permitindo que fossem tratadas como gado (cattle) e habilitando práticas como o Chaos Monkey.
• Melhoria na Observabilidade: A UI do Temporal tornou significativamente mais fácil depurar e monitorar Workflows em execução em produção em tempo real.

Lições Práticas Aprendidas:

1. Evite Child Workflows Desnecessários: Usar Child Workflows puramente para organização de código pode complicar a depuração. Considere composição de classes em vez disso.
2. Use Objetos de Argumento Único: Alterar a assinatura de um método de Workflow/Activity pode quebrar Workflows de longa duração. Usar uma única classe serializável para conter todos os argumentos é um padrão mais seguro.
3. Separe Falhas de Negócio de Falhas de Workflow: Usar um tipo wrapper como WorkflowResult para comunicar falhas de lógica de negócio separadamente de falhas de execução de Workflow permite um tratamento de erros mais matizado.

Essa migração bem-sucedida catalisou a adoção generalizada do Temporal na Netflix, que agora aproveita o Temporal Cloud (SaaS) para centenas de casos de uso diversos. Este caso serve como um valioso estudo para qualquer arquiteto projetando sistemas distribuídos que devem alcançar confiabilidade em meio à complexidade.