Entrevista com Greg Burrell da Netflix. Um dos criadores do modelo Full Cycle

Faz mais ou menos dois anos que, pela primeira vez, tinha ouvido o termo...

Full Cycle Developer.

É isso mesmo, alguém me enviou uma ligação do blogue de tecnologia da Netflix,

e li aquele artigo do pessoal a falar sobre os desafios na Netflix.

Eles tentaram organizar a estrutura de desenvolvimento de várias formas,

e uma solução que encontraram foi através deste modelo chamado Full Cycle Developers.

O mais fixe de tudo isto é que, quando li aquilo pela primeira vez, fez-me todo o sentido,

porque era exatamente a forma como eu pensava e como agia na minha vida profissional há anos.

Fiquei mesmo apaixonado pelo modelo e percebi conceitos que ainda não tinha notado.

Maratona Full Cycle 3.0

E hoje estamos aqui na Maratona Full Cycle, dois anos depois,

onde tenho tentado transmitir estes conceitos a muitos desenvolvedores.

Temos o nosso curso para ajudar a formar Full Cycle Developers com experiência prática

a criar sistemas com microsserviços.

Mas eu queria muito que toda a gente ouvisse esta história de Full Cycle diretamente da fonte,

da pessoa que organizou este modelo no dia zero e o tornou escalável e de sucesso na Netflix.

Por isso, fiz de tudo para encontrar este homem: chama-se Greg Burrell,

e trabalha na Netflix há 15 anos.

Ele acompanhou a transição do envio de DVDs pelo correio até à Netflix atual.

Consegui falar com ele e pedi-lhe esta entrevista, sabendo que todos iriam adorar.

Ouvir diretamente dele os pontos principais de como funciona o Full Cycle

será um enorme contributo para muitos desenvolvedores. O Greg aceitou o convite!

O meu nome é Wesley Williams e sou do projeto Full Cycle.

Maratona Full Cycle 3.0 - Entrevista

Olá, Greg! Como estás?

Tudo bem, olá!

Muito prazer em conhecer-te, Greg. Muito obrigado por estares aqui. Sei que estás muito ocupado,

mas tenho a certeza de que a nossa comunidade vai adorar esta entrevista.

Obrigado por esta oportunidade de conversar contigo.

Com certeza. Greg, o tema de hoje é o modelo de Full Cycle Developers,

mas podes apresentar-te brevemente, falar da tua carreira e da tua história na Netflix?

Claro! Chamo-me Greg Burrell, vivo na Califórnia, no Silicon Valley, nos EUA.

Estou na Netflix há 15 anos. Quando comecei em 2005, a empresa explorava a ideia:

'E se pudessemos enviar filmes pela Internet?' Pois até aí enviávamos DVDs pelo correio.

O negócio dos DVDs corria bem, mas perguntámo-nos se podíamos entregar filmes mais depressa.

Surgiu a Internet e começámos a fazer pequenas experiências dentro da empresa.

Eu fazia parte dessa equipa experimental, quase como uma startup dentro da empresa.

Durante vários anos, testámos como tornar isso um modelo de negócio viável e escalável.

Sabíamos que, se funcionasse, iria crescer imenso a nível mundial.

Livre dos limites do serviço de correios dos EUA, o mundo inteiro abriu-se para nós.

Queriamos fazer tudo bem, sem complicações técnicas nem confusão para os clientes.

Após anos de trabalho, sentimos que os clientes estavam finalmente prontos para a plataforma.

Acompanhei toda essa evolução, reestruturações e testes de vários modelos de trabalho.

Dessa experiência nasceu o conceito do modelo de Full Cycle Developer.

Para mim parecia algo natural, mas decidimos partilhar o modelo no nosso blogue de tecnologia.

E é por isso que estamos aqui a conversar hoje!

Uau! Quando li o teu artigo pela primeira vez, pensei: 'É exatamente isto que penso!'

Sobretudo pelo sentimento de compromisso e responsabilidade que os desenvolvedores devem ter,

o sentido de operar, testar e ser responsável por tudo o que se constrói.

Essa mentalidade é fundamental no Full Cycle Developer, ao contrário da visão antiga

onde o desenvolvedor só escreve código e passa o resto para as equipas de operações.

Como definirias tu, em poucas palavras, o modelo de Full Cycle Developer?

Tocaste nos dois pontos-chave: responsabilidade e mentalidade.

Não é um conjunto fixo de tecnologias, é a atitude de assumir todo o ciclo de vida do software:

desde a conceção, desenvolvimento, testes, até à implantação e operação.

Mesmo que existam equipas de testes, tu continuas a ser o principal responsável pelos testes,

pois tu desenhaste o software. E o mesmo se aplica ao deployment e à operação diária.

Tens de monitorizar a saúde do serviço, gerir erros, capacidade de escala e a experiência do utilizador.

E os clientes podem ser os utilizadores finais ou outras equipas internas que consomem a tua API.

Exato, outros desenvolvedores a consumir a tua API.

Exatamente. Fazes parte de um ecossistema, consomes APIs de outros e outros consomem a tua.

Tens de garantir o bom funcionamento do teu serviço e prestar suporte quando surgem problemas.

Apoiar outras equipas a resolver erros na integração faz parte de operar o teu serviço.

O Full Cycle é a mudança de mentalidade de apenas 'escrever código' para assumir todo o ciclo,

dando igual valor a todas as etapas, desde o desenvolvimento até às operações.

Manter o serviço estável em produção é tão importante quanto adicionar novas funcionalidades.

De nada serve criar muitas funcionalidades se o serviço falhar em produção ou for difícil de usar.

Garantir documentação clara, responder ao suporte e manter testes e deployments limpos

tem a mesma importância que escrever novo código. É essa a grande transformação.

Não acaba quando fazes o commit no repositório; esse é apenas o início do ciclo.

Qual é a diferença entre um Full Cycle Developer e um Full Stack Developer?

E qual a diferença para um desenvolvedor que domina DevOps?

Ótima pergunta! Estes conceitos variam um pouco consoante a perspetiva de cada um.

Um Full Stack Developer trabalha tanto no front-end como no back-end, focando-se no código.

Na Netflix contratamos muitos Full Stack Developers, mas no modelo Full Cycle

a responsabilidade não acaba no código: estende-se aos testes, deployment, operações e suporte.

Quanto a alguém que 'sabe DevOps', muitas vezes vê o DevOps como uma tarefa secundária.

No Full Cycle, o desenvolvedor envolve-se ativamente na observabilidade, métricas e suporte.

Se deixarmos as operações em segundo plano quando há prazos apertados, elas acabam por ser ignoradas.

E o desenvolvedor acaba por dizer ao administrador de sistemas: 'O meu trabalho está feito!'

Exato! No Full Cycle, pensas na escala, na monitorização e nos alertas desde o primeiro momento.

Isso cria um ciclo de feedback rápido na própria equipa, melhorando continuamente o serviço.

Se notamos falhas na monitorização ou no suporte, melhoramos o código e a documentação.

No passado tínhamos silos: o desenvolvedor entregava o código, o operador fazia o deployment,

e quando algo corria mal, as equipas culpavam-se mutuamente sem que ninguém visse o todo.

'Entreguei código excelente, o problema foi da equipa de operações!'

E os administradores diziam: 'Deram-nos código com defeito!' No Full Cycle acabam as desculpas,

pois se sentes a dor de operar o serviço, tens todo o poder e autonomia para a corrigir.

Algumas pessoas dizem que isto é uma estratégia para poupar dinheiro e contratar menos gente.

É preciso aumentar a equipa para haver entreajuda e tempo de aprendizagem?

Se o objetivo da empresa for apenas cortar custos com este modelo, irá falhar redondamente.

Na Netflix acabámos por precisar de mais recursos humanas, não de menos.

Não podes acumular operações e suporte sobre um horário de desenvolvimento já preenchido.

Isso gera burnout e prejudica a qualidade do produto e dos serviços.

A chave é reconhecer que todas as fases do ciclo têm o mesmo valor e exigem tempo dedicado.

Quando um desenvolvedor está de piquete (on-call), não deve ter tarefas de novo código,

focando-se em responder a alertas, melhorar dashboards e otimizar a observabilidade.

Em vez de programar 7 horas por dia, o tempo é distribuído entre código, testes e operações.

O segundo ponto crucial é o investimento em formação e em ferramentas de qualidade.

Criámos equipas dedicadas a construir ferramentas como o Spinnaker para simplificar o deployment.

Estas equipas centrais oferecem consultoria e suporte em áreas como a segurança.

Em suma, criámos uma plataforma que capacita os Full Cycle Developers a gerir todo o ciclo.

Vocês criaram um ecossistema de ferramentas para dar total autonomia aos desenvolvedores.

Quantas pessoas costumam ter nas vossas equipas de desenvolvimento?

Normalmente são equipas pequenas, entre 10 a 12 pessoas em média.

Cada equipa é responsável por um ou mais microsserviços específicos, como o serviço de DRM.

Eles conhecem todos os detalhes e o desempenho desse serviço dentro da plataforma.

Essa autonomia traz um forte sentimento de propriedade e dedicação ao produto.

É muito semelhante ao espírito de uma startup, onde cada um assume vários papéis.

É como ter uma mini-startup para cada microsserviço!

Exatamente! Conseguimos manter essa agilidade e responsabilidade numa grande empresa.

Que conselho darias aos desenvolvedores que querem adotar o modelo Full Cycle?

Especialmente aqueles que trabalham em empresas sem esta infraestrutura de apoio?

Primeiro que tudo, estamos sempre a contratar na Netflix!

O meu conselho principal é ter uma conversa transparente com a chefia ou gestão.

Explicar os benefícios de aprender sobre operações e negociar tempo para essa formação.

Não precisa de ser uma transição brusca; pode ser um processo gradual e contínuo.

Com a mudança de mentalidade, os desenvolvedores ficam mais motivados e a empresa ganha muito.

Muito obrigado pelo teu tempo, Greg! Esta conversa foi fantástica.

Obrigado pela oportunidade! Sou apaixonado por este tema. Muito obrigado!

Obrigado, Greg! [Encerramento Maratona Full Cycle]