Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. O episódio completo pode ser visto no canal.

Introdução

Hoje vamos falar sobre uma decisão da Amazon Prime de voltar de uma arquitetura de microservices para uma arquitetura monolítica relacionada a um sistema específico que eles que tinham.

Eles fizeram um post contando um pouco do que motivou essa decisão. Além de falar sobre esse texto em específico, também vamos falar sobre um outro texto do criador do Rails, David Heinemeier Hansson, o CTO da Basecamp, criticando bastante a decisão de se caminhar para uma arquitetura distribuída baseada em microservices.

A Decisão da Amazon Prime

O texto, intitulado "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%", discorre sobre a decisão de escalar verticalmente o serviço de monitoramento do Prime Video e reduzir 90% dos custos. Aqui estão algumas frases essenciais do texto para traçar uma timeline da decisão:

Intenção Inicial: "We never intended nor designed it to run at high scale." - De acordo com o texto, a equipe nunca teve a intenção e, consequentemente também não pensaram no design, para rodar em alta escala.

Custos de Infraestrutura: Os custos de infraestrutura para essa alta escala estavam muito altos.

Limite de Escalabilidade: Eles estavam conseguindo escalar apenas 5% da carga esperada.

O texto informa que o approach distribuído não estava trazendo os benefícios esperados para o caso de uso específico. Então, resolveram juntar tudo em um processo só para manter a transferência de dados em memória.

A ideia era fazer uma análise de defeitos dentro da transmissão do vídeo, e perceberam que mandar os frames do vídeo para o S3 e depois baixá-los para análise era pior do que fazer tudo em memória.

A Crítica do Criador do Rails

David Heinemeier Hansson, escreve um rápido post falando sobre a decisão da Amazon Prime. Em geral ele sempre usa um tom crítico quando o assunto é arquitetura distribuída e, neste texto, a coisa não foi diferente.

Ele se ancora na decisão da Amazon Prime para dizer que a realidade sobre arquiteturas distribuídas, mais uma vez, bate na porta. Ele cita que a loucura(na opinião dele) começou lá com o J2EE e sua ideia de beans remotos. Do mesmo jeito que aquela ideia caiu em desuso(diria que há controvérsias), ele entende que a ideia de usar uma arquitetura de microservices para a maioria dos cenários, deve cair também.

O problema foi gerado por conta da arquitetura de microservices mesmo ?

Para mim, a história contada no texto da Amazon é a história da vida real de um sistema que foi projetado para uma coisa, a coisa mudou bastante e aquela projeção inicial não sustentou o que precisava. Faz parte do jogo. A decisão de voltar para uma arquitetura monolítica foi baseada na necessidade de escalar de maneira eficiente e reduzir custos.

Aqui considero importante ressaltar que o problema de escala não foi gerado pela escolha da arquitetura distribuída e sim pelas decisões de implementação para determinados componentes dentro desta arquitetura. Acreditar que a simples escolha entre arquitetura distribuída e monolítica é o fator de decisão para a escala de um sistema, na minha visão, é um tanto quanto ingênuo.

Vamos falar mais ?

Se você gostou, deixa um comentário aqui. Tem um comentário construtivo? Deixa aqui também, com educação. Vamos trocar mais ideias :).

Conheça mais sobre a Jornada Dev + Eficiente

A Jornada Dev + Eficiente é um treinamento cujo objetivo é fazer com que você busque as melhores posições como Dev impulsionado pela sua profundidade técnica em Design e Arquitetura de Software.

Trabalhamos para que você tenha cada vez mais capacidade de entregar software em produção associando velocidade com alto padrão de qualidade.

Para saber mais, acesse em https://deveficiente.com