Filosofia de engenharia: Werner Vogels

Principais conclusões

• Seu princípio definidor é que tudo falha o tempo todo, então você projeta para a falha em vez de contra ela. Como CTO da Amazon desde 2005, Werner Vogels transformou uma observação direta – em escala suficiente, a falha de componentes é constante e estatisticamente garantida – em uma doutrina de design: presuma que cada disco, servidor, enlace de rede e dependência vai falhar, e construa sistemas que permaneçam disponíveis através da falha em vez de fingir que ela pode ser evitada.¹⁶
• Ele coescreveu o artigo do Dynamo, que foi pioneiro nas ideias por trás do NoSQL moderno. “Dynamo: Amazon’s Highly Available Key-value Store” (SOSP 2007) reuniu hashing consistente, relógios vetoriais, quóruns frouxos, associação baseada em gossip e consistência eventual em um único armazenamento sempre gravável, e influenciou diretamente Cassandra, Riak, Voldemort e o próprio DynamoDB da Amazon.²³
• Ele é o principal evangelista da consistência eventual. Seu ensaio “Eventually Consistent” expôs com clareza o trade-off entre disponibilidade e consistência: quando a rede se particiona – e, em escala, ela vai – você precisa escolher, e o Dynamo escolheu permanecer disponível e convergir logo em vez de bloquear até que cada réplica concorde.⁴⁷
• Ele deu à cultura de engenharia a frase “você constrói, você opera” (you build it, you run it). Em uma conversa de 2006, ele descreveu o modelo da Amazon no qual os desenvolvedores são donos de seus serviços em produção – delimitando-os, construindo-os e operando-os – e argumentou que colocar quem constrói no plantão e diante do cliente é o que impulsiona a qualidade.⁵

O princípio

“Tudo falha, o tempo todo.” – Werner Vogels, CTO da Amazon, sobre projetar sistemas distribuídos confiáveis⁶

A maior parte da engenharia otimiza para o caso em que tudo funciona. Você constrói o caminho feliz, trata os poucos erros que consegue imaginar e publica. Esse instinto sobrevive até o exato momento em que você opera em escala – e então ele te trai. Quando você está rodando centenas de milhares de máquinas, o “raro” deixa de ser raro. Uma falha de disco que ocorre uma vez a cada três anos por unidade ocorre em algum ponto da sua frota a cada poucos minutos. Um enlace de rede que perde um pacote em um milhão perde milhões de pacotes por dia. A frase mais famosa de Vogels comprime isso em quatro palavras: tudo falha o tempo todo.⁶ A falha não é uma exceção a ser contornada pela engenharia; em escala, ela é a condição de estado estacionário para a qual você precisa projetar.

O princípio que disso decorre é a inversão do usual. Se você não pode evitar a falha – e, em escala, comprovadamente não pode – então evitá-la é o objetivo errado. O objetivo certo é permanecer disponível enquanto as coisas estão falhando. Então você presume que cada componente vai morrer e projeta de modo que qualquer morte isolada seja sobrevivível: replica dados entre máquinas para que a perda de uma seja invisível, desacopla serviços por trás de APIs para que uma dependência que falha degrade um recurso em vez de derrubar o sistema, e minimiza o raio de impacto de qualquer falha para que ela não possa derrubar o todo. O sistema não é construído para evitar o caso de falha; é construído para que o caso de falha seja entediante.¹⁶

Há uma segunda metade do princípio, e é ela que torna real a primeira: você não pode ter consistência perfeita e disponibilidade perfeita ao mesmo tempo quando a rede pode se particionar, então você precisa escolher – e Vogels escolheu a disponibilidade. Quando uma divisão de rede corta o contato entre suas réplicas, um sistema pode ou se recusar a responder até que todos concordem (consistente, mas indisponível) ou continuar respondendo com o que tem e reconciliar depois (disponível, mas brevemente inconsistente). Para o carrinho de compras da Amazon, recusar-se a responder era inaceitável – um carrinho que rejeita um “adicionar ao carrinho” durante uma partição é um carrinho que perde uma venda.⁴ Então o Dynamo sempre aceita a gravação e deixa as réplicas convergirem depois. O custo é uma pequena janela na qual réplicas diferentes podem retornar respostas diferentes; a recompensa é um sistema que nunca diz “não” a um cliente. Esse trade-off – permanecer disponível e convergir logo em vez de bloquear até que todos concordem – é a consistência eventual, e Vogels passou uma carreira defendendo que é o trade-off certo em escala.⁴⁷

Contexto

Werner Vogels nasceu em 3 de outubro de 1958 em Ermelo, nos Países Baixos.¹ Seu caminho até a computação não foi a linha reta convencional através de uma universidade de elite. Ele estudou ciência da computação na The Hague University of Applied Sciences, concluindo em 1989, e só mais tarde obteve um doutorado em ciência da computação pela Vrije Universiteit Amsterdam – sua tese de 2003, “Scalable Cluster Technologies for Mission Critical Enterprise Computing”, foi orientada por Henri Bal e Andrew Tanenbaum, este último uma das figuras fundacionais da área em sistemas distribuídos e sistemas operacionais.¹ O detalhe que vale a pena guardar é que o doutorado veio depois de anos de trabalho real com sistemas em vez de precedê-lo; a teoria alcançou a prática.

O capítulo mais formativo veio na Cornell University, onde de 1994 a 2004 ele foi cientista pesquisador trabalhando em sistemas corporativos escaláveis e confiáveis.¹ Em Cornell ele esteve dentro do grupo de sistemas distribuídos de Ken Birman – a linhagem por trás do Isis e da comunicação de grupo confiável, o corpo de trabalho que perguntava como um conjunto de máquinas pode concordar, permanecer consistente e continuar funcionando à medida que seus membros falham e se recuperam. Ele cofundou uma empresa, a Reliable Network Solutions, com Birman e Robbert van Renesse, e atuou como seu VP e CTO.¹ Este é o solo intelectual em que Vogels cresceu: não “como impedimos que as máquinas falhem”, mas “como um grupo de máquinas permanece correto e disponível enquanto seus membros falham”. Quando mais tarde disse que tudo falha o tempo todo, ele não estava improvisando – estava enunciando a premissa fundadora da tradição de sistemas distribuídos confiáveis dentro da qual passara uma década.

Ele entrou na Amazon em setembro de 2004 como diretor de pesquisa de sistemas, foi nomeado CTO em janeiro de 2005 e acrescentou o título de VP em março de 2005 – o cargo que ocupa desde então, conduzindo a direção tecnológica de toda a empresa.¹ Sua chegada coincidiu com os anos em que a Amazon estava inventando a nuvem moderna: o sistema de armazenamento Dynamo foi construído e documentado nesse período, a Amazon Web Services lançou seus serviços fundacionais, e Vogels se tornou a voz pública dos princípios arquiteturais por trás de tudo isso – projetar para a falha, desacoplar via serviços, abraçar a consistência eventual e colocar as pessoas que constroem um serviço no comando de operá-lo.²⁴⁵

O trabalho

“Tudo falha o tempo todo”: projetar para a falha e a consistência eventual

Comece aqui, porque é o princípio transformado em engenharia. A doutrina tem dois movimentos. O primeiro é projetar para a falha: tratar cada componente como algo que vai falhar e fazer o sistema sobreviver à sua perda. Isso significa redundância (replicar para que qualquer cópia possa desaparecer), desacoplamento (os serviços conversam por APIs para que uma dependência doente se degrade com elegância em vez de cascatear) e contenção do raio de impacto (particionar o sistema para que uma falha fique presa em uma célula pequena em vez de se espalhar).¹⁶ O teste de um design não é “ele funciona quando tudo está saudável”, mas “o que acontece quando esta peça morre no pior momento possível” – e a resposta tem que ser “o sistema continua atendendo”.

O segundo movimento é o que torna a alta disponibilidade possível em escala: a consistência eventual. A observação CAP de Eric Brewer diz que, quando a rede se particiona, um sistema distribuído não pode ser ao mesmo tempo perfeitamente consistente e plenamente disponível – precisa abrir mão de um.⁷ O “Eventually Consistent” de Vogels torna a escolha explícita e define a alternativa com precisão: sob consistência eventual, “o sistema de armazenamento garante que, se nenhuma nova atualização for feita no objeto, eventualmente todos os acessos retornarão o último valor atualizado”.⁴ A palavra eventualmente é todo o trade-off. Um sistema que enfatiza a disponibilidade “pode sempre aceitar a gravação, mas, sob certas condições, uma leitura não refletirá o resultado de uma gravação recentemente concluída”.⁴ Por uma janela breve e limitada, duas réplicas podem discordar – mas nenhuma jamais se recusa a responder. A convergência acontece em segundo plano, e o usuário nunca fica bloqueado.

Por que isso importa como engenharia: o modelo mental que a maioria dos desenvolvedores tem de um banco de dados é o de uma única máquina, onde uma gravação é instantaneamente visível para toda leitura subsequente porque há apenas uma cópia. Esse modelo não sobrevive à escala, porque uma única cópia é um ponto único de falha e uma única máquina é um teto para a vazão. No momento em que você replica – o que precisa fazer para estar disponível – você herda a pergunta sobre o que um leitor enxerga enquanto as cópias estão se atualizando. A contribuição de Vogels foi insistir que isso não é um defeito a ser escondido, mas uma dimensão de design a ser escolhida deliberadamente, e dar aos engenheiros o vocabulário – read-your-writes, leituras monotônicas, consistência de sessão – para escolher exatamente quanta consistência uma dada carga de trabalho realmente precisa, em vez de pagar pela garantia mais forte em todos os lugares.⁴

O artigo do Dynamo e o movimento NoSQL

O princípio tem um artefato canônico: “Dynamo: Amazon’s Highly Available Key-value Store”, que Vogels coescreveu e que foi publicado no SOSP 2007, o principal fórum de sistemas operacionais da área.² O Dynamo foi a resposta da Amazon a um requisito específico e brutal – o carrinho de compras tinha que aceitar gravações sempre, mesmo durante partições de data center e falhas de disco, porque um carrinho indisponível perde receita diretamente.²³ Bancos de dados relacionais tradicionais, ajustados para consistência forte, não podiam prometer isso sob partição. Então a Amazon construiu um armazenamento que trocou consistência por disponibilidade e registrou exatamente como.

O Dynamo é um catálogo de técnicas de sistemas distribuídos montadas em um único sistema sempre gravável e descentralizado, e a influência do artigo vem de quão limpamente ele as expôs.²³ O hashing consistente particiona os dados entre os nós para que o anel possa crescer ou encolher sem reembaralhar tudo – “escalabilidade incremental, possivelmente linear”.³ Os relógios vetoriais rastreiam o histórico causal de cada valor para que gravações concorrentes possam ser detectadas em vez de silenciosamente perdidas. Os quóruns frouxos e a transferência com dica mantêm o sistema gravável mesmo quando algumas réplicas estão inacessíveis, estacionando gravações em um substituto temporário até que o nó legítimo retorne. A anti-entropia com árvores de Merkle permite que as réplicas encontrem e reparem suas diferenças de forma eficiente. A associação baseada em gossip permite que os nós conheçam uns aos outros e detectem falhas sem um coordenador central – o design é deliberadamente simétrico e descentralizado, de modo que “todo nó no Dynamo deve ter o mesmo conjunto de responsabilidades que seus pares”, o que significa que não há um nó especial cuja morte seja catastrófica.³ Cada uma dessas escolhas serve ao mesmo senhor: permanecer disponível quando as coisas falham.

A Amazon nunca liberou o código do Dynamo, mas o artigo fez o trabalho – tornou-se um dos artigos de sistemas mais influentes de sua década, a semente intelectual do movimento NoSQL.³ Apache Cassandra, Riak e Project Voldemort traçam todos os seus designs sem líder e eventualmente consistentes diretamente até ele.³ E o nome perdurou comercialmente no Amazon DynamoDB, que é construído sobre os princípios do Dynamo embora tenha feito escolhas de engenharia diferentes nos bastidores (replicação com líder único em vez do modelo puramente sem líder do Dynamo).³ A lição da influência do Dynamo vale a pena ser notada por si só: o fosso competitivo da Amazon não era o código, era a clareza. Ao explicar precisamente de quais garantias abriram mão e por quê, eles ensinaram a uma geração de engenheiros como raciocinar sobre o trade-off.

AWS, orientação a serviços e “você constrói, você opera”

O Dynamo é um sistema de armazenamento; a contribuição mais profunda de Vogels é arquitetural e cultural. A plataforma da Amazon é construída como uma malha de serviços independentes que só conversam por APIs – sem bancos de dados compartilhados alcançados por trás da cortina, sem acoplamento oculto.⁵ A disciplina importa para a falha: quando os serviços são desacoplados por trás de interfaces rígidas, um que falha degrada o recurso específico que alimenta em vez de corromper os dados ou travar as threads de tudo que o tocou. A orientação a serviços é contenção do raio de impacto expressa como arquitetura. É também o que tornou a AWS possível – uma vez que seus sistemas internos são serviços limpos e endereçáveis por API, expô-los ao mundo exterior como produtos é um próximo passo natural.

A metade cultural é a frase pela qual Vogels é citado com a mesma frequência que “tudo falha o tempo todo”: “você constrói, você opera” (you build it, you run it). Em uma conversa de 2006 com Jim Gray, ele descreveu o modelo da Amazon em que cada serviço pertence de ponta a ponta à equipe que o cria: “Cada serviço tem uma equipe associada a ele, e essa equipe é completamente responsável pelo serviço – desde delimitar a funcionalidade até arquitetá-lo, construí-lo e operá-lo”.⁵ E a justificativa era explicitamente sobre qualidade por meio da propriedade: “Você constrói, você opera. Isso coloca os desenvolvedores em contato com a operação cotidiana de seu software. Também os coloca em contato cotidiano com o cliente”.⁵ Não há um muro por cima do qual jogar o código; o engenheiro que escreveu o serviço carrega o plantão por ele. O efeito é um laço de feedback apertado – a pessoa mais capaz de consertar uma fragilidade é a pessoa que sente sua dor às 3 da manhã, e a pessoa que projetou o recurso ouve a reclamação do cliente diretamente. A propriedade não é aqui um slogan de RH; é um mecanismo de confiabilidade. Uma equipe que opera o que constrói projeta para a falha porque a falha acorda ela.

Evangelizar a nuvem: raio de impacto, células e sistemas bem arquitetados

O quarto corpo de trabalho de Vogels é menos um artefato único do que um papel sustentado: por duas décadas ele tem sido o arquiteto-evangelista que codificou como construir sobre a nuvem, não apenas como construir a nuvem.¹⁶ Os temas recorrentes são o princípio aplicado a um escopo cada vez maior. Minimizar o raio de impacto: particionar os sistemas em células independentes para que uma falha, uma implantação ruim ou uma requisição envenenada fique contida a uma fatia de clientes em vez de a todos eles. Desacoplar de forma agressiva: preferir serviços assíncronos e frouxamente acoplados com contratos explícitos a cadeias síncronas apertadas onde uma dependência lenta trava todo o caminho de chamada. Automatizar a recuperação, não documentá-la: um manual de operação que precisa de um humano não se executa quando o humano está dormindo. Abraçar a falha como uma entrada de teste, injetando deliberadamente falhas para provar que o sistema as sobrevive em vez de torcer para que sobreviva. Cada um desses é “tudo falha o tempo todo” transformado em uma prática operacional – a mensagem consistente, repetida ao longo de palestras, textos e uma segunda conversa na ACM anos depois, de que a resiliência é uma propriedade que você projeta desde a primeira linha, não uma camada que você adiciona depois que a demonstração funciona.⁶

O método

Leia ao longo do Dynamo, da consistência eventual, da orientação a serviços e de “você constrói, você opera”, e os mesmos compromissos voltam. O método de Vogels é menos um slogan do que um conjunto de hábitos permanentes.

Projete primeiro para o caso de falha. Em escala, a falha é o estado estacionário, não a exceção, então a pergunta nunca é “isso funciona”, mas “o que acontece quando cada peça disto morre”.⁶ A lição se transfere muito além da escala da Amazon: não escreva o caminho feliz e remende o tratamento de erros – enumere primeiro os modos de falha e deixe o caminho que funciona decorrer de um sistema que já os sobrevive. É a barreira da evidência aplicada à confiabilidade – “funciona na demonstração” não é prova; “permanece disponível quando eu mato um nó no meio de uma requisição” é o mesmo padrão de autorrecuperação que Radia Perlman embutiu em redes que reconvergem sem um humano no laço.

Escolha sua consistência, não a herde. O movimento mais profundo no Dynamo é recusar o padrão de que toda leitura precisa enxergar toda gravação anterior. Vogels transforma a consistência em um botão que você ajusta por carga de trabalho – forte onde a correção exige, eventual onde a disponibilidade importa mais – e é preciso sobre qual garantia um sistema de fato fornece.⁴⁷ A disciplina é saber exatamente sobre o que sua afirmação de consistência se apoia e nunca pagar por uma garantia que uma carga de trabalho não precisa. É a mesma precisão sobre correção que Leslie Lamport trouxe ao tempo distribuído: não presuma a propriedade, defina-a com exatidão e saiba quando ela vale.

Desacople para conter o raio de impacto. Serviços independentes por trás de APIs rígidas significam que uma falha fica presa onde acontece em vez de cascatear.⁵ O hábito permanente é traçar as fronteiras de modo que o pior caso seja um recurso degradado, nunca um sistema derrubado – perguntar de cada dependência “quando isto falha, qual é o tamanho do buraco?” e fazer o buraco pequeno. É a forma arquitetural do produto mínimo digno: a fronteira mais limpa é aquela que faz exatamente o seu trabalho e falha sozinha.

Faça com que quem constrói seja dono da operação. “Você constrói, você opera” coloca as pessoas que projetam um serviço no plantão por ele, fechando o laço entre uma fragilidade e a pessoa capaz de consertá-la.⁵ A lição é que a dor operacional é o sinal de qualidade mais honesto que existe – uma equipe isolada da produção vai subinvestir em resiliência, porque o custo da fragilidade recai sobre outra pessoa. A propriedade é um mecanismo de confiabilidade, que é a qualidade é a única variável transformada em um organograma: a única maneira de garantir a qualidade é fazer quem constrói sentir a consequência de sua ausência.

Explique o trade-off às claras. A influência do Dynamo não veio de seu código – que nunca foi liberado – mas de um artigo que declarou com franqueza de quais garantias se abriu mão e por quê.²³ O hábito é tornar o raciocínio legível: nomear o trade-off, justificar o lado que você escolheu e ensinar o próximo engenheiro a raciocinar sobre ele em vez de copiar o resultado por imitação cega. A clareza sobre o porquê é o que permite que um design sobreviva ao seu autor – a mesma disciplina explicativa que tornou os artigos de Perlman e Lamport ensináveis décadas depois.

Cadeia de influência

Quem o moldou

Ken Birman e a tradição de sistemas distribuídos confiáveis de Cornell. A década de Vogels em Cornell, dentro do grupo de Birman e da linhagem Isis/comunicação de grupo confiável, é a fonte de sua premissa fundadora.¹ A pergunta central dessa tradição – como um grupo de máquinas permanece correto e disponível enquanto seus membros falham e se recuperam – é precisamente a pergunta que “tudo falha o tempo todo” responde. Ele não cunhou um slogan; reformulou o primeiro princípio de sua área para uma audiência planetária. (Influência formativa)

Andrew Tanenbaum e a academia de sistemas distribuídos. Seu doutorado na Vrije Universiteit foi orientado em parte por Tanenbaum, um dos professores fundacionais da área em sistemas operacionais e distribuídos.¹ O alicerce aparece: o Dynamo se lê como uma síntese funcional do cânone dos sistemas distribuídos – hashing consistente, relógios vetoriais, quóruns, gossip – montada por alguém que conhecia a literatura de cor. (Influência formativa)

Eric Brewer e o trade-off CAP. O argumento de Vogels a favor da consistência eventual se apoia explicitamente na observação CAP de que um sistema tolerante a partições precisa negociar consistência contra disponibilidade.⁴⁷ Brewer enquadrou a impossibilidade; Vogels operacionalizou a escolha na escala da Amazon e fez de “escolha disponibilidade e convirja” um padrão respeitável. (Influência direta)

Quem ele moldou

Todo o movimento NoSQL. O artigo do Dynamo é o ancestral direto de Cassandra, Riak e Voldemort, e o homônimo do DynamoDB – o padrão de design sem líder e eventualmente consistente se propagou de um artigo de 2007 para a camada de dados de uma geração de sistemas.³

A arquitetura cloud-native e a cultura DevOps. “Você constrói, você opera” tornou-se uma das ideias fundadoras do DevOps moderno – a propriedade de serviço completa, os desenvolvedores de plantão e a dissolução do muro entre dev e ops remontam diretamente ao modelo que Vogels descreveu em 2006.⁵

Uma geração de arquitetos de nuvem. Por meio dos princípios de design da AWS e de sua evangelização sustentada, “projetar para a falha”, “minimizar o raio de impacto” e “desacoplar via serviços” se tornaram o vocabulário padrão que os engenheiros usam para raciocinar sobre construir sistemas confiáveis na nuvem.⁶

O fio condutor

Vogels é a pedra angular de escala operacional desta série – a figura que pegou a teoria de sistemas distribuídos e a rodou em um planeta inteiro de máquinas. Leslie Lamport deu aos sistemas distribuídos seus alicerces: como definir tempo, ordenação e consenso com precisão, e como manter um sistema correto quando os participantes falham ou se comportam de forma arbitrária. Vogels é como esses alicerces se parecem quando precisam atender a um carrinho de compras de Black Friday – as mesmas perguntas de consistência e falha, respondidas não em um quadro branco, mas sob carga real, com receita real apostada em permanecer disponível.⁴ E Radia Perlman construiu redes que tratam o caso de falha como o centro do design, curando-se sozinhas sem um humano no laço; Vogels construiu serviços sobre exatamente esse instinto, uma camada acima na pilha – replicar, desacoplar, conter o raio de impacto e deixar o sistema convergir por conta própria. Onde Lamport diz defina a correção e prove que ela sobrevive à falha e Perlman diz construa para que se cure sozinho, Vogels diz: tudo falha o tempo todo, então pare de tentar evitar – projete para que o sistema permaneça disponível diretamente através da falha, e deixe quem o constrói e o opera sentir cada rachadura. (Ponte da série)

O que eu tiro disto

A lição que guardo de Vogels é tratar a falha como o caso normal, não a exceção. Meu instinto, como o da maioria de quem constrói, é escrever o caminho em que a chamada tem sucesso, a dependência responde, o disco está lá – e então parafusar um try/catch depois que funciona. “Tudo falha o tempo todo” é a repreensão: em qualquer escala real, a falha não é um evento raro que acontece ao meu sistema, é uma condição constante na qual meu sistema vive. Então, quando construo algo agora – um job de sincronização, um cliente de API, um consumidor de fila – tento partir de “o que morre, e o resto continua atendendo quando isso acontece?” em vez de chegar lá por último. A versão honesta de “funciona” não é a demonstração no verde; é matar uma dependência no meio de uma requisição e ver o sistema se degradar com elegância em vez de tombar. Um sistema que só sobrevive ao caminho feliz é um sistema que eu não terminei de projetar.

A segunda lição é que disponibilidade e consistência são um trade-off que eu tenho que fazer de propósito. É tentador querer ambas – toda leitura enxerga toda gravação, e o sistema nunca diz não – e, para uma única máquina, você pode ter as duas. No momento em que replico qualquer coisa, esse conforto acabou, e a disciplina de Vogels é escolher o lado deliberadamente para cada carga de trabalho em vez de recorrer por padrão à garantia mais forte em todos os lugares por hábito. A maior parte do que construo não precisa que uma leitura reflita instantaneamente a gravação mais recente; precisa nunca recusar o cliente. A consistência eventual reformulou isso para mim de um compromisso assustador em uma ferramenta precisa: nomear exatamente quão desatualizado um leitor pode tolerar estar, comprar disponibilidade com essa folga e parar de pagar por uma garantia que o recurso nunca precisou. A habilidade não é sempre buscar a promessa mais forte – é saber qual promessa o trabalho de fato requer.

FAQ

O que significa “tudo falha o tempo todo”?

É a compressão que Werner Vogels faz de uma lição duramente conquistada sobre escala: quando você opera máquinas suficientes, a falha de componentes deixa de ser uma exceção rara e se torna uma condição constante e estatisticamente garantida.⁶ Um modo de falha raro o bastante para ser ignorado em um único servidor ocorre em algum ponto de uma frota grande constantemente. A consequência prática é a inversão da engenharia normal: em vez de tentar evitar a falha, você presume que cada disco, servidor, enlace e dependência vai falhar, e projeta sistemas que permanecem disponíveis através da falha – via redundância, desacoplamento e raio de impacto contido – de modo que qualquer falha isolada seja sobrevivível e, idealmente, invisível.¹⁶

O que é o artigo do Dynamo?

“Dynamo: Amazon’s Highly Available Key-value Store” é um artigo de SOSP de 2007, coescrito por Vogels, que descreve o sistema de armazenamento que a Amazon construiu para manter serviços como o carrinho de compras graváveis mesmo durante falhas e partições de rede.²³ Ele combinou hashing consistente para o particionamento, relógios vetoriais para rastrear gravações concorrentes, quóruns frouxos e transferência com dica para permanecer disponível sob falha, anti-entropia com árvores de Merkle para reparo e gossip para associação descentralizada – tudo a serviço de sempre aceitar uma gravação e reconciliar depois. A Amazon nunca liberou o código, mas o artigo se tornou fundacional para o movimento NoSQL, influenciando diretamente Cassandra, Riak, Voldemort e Amazon DynamoDB.³

O que é consistência eventual?

A consistência eventual é um modelo de consistência relaxado que Vogels defendeu e definiu em seu ensaio “Eventually Consistent”: “se nenhuma nova atualização for feita no objeto, eventualmente todos os acessos retornarão o último valor atualizado”.⁴ Em um sistema replicado, uma gravação pode chegar a algumas réplicas antes de outras, então, por uma janela breve, réplicas diferentes podem retornar respostas diferentes – mas nenhuma jamais recusa uma requisição. O sistema permanece disponível e converge em segundo plano em vez de bloquear até que cada réplica concorde. É o lado da disponibilidade do trade-off CAP: quando a rede se particiona, um sistema pode ser consistente (recusar-se a responder até que todos concordem) ou disponível (responder com o que tem e reconciliar depois), e a consistência eventual escolhe disponível.⁴⁷

O que significa “você constrói, você opera”?

“Você constrói, você opera” é a descrição de Vogels, de uma conversa na ACM Queue de 2006, do modelo da Amazon de propriedade de serviço completa: a equipe que constrói um serviço é “completamente responsável pelo serviço – desde delimitar a funcionalidade até arquitetá-lo, construí-lo e operá-lo”.⁵ Não há muro entre desenvolvimento e operações – os engenheiros que escreveram o código carregam o plantão por ele. Vogels argumentou que isso “coloca os desenvolvedores em contato com a operação cotidiana de seu software” e “em contato cotidiano com o cliente”, e que o laço de feedback resultante é o que impulsiona a qualidade.⁵ A ideia se tornou um dos princípios fundadores da cultura DevOps moderna.

Fontes