O Poder do CTO: Netflix – A pane de 2008 e os sete anos de migração para a nuvem

Em agosto de 2008, uma corrupção grave no banco de dados da Netflix interrompeu por três dias o envio de DVDs aos assinantes. O episódio levou a empresa a abandonar os próprios data centers e migrar toda a operação para a nuvem da Amazon Web Services (AWS). A migração levou sete anos e terminou no início de janeiro de 2016. A Netflix não copiou seus sistemas para a nuvem: reconstruiu praticamente toda a tecnologia.

O caso é referência para quem pensa na carreira de CTO porque reúne as três decisões que definem a função: o que mudar, com que arquitetura e em quanto tempo.

O que aconteceu em 2008?

Uma falha no banco de dados, o sistema central que guardava as informações da operação. Durante três dias, a Netflix não conseguiu despachar DVDs, e cada dia sem envio significava assinantes sem filme.

O incidente levou a empresa a repensar a arquitetura, e não apenas a consertar aquele banco de dados. A lógica é a do ponto único de falha: quando uma peça central para, tudo para com ela, e corrigir o defeito de um dia não elimina o risco do próximo.

Por que a Netflix escolheu a nuvem?

Para ganhar confiabilidade e capacidade de crescer. A empresa escolheu a AWS por oferecer, nas palavras do comunicado que anunciou o fim da migração, “a maior escala e o conjunto mais amplo de serviços e recursos”.

O mesmo texto faz uma afirmação que surpreende quem associa nuvem a economia: a redução de custos “não foi o principal motivo” da decisão. O objetivo era disponibilidade e escala.

Por que a migração levou sete anos?

Porque a Netflix escolheu reconstruir em vez de transportar. Havia dois caminhos:

• Levar os sistemas como estavam (“lift and shift”), mudando apenas o lugar onde rodavam. Mais rápido, mas, segundo a própria empresa, isso significaria “levar todos os problemas e limitações do data center junto”.
• Reconstruir para a nuvem, redesenhando os sistemas para aproveitar o novo ambiente. Mais lento e mais caro no curto prazo.

A Netflix escolheu o segundo e reconstruiu “praticamente toda” a sua tecnologia. Dois movimentos definem a nova arquitetura:

1. De um sistema monolítico para centenas de microsserviços. Em vez de um programa grande que faz tudo, a operação passou a ser dividida em centenas de serviços pequenos e independentes.
2. De um banco de dados central para dados distribuídos, em bancos NoSQL, com modelo de dados desnormalizado.

O que muda com os microsserviços?

Muda o tamanho do estrago quando algo quebra. Em um sistema monolítico, uma falha pode derrubar tudo, como o banco de dados de 2008 derrubou os envios. Com centenas de serviços independentes, a falha de um deles afeta só a sua função, e o restante continua no ar.

Um exemplo hipotético: se o serviço que gera as recomendações de filmes cai, o assinante ainda consegue buscar um título e assistir, apenas sem as sugestões. Em uma arquitetura monolítica, o mesmo defeito poderia tirar o site do ar.

Qual foi o resultado?

Em fevereiro de 2016, a Netflix publicou o balanço da migração, assinado por Yury Izrailevsky, vice-presidente de computação em nuvem e engenharia de plataforma, com Stevan Vlaovic e Ruslan Meshenberg. Os números:

• Assinantes: a base de streaming era oito vezes maior que a de 2008.
• Consumo: o volume de visualização cresceu três ordens de grandeza em oito anos, cerca de mil vezes.
• Disponibilidade: subiu de forma contínua e se aproximava da meta de “quatro noves”, ou 99,99% de tempo no ar.
• Custo: o custo por início de reprodução na nuvem ficou em “uma fração” do que era no data center.

Em 6 de janeiro de 2016, dias depois de desligar os últimos componentes do data center, a Netflix expandiu o serviço para mais de 130 novos países.

O que significa 99,99%?

Que o serviço pode ficar fora do ar por cerca de 52 minutos em um ano inteiro. Com 99,9%, o limite seria de quase nove horas. Cada nove a mais reduz o tempo de indisponibilidade tolerado em dez vezes, e exige uma arquitetura que sobreviva a falhas sem intervenção humana.

Por que a lentidão foi uma vantagem?

Porque a empresa nunca parou. A migração aconteceu enquanto a Netflix trocava o DVD pelo streaming e multiplicava por mil o volume de uso. Uma mudança brusca, feita de uma vez, colocaria em risco justamente o crescimento que a motivava.

Os sete anos também mostram uma escolha de prioridade. Reconstruir a base técnica é um trabalho que o assinante não enxerga, e mesmo assim a empresa o sustentou até o fim, porque a arquitetura antiga limitaria tudo o que viesse depois.

O que o caso Netflix ensina a quem quer ser CTO?

Ensina a ler um incidente como sintoma. O problema de 2008 foi um banco de dados corrompido. A causa era uma arquitetura com ponto único de falha. O CTO que corrige só o sintoma vai enfrentar o mesmo problema com outra roupa.

Ensina também que migrar não é copiar. Levar um sistema ruim para um ambiente novo preserva os defeitos. O trabalho do diretor de tecnologia é decidir quando vale reconstruir e convencer a empresa a financiar anos de trabalho que o cliente não vê. Formação, trajetória e remuneração da função estão na página de CTO (Diretor de Tecnologia) do Guia de Carreiras.