A Amazon Prime Video recentemente lançou um artigo⇗ que sacudiu o mundo da tecnologia, explicando como eles economizaram 90% em sua conta de serviços da web ao mudar de microsserviços serverless para uma arquitetura monolítica.

O artigo tem causado bastante alarde porque um dos pontos centrais da arquitetura serverless é a capacidade de dimensionar a infraestrutura com mais eficiência - o que, em teoria, deveria custar menos dinheiro.

Para discutir sobre o assunto polêmico, vamos explicar a justificativa da Amazon Prime Video para o retorno ao monólito e trazer as opiniões do canal do YouTube Fireship e de Lucas Boemeke, CEO/CTO da bohr.io.

Mas, antes, é importante estabelecer as diferenças básicas entre microsserviços e arquitetura monolítica.

Qual é a diferença entre a arquitetura monolítica e a arquitetura de microsserviços?

Em uma arquitetura monolítica, o aplicativo é construído como uma única unidade, onde todos os componentes são agrupados em um único sistema. Essa abordagem é mais simples de desenvolver, testar e implantar, pois tudo está em um só lugar. No entanto, pode ser difícil de escalar e manter à medida que o aplicativo cresce, já que cada mudança afeta todo o sistema.

Já a arquitetura de microsserviços divide o aplicativo em serviços independentes que se comunicam entre si por meio de APIs. Cada serviço é responsável por uma única funcionalidade específica do aplicativo e pode ser escalado, atualizado e implantado independentemente dos outros serviços. Essa abordagem é mais complexa, pois exige uma coordenação mais rigorosa entre os serviços, mas também é mais flexível, escalável e resiliente, permitindo que as equipes de desenvolvimento trabalhem em serviços separados e independentes uns dos outros.

Por que a Amazon Prime Video mudou de uma arquitetura de microsserviços distribuídos para um aplicativo monolítico?

Tudo começou assim: a Amazon Prime Video precisava de uma ferramenta para analisar o conteúdo de áudio ou problemas como congelamento de vídeo e corrupção de arquivos. Para implementar essa ferramenta, eles usam várias funções serverless chamadas Step Functions⇗ (que são basicamente a mesma coisa que as Lambdas) para lidar com diferentes responsabilidades.

Explicando o workflow:

Você tem um ponto de entrada inicial que inicia outro serviço para fazer uma conversão de arquivo, a qual converte um stream de áudio/vídeo em quadros que podem ser usados pelo detector. Daí você tem vários detectores usando aprendizado de máquina para analisar o vídeo e, finalmente, você precisa de outra função para agregar o resultado e armazená-los em um bucket.

Acontece que há um pouco de sobrecarga toda vez que você passa dados de um serviço para outro. É preciso serializar e desserializar dados e se comunicar por uma rede. Nesse caso, o serviço precisava ser executado várias vezes para cada segundo de um stream de vídeo. Por isso, eles rapidamente atingiram um gargalo com os limites de sua conta apenas tentando orquestrar o serviço (segundo a empresa, a maneira como usaram alguns componentes fez com que atingissem um limite rígido de dimensionamento em cerca de 5% da carga esperada).

Além disso, ao fazer o upload temporário de arquivos para o S3⇗ (Amazon Simple Storage Service), gastavam dinheiro apenas acessando esses arquivos nos buckets. Assim, eles perceberam que a arquitetura distribuída era a causa raiz desses gargalos, o que os levou a tomar uma decisão ousada de re-arquitetar a estrutura para um monólito.

Então, em vez de executar serviços distribuídos desacoplados, eles pegaram tudo e o fizeram rodar em um único container. Nele, todos os componentes são iguais, mas agora que são executados em um único servidor, eles só podem ser dimensionados verticalmente.

Detalhe: isso significa que, para fazer mais trabalho, eles precisarão tornar maior cada servidor - ao contrário da arquitetura de microsserviço, que pode ser dimensionada horizontalmente criando mais serviços para cada componente individual com base em suas necessidades de dimensionamento.

Embora admita que algumas decisões tomadas não são óbvias, a Amazon Prime Video alega que mover o serviço para um monólito reduziu o custo de infraestrutura em mais de 90%, além de aumentar as capacidades de dimensionamento. Hoje, a empresa se diz capaz de lidar com milhares de streams, com capacidade de escalar ainda mais o serviço.

A Amazon Prime Video não está sozinha nesse movimento. David Heinemeier Hansson (DHH), criador do Ruby on Rails e do Basecamp, tirou toda a sua empresa da nuvem depois de gastar mais de US$3 milhões em um ano e agora apenas executa seus próprios servidores.

Muitas startups de sucesso, como o Dropbox, também deixaram a nuvem quando chegaram a um determinado nível de crescimento de suas operações.

Ganha dinheiro por um lado e perde por outro

O vídeo Serverless was a big mistake... says Amazon, do canal Fireship, apresenta uma situação contraditória em que se encontra a Amazon: por um lado, ela vai economizar dinheiro, mas, por outro, vai perder uma grande fonte de receita. Hoje em dia há muitas plataformas que oferecem serviços serverless, como Vercel e Netlify (que, segundo o Fireship, estão apenas usando e revendendo serviços da AWS nos bastidores). Há quase toda uma indústria de startups que torna a AWS mais fácil de usar, incluindo projetos de código aberto como o Serverless Framework e o SST.

Contraponto: a arquitetura serverless é o ideal para um grande número de usos

O vídeo do canal Fireship afirma que a tecnologia serverless e os microsserviços são usados em seus projetos e que essas tecnologias representam uma virada de jogo absoluta para fazer as coisas rapidamente.

Então, para quem já estava concluindo que precisa juntar seus microsserviços em um monólito, o Fireship lembra da Netflix em 2088, quando era baseada na arquitetura monolítica e teve uma falha enorme, a qual a motivou a dividir sua arquitetura em centenas de microsserviços diferentes que pudessem ser dimensionados independentemente, com tolerância a falhas.

Mesmo que o processo tenha sido complexo e caro, pense que, se a Netflix ficar fora do ar por algumas horas, isso vai custar muito mais dinheiro e perda de assinaturas.

Outra questão é o tamanho das operações. O Fireship lembra que pequenas empresas raramente extrapolam o nível gratuito e, quando o fazem, isso representa dinheiro bem gasto, pois sabem que não vão implantar algum código ruim em um monólito que pode derrubar toda a operação.

Já Lucas Boemeke, CEO/CTO da bohr.io, afirma que, embora a mudança de uma arquitetura de microsserviços distribuídos para uma aplicação monolítica pareça ter alcançado maior escalabilidade e reduzido os custos para o Prime Video, a abordagem serverless ainda possui vantagens significativas que podem ser benéficas em outros casos de uso - ou mesmo dentro do caso da Amazon, se aplicada de maneira diferente.

Aqui estão as principais vantagens da arquitetura serverless elencadas por Boemeke:

📈 Escalabilidade independente

A arquitetura serverless é projetada para escalar cada componente do serviço de forma independente. Isso garante que cada componente só usa recursos quando necessário, o que reduz custos e melhora a eficiência.

💵 Custo-efetividade

A arquitetura serverless também pode ser econômica, pois você só paga pelo tempo de computação que consome. Problemas de custo, como mencionado no exemplo da Amazon Prime Video, podem ocorrer devido ao uso ineficiente de recursos, e não a um problema inerente ao modelo serverless.

⚡Flexibilidade de microsserviços

A arquitetura de microsserviços permite a entrega rápida, frequente e confiável de aplicações grandes e complexas. Isso permite às organizações evoluir suas stacks de tecnologia, sendo capazes de testar novas abordagens em um único serviço sem afetar todo o sistema.

🚀 Velocidade e produtividade

A arquitetura serverless permite que os desenvolvedores se concentrem no produto principal, em vez de gerenciar e operar servidores ou tempos de execução. Isso melhora a produtividade do desenvolvedor, levando a um tempo de lançamento mais rápido no mercado.

🤖 Alta disponibilidade automatizada

A arquitetura serverless oferece disponibilidade e tolerância a falhas embutidas. Não é necessário arquitetar para essas capacidades, pois os serviços que executam a aplicação as fornecem por padrão.

Conclusão

Segundo Lucas Boemeke, embora uma arquitetura monolítica possa fornecer simplicidade e velocidade para certos casos de uso específicos, ela também vem com seus próprios desafios, como falta de flexibilidade, potencial para ciclos de desenvolvimento mais lentos e dificuldade em escalar partes específicas do aplicativo.

Na arquitetura monolítica, cada aplicação é única e requer uma abordagem personalizada. Portanto, a decisão de adotar serverless ou monólito deve depender das necessidades específicas do projeto em questão.

É possível que os desafios enfrentados no caso da Amazon Prime Video pudessem ter sido superados com um design ou implementação diferente dentro da arquitetura serverless. Por isso, Boemeke diz que não descartaria a abordagem serverless com base neste caso, mas sim, a usaria como uma oportunidade para aprender e melhorar o design e a utilização de arquiteturas serverless em projetos futuros.

Ou seja, como sabiamente foi dito no vídeo do Fireship, quando se trata de arquitetura em nuvem, não há soluções, apenas trade-offs.