Amazon Prime Video abandona a arquitetura de microservices: O problema foi o microservice mesmo?

[@DevEficiente]

Para saber mais sobre a Jornada Dev Eficiente acesse deveficiente.com/

[@danielrangelsa]

É importante ressaltar que é APENAS do serviço de MONITORAMENTO da saúde dos arquivos de vídeo.. tudo aqui deixa a entender que é o serviço CORE de streaming de vídeo que foi modificado.

[@DevEficiente]

Opa, valeu pelo comentário. No vídeo eu Vito que é um serviço de análise de qualidade.

[@lucasmagalhaes5936]

Obrigado pelo conhecimento passado Alberto, assisto a todos os seus vídeos.

[@DevEficiente]

Oi Lucas, valeu demais! Fico feliz mesmo que goste!

[@lucasmagalhaes5936]

@@DevEficiente sempre que puder faça esses vídeos sem muito a parte técnica, gosto muito de ver no horário do almoço

[@lacerdaph23]

Se até a Amazon tá considerando a infra cara… hahahah.. coitado de nós

[@DevEficiente]

huahuahuahua. Se os donos da infra tão achando caro...

[@maolabs]

Muito bom vídeo Aberto. Show o prime vide tech compartilhar o caso deles com todos nós. E acho que não deixa margens para dúvidas a conclusão que está lá, explicita no texto: "Microsserviços e componentes serverless são ferramentas que funcionam em alta escala, mas a decisão de usá-las em vez de um monolito deve ser feita caso a caso". E é isso. Li o texto do David e me pareceu que ele milita contra os microsserviços, conseguindo concluir outra coisa que não aquela que está explicita no texto original da amazon. Enfim, a resposta para a pergunta "qual a melhor solução para o problema" continua e continuará sendo a velha máxima: depende.

[@DevEficiente]

Boaaaa! Acho que é isso aí.. Em um texto temos alguém explicando um processo de decisão, no outro temos um cara aproveitando a chance para evangelizar o que ele quer.

[@detinhorp]

Há de se observar também que muito das tecnologias / serviços para sistemas distribuídos focam em processar milhares/ milhões de pequenas mensagens e que, sendo pequenas (em tamanho e semântica) podem se dar ao luxo de sofrer às vezes variações de 10x em queda de performance e isso não ser um problema. Olhando no 99% é irrelevante. Talvez devido à natureza dos dados (frames de vídeo) serem mensagens maiores (em tamanho e semântica), tenham atingido limites das ferramentas / serviços. E aí juntar tudo faz sentido pois você troca alguns segundos de transmissão de dados por alguns nanossegundos de chamada de função. Em uma arquitetura microserviços "tradicional" demoramos mais pra sentir isso pois geralmente a diferença é "apenas" de Milissegundos pra nanossegundos.

[@DevEficiente]

Pode ser também!

[@maisumpai9551]

Acho que pensaram em escalar, mas aplicaram errado. Digo isso pois o produto em si foi feito pensando em bater e frente com um gigante, então escalabilidade devia estar em pauta ( achismos da minha cabeça)

[@DevEficiente]

Opa, lembra que foi só um serviço dentro da streaming deles, não a streaming inteira. Acho que escala bem sim :)

[@jacksonjk]

ótimo vídeo, muito bom para entender melhor a criação e gerenciamento de softwares, além de provar cada vez mais que não é uma ciência exata!

[@DevEficiente]

Opa Jackson, acho que é isso. A gente coleta variáveis para tentar tomar a melhor decisão, de vez em quando acertamos em cheio e de vez em quando erramos por muito hehe.

[@mynameisabcd05]

Acho que o ponto mais importante desse texto é validar novamente que Monólito também continua sendo uma opção. Renata já fala isso do Stack Overflow há anos mas vejo muita gente ainda achando que somente micro serviço é viável. Parabéns pela análise, o que não falta é engenheiro de obra pronta analisando esse texto. Duvido nada que daqui uns dias tem gente falando que micro serviço já era e agora só monólito serve haha

[@DevEficiente]

Opa, eu acho que nem tem o que falar. Sempre que alguém me diz que achou a solução perfeita para todos os casos de software, eu já fico desconfiado. Vamos moldando nossa opinião e refinando as heurísticas para tentar acertar cada vez mais mesmo.

[@DevEficiente]

@Tony Messias pontuou bem que no texto da amazon é citado que o movimento de legar a lógica para o monólito simplificou a orquestração de um fluxo que eles tinha. No vídeo, quando falo do texto de DHH, eu inclusivo cito que isso era um resultado até esperado. Valeu Tony!

[@CesinhaGames]

gostei

[@DevEficiente]

Legal demais que curtiu!

[@JK-qx6mg]

Minha leitura: não sabiam fazer e voltaram para monolito que é skill do time.

[@DevEficiente]

Oi JK, confesso que enxergo diferente. Acho que eles projetaram para um cenário, o cenário mudou e eles tentaram manter a mesma solução. Não deu certo.

[@gfantin88]

Eu li outra opinião tb, não sei onde, e acabei concordando... Não é que eles fizeram em microservices e não deu certo.... Eles fizeram em microservices pq era mais barato(infra) pra iniciar e não tinham ainda a previsão se daria certo..... E deu super certo, então eles revisaram o caminho crítico da arquitetura deles e readequaram a infra.... Não vi erro em momento algum em todo o processo, só evolução natural do software... E depois que vc tem dados para provar como seu app se comporta com a sua demanda, fica mais fácil evoluir para uma arquitetura mais eficiente...

[@DevEficiente]

Oi Gabriel, eu entendo aqui o ponto de vista. Mas confesso que falei só sobre o que eu li lá no texto, sem tentar ir muito longe na interpretação. A frase lá que me chama atenção é a que eles apontam que não projetaram aquilo para escalar. Não lembro de ter lido que foram por este caminho pq a infra era mais barata ou algo assim.

[@kaktus12020]

Acho que o problema foram dois: custo e má implementação. Perceberam que com o monolito teriam a mesma capacidade de atender a demanda, ou perto disso, e o custo muito inferior.

[@DevEficiente]

Oi stripe, pelo que li lá eles perceberam que com o design que tinham não iriam atender a demanda e que de fato iriam precisar pagar muito por isso. Aí acharam que juntar tudo era o melhor.

[@MrBlackWolfX]

Desconsiderando o rant do DHH, o problema da Amazon parece ter sido de complexidade. É muito comum que aplicações distribuídas se tornem mais complexas de manter por conta do overhead de problemas possíveis (latência, indisponibilidade, retentativas, tráfego). P.S: fecha um pouco dessas abas kkkkkk

[@DevEficiente]

Sem dúvida, tem que tomar bastante cuidado. Tenho uma relação complicada com as abas mesmo!

[@andrecarvalho721]

po, mas eles não colocaram o prime video inteiro num monolito, foi só uma pequena parte.

[@DevEficiente]

Sim :). Inclusive cito ali na descrição.

[@marcioengsoft]

Parabéns pelo vídeo Alberto. Uma coisa que sempre me chama a atenção é a quantidade de abas abertas. Você deve ter uma computador com 100 giga de ram e um processador bem parrudo. Se abrir este tanto de aba até a geladeira vai travar.

[@DevEficiente]

hauhuahua, eu preciso é diminuir então na hora de gravar! Não quero tirar sua atenção do vídeo hehe.

[@marcioengsoft]

@@DevEficiente Parabéns pelo seu trabalho desenvolvido aqui e nos cursos.

[@DevMultitask]

O que achei estranho no artigo é a alta redução nos custos, pq manter um monolito não é barato... e o esquema de memória sem o S3 poderia ser feito em microsserviço... mas o que fiquei curioso mesmo é por que eles abriram essa informação ? Fiquei com a impressão que o resultado foi mais negativo que positivo para a AWS.

[@DevEficiente]

É superficial ali. Tinha alguma coisa custo alto de chamada para o S3, pelo que entendi. Sobre abrir, eu confesso que enxergo diferente. Acho legal a transparência de abrir os eventuais equívocos.

[@rodolfoazevedo4082]

Eles explicam que o custo foi alto devido ao exagerado número de vezes que iam até o S3 recuperar os objetos.

[@vassoritzen]

As vezes o cara simplesmente tava num dia ruim pra escrever. Afinal... humanos né.

[@DevEficiente]

Vixe, admito que nem pensei nisso hehe

[@AllefMizael]

Mas na sua opinião, qual fator os levou a não tentar "salvar" os microsserviços? O custo de refatorar pode ter sido mais alto do que implementar um monólito?

[@DevEficiente]

Pelo que entendi(e aqui é preciso levar em consideração que eu não manjo nada de codar para streaming e tal), para manter a arquitetura distribuida eles teriam que de fato repensar o design. A ideia de upar para o S3 e outro serviço fazer download, usando o S3 como banco mesmo, não pareceu que atendia os requisitos dele. Juntando tudo em módulo só, me parece que eles só criaram outra implementação para essa interface de banco de dados... em vez de ser s3, agora virou a memória mesmo e pronto.

[@rodolfoazevedo4082]

Eu li o artigo, e pelo que entendi o problema foram dois: custos e capacidade de scaling. Não se falou em performance em momento algum, apesar de terem ganho em relação ao trocar do S3 para armazenamento em memória de certos objetos(aqui eles não falam em ganho de performance, é algo que eu que acho mesmo). Repetindo, a palavra performance nem aparece no artigo(e não estou discordando do video nem falando que você falou que o problema era performance, estou só trazendo o que entendi do que li).

[@DevEficiente]

Oi Rodolfo, obrigado pelo comentário! Considero que escalar é buscar atender um requisito de performance para um volume maior dentro de um determinado intervalo de tempo. Por isso que, na minha interpretação, as palavras escalabilidade e performance sempre andam juntas.

[@matheustorres8737]

Boa Alberto! A conclusão que eu tirei dessa discussão é que em briga de tecnologia/framework, a resposta cabalística pra todas as perguntas continua sendo a mesma: Depende! O caso de uso do prime video mostra que num cenário em que classicamente espera-se trabalhar com microserviços fez mais sentido para o time adotar um monolito, nao porquê uma tecnologia se mostrou insuficiente, mas devido as condições materiais que eles se colocaram. Um outro ponto que eu não cheguei a ver nessa discussão foram as questões interpessoais dentro do projeto, se eles estão trabalhando com um monolito eu assumo que o projeto não envolva muitos times ou que a pipeline deles não tenha a colaboração de muitas pessoas simultaneamente. Eu trabalho num projeto que poderia muito bem ser um monolito, mas são tantos times envolvidos e evoluindo suas peças no seu próprio ritmo que seria insustentável trabalhar com monolitos, mesmo que financeiramente fosse mais viável. Enfim, tudo depende...

[@DevEficiente]

Pelo que entendi Matheus, era uma ferramenta bem específica dentro da Prime Video.

[@LoboJuniorBr]

O cara faz microservices, onde um roda um stream e outro baixa o stream para rodar algoritmo de qualidades etc etc.... Realmente, nesse cenário foi uma puta decisao infeliz o que nao significa que "microservices " est\ao fadados ao fracasso... sistemas ruins e decisoes ruins podem ser feitas usando qualquer arquitetura 😛

[@DevEficiente]

Concordo demais!

[@thiago258wii]

só alguns pontos tambem. Vejo muita gente que nao leu, achando que a prime video voltou totalmente para monolito, aquele bem old schol, com cadastro de usuario , modulo de "codex" e "streaming" do video no mesmo monolito (e mais uma cacetada de funcionalidade que o prime precisa). Nao foi isso, eram tres microservicos, que resolveram juntar em 1 , e chamaram de "monolito", e como voce bem explicou, pelo jeito nem estudaram de cara se seria melhor criar essas funcionalidades, separadas ou no mesmo serviço. Fora que o "mundo" de streaming nao é entendido por 99,99999% dos devs, algo extremamente nichado. Pra quem entende, percebe o quao ruim era a solucao original da prime video.

[@DevEficiente]

Opa Thiago, não tenho nada a acrescentar, excelente resumo. Estou nos 99,99999% hauha.

[@felipelopes3171]

Oi Alberto, video muito bom, como sempre. Minha análise é a seguinte: se formos analisar o texto do ponto de vista técnico o que você falou está corretíssimo. Não temos informações suficientes pra dizer se o problema era mesmo microsserviço. Porém, nesse caso acho que uma análise técnica seria muito limitada nesse caso, e também devemos entender o contexto "social", digamos assim. As tecnologias de virtualização que proporcionaram arquitetura de microsserviço realmente tem potencial. É só ver o quanto um container inicializa mais rápido que uma VM. Porém, pra isso funcionar tem um tanto de coisa que vem junto, como redundância em diferentes DBs, transações distribuídas, robustez na observabilidade pra fazer autoscaling, etc. Isso é completamente normal, e na minha opinião vale a pena em vez de usar mainframe. Porém, basta só alguns meses na indústria pra entender que isso é extremamente mal feito e a razão que os consultores usam é pq big tech usa, e a própria Amazon admitindo que eles nao conseguiram fazer funcionar é um golpe forte pra eles, e acho que podemos esperar uma mudança de direção brusca na AWS, provavelmente precipitada pela crise. Enfim, eu acho que pra quem tava fazendo tudo direito não importa muito, simplesmente vao continuar melhorando os microsserviços. Agora, pra quem tava acostumado a vender tudo que a AWS lança, é um desastre sem precedentes.

[@DevEficiente]

Opa Felipe, obrigado pelo comentário. Essa thread ficou muito rica!!

[@LuizHenrique-sf1ji]

Sou novo , no mundo da programão quais livros vc recomenda para aprender engenharia de software que aborde esse tema de criar softwares para grandes escalas ?

[@DevEficiente]

Oi Luiz, aqui acho que depende do quão novo você se acha nesse mundo. Os livros que falam de sistemas distribuídos tocam em muitos assuntos relacionadas a larga escala, então eu recomendo. Por exemplo o Building Microservices acho muito bom.

[@NathanOnCodes]

ahhhhhhhh agora entendi, agora eu saquei. Por isso tinha tantos posts no linkedin, foi o amazon prime kk

[@DevEficiente]

hehehehe