Imagine que você precisa implementar uma solução como o YouTube. Seus requisitos parecem simples, exceto pela escala!
Para renderizar uma página de vídeo, você precisaria:
- Recuperar título, descrição, duração, e outras informações meta associadas ao vídeo;
- Estabelecer o streaming do vídeo (de acordo com formatos suportados pela rede e pelo device do usuário)
- Recuperar e incrementar o número de visualizações para um vídeo
- Recuperar e permitir a adição de comentários.
Os dois primeiros requisitos fazem, essencialmente, leitura. Por isso, são mais fáceis de escalar (com caching interno, caching na borda, caching no cliente, etc). Os dois últimos, que precisam ler e modificar estado, devido a necessidade óbvia do YouTube de particionar servidores tanto para processamento quanto para dados (escala horizontal), representam um grande desafio.
Em sistemas distribuídos, o teorema CAP aponta que temos que optar entre manter consistência ou disponibilidade para os usuários. O YouTube, por ser suportado em diversos servidores (sistema distribuído), é “vítima” do teorema CAP.
Ao tentar manter um contador do número de visualizações para um vídeo, poderíamos considerar, arquiteturalmente:
- Manter um único servidor de aplicação processando requisições para recuperar e incrementar o número de visualizações. Obviamente, esse servidor seria “gargalo” e comprometeria a capacidade do YouTube de escalar.
- Permitir que todos os servidores de aplicação aceitassem requisições de consulta e incremento centralizando os dados em um servidor de dados. Nesse caso, o “gargalo” seria o servidor de dados.
- Manter mais de um servidor de dados suportando a contagem, fazendo com que, eventualmente, os dados sejam consolidados entre todos os servidores (consistência eventual). Nesse caso, os dados para o usuário não estariam acurados (principalmente em virais).
Das três soluções acima, apenas a terceira realmente tem potencial para escalar. Entretanto, ela tem um efeito colateral extremamente indesejado: o YouTube não teria condições de fornecer dados precisos para o usuário.
Essa é a razão que leva o YouTube a “mentir” deliberadamente para os usuários. No lugar de tentar apresentar dados precisos, o site apresenta um comportamento de crescimento consistente com a expectativa do usuário (cuidando, inclusive, para não repetir muitos números pares ou ímpares).
A mesma ideia se aplica aos comentários. Afinal, em escala global, não seria possível garantir que todos os comentários estivessem consistentemente consolidados (replicados) nos diversos servidores. Por isso, no lugar de tentar fazer com que um comentário “replique rápido”, o YouTube toma uma série de cuidados para garantir que o usuário que fez um comentário o veja no próximo request (sem se importar que o comentário esteja sendo visto pelos demais usuários).
[tweet]Em sistemas escaláveis, cedo ou tarde temos que abrir mão da consistência.[/tweet] Nesses casos, é mais importante ter estratégias para parecer consistente do que ser consistente. Você não precisa “contar a verdade” o tempo todo, apenas precisa parecer contar a verdade a ponto de convencer seu usuário.
Abaixo, um vídeo, já um pouco antigo, onde um engenheiro do YouTube fala mais sobre as estratégias de escalabilidade da empresa.
Eu tendo a concordar com você em quase tudo, menos nesse assunto. E posso estar errado e até acho que precisamos conversar um pouco mais sobre para quem sabe você me convencer disso, o que não seria tarefa fácil, mas estou aberto a isto 🙂
Não que eu não concorde integralmente com o artigo. Não concordo com a conclusão que leva todo mundo ter logo depois de lê-lo, entre outros materiais do tipo. E você já esteve e por vez está do outro lado, mostrando o mesmo que vou dizer aqui.
Concordamos que em certo nível de escala precisa de arquiteturas mais complexas, provavelmente usando microsserviços, NoSQL e quem sabe DDD (coloquei os 3 porque são os assuntos que eu costumo estar do outro lado do pensamento mais corrente, e vejo os 3 muito ligados sob certo ponto de vista, na forma como costumam ser usados, não que eles precisam estar ligados). Já vi você demonstrando ou defendendo como essas coisas não são necessárias em certos cenários, como há casos que você escala bem de forma simples. Até aí só concordância.
A discordância provavelmente começa no ponto de inflexão. E já adianto que cada caso é um caso, vou dar números anedóticos só pra mostrar que a distância entre o meu ponto e o seu ou de outras pessoas que falam muito sobre o assunto.
Se você é um dos 5 sites mais acessados do mundo eu tenho quase certeza que tudo isso é válido. Eu não tenho 100% de certeza, mas aceito que seja, provavelmente é mesmo. Não tenho como argumentar com credibilidade.
Eu poderia dizer o mesmo para os 50 sites mais acessados do mundo. Se não existisse o Stack Overlow que não faz nada dessas coisa,s faz tudo simples, escala bem sem abrir mão de coisa alguma importante (eu acho que experiência do usuário melhoraria com algumas features que pesam mais porém sem abrir mão da consistência, mas isso não importa aqui). Eles fazem tudo mais barato justamente porque é simples, e alguém costuma dizer muito que complexidade é custo.
Note que eles eles fazem vários deploys por dia e tudo funciona estável e não acontece os problemas que as pessoas falam que acontece se você não usar arquiteturas complexas. Tudo isso “quase” sem teste 😀 e sem usar quase tudo que as pessoas falam que se você não usar seu software causará desastre maior que Chrnobyl. E poderiam fazer tudo em um único servidor se quisessem (provavelmente com gargalos em picos e problemas de confiabilidade).
Não vou me pegar a este número, mas fico pensando, será que se sair dos 500 sites mais acessados do mundo ainda existe um que realmente só vai funcionar bem se usar essas arquiteturas complexas que não podem nem manter consistência?
Deixa esse número pra lá. Vamos valor que se você não for uns dos 5000 maiores sites do mundo você não precisa de tudo isso. Pode ter alguma exceção, mas não é a regra.
Mas não vou perder meu tempo debatento esse tamanho. Vou questionar mesmo se você não for um dos 50 mil maiores sites Quase ninguém trabalha em um site desses.
Mesmo que faça sentido pra tanto site assim, ainda assim se fala do assunto mais do que devia porque ainda não será muito mais que 0,1% das soluções de TI criadas.
E aceito qualquer padrão de uso mais corporativo que se assemelhe ao acesso de um desses sites.
A impressão que eu tenho que as pessoas estão preparando viagem à marte quando só querem ir até a próxima cidade.
Tem motivos variados para as pessoas adotarem isto. Um deles acho que as pessoas criam tanto pra resolver problemas causados pelos motivos já discutidos em “Somos amadores remunerados?” e tudo o que se discutiu dali. Outro grande motivo porque as pessoas precisam estar na moda. Sem descartar as que tem motivos reais para uso disto.
Enfim, soltei a bomba 😀
Não percebi onde discordamos. 🙂
Repare que eu falei sobre dois desafios insanos aqui: 1) manter um contador em um sistema distribuído e 2) replicar dados em serviços massivamente distribuídos de forma global.
Claro que esse é um cenário de exceção. “Você não é o YouTube” seria a minha resposta usual para qualquer pessoa que viesse falar comigo em adotar soluções semelhantes.
Posso estar enganado, mas eu acho que você vê microsserviços como solução pra muita coisa, embora não pra tudo. Eu vejo como solução para uma quantidade ínfima de coisas, a tal ponto que não vale o esforço de ficar falando nisso a não ser que tenha um caso real de uso. Ei sei que nunca trabalharei em um caso assim. EU sei que muita gente acha que tem um caso real de uso, mas sempre cai em tudo o que falei antes.
Eu vi uma palestra de um funcionário de um unicórnio brasileiro. Disse que precisam da solução complexa toda que foi apresentada por causa do tráfego volumoso que tinham. Apresentou os números, era 5% do tráfego do Stack Overflow.
Além do Monolith First acho que todos deveriam fazer o Optimization Second, depois pensar em arquitetura complexa, se não tiver nada mais que possa ser feito antes. Eu sei que você é contra a complexidade desnecessária, mas não sei se é tão contra quanto eu. Pra mim microsserviços só é solução se realmente todas as outras opções não funcionam (não estou nem dizendo que são piores), e eu acho que existem alguns poucos milhares de casos concretos entre os muitos milhões existentes que se encaixa nisto, e estou sendo condescendente nesse número. Se você vê um número semelhante talvez concordemos mesmo. Aí só não entendo porque está tão preocupado com isso. Quais as chances de alguém trabalhar em dois casos assim no Brasil? Já acho quase zero pra um caso. Nós concordamos se você disser que quase todos os casos que estão usando microsserviços provavelmente são equivocados.