Hoje pela manhã me deparei com uma postagem que me chamou a atenção. Uma compartilhamento de um post que trazia um comentário sobre a Amazon Prime Video, contanto como eles estavam voltando de Microsserviços /Serverless para um Monolito.

Como se não bastasse, fui conferir o post e a headline diz:

Ampliação do serviço de monitoramento de áudio/vídeo Prime Video e redução de custos em 90%

A mudança de uma arquitetura de microsserviços distribuídos para um aplicativo monolítico ajudou a obter maior escala, resiliência e reduzir custos.

Hoje esse será o tema do nosso papo aqui.

O título impressiona, mas… vamos entender todo o contexto primeiro.

A Amazon no contexto de Microsserviços

A Amazon é famosa por também, em conjunto com Netflix, ser berço dos Microsserviços. Estamos falando das primeiras grandes empresas, com grandes cases, com grandes conquistas, que adotaram microsserviços e falaram do assunto para grandes audiências.

Não à toa Adrian Cockcroft (linkedin) que apresentou a solução da Netflix em 2014, ainda como arquiteto de soluções da empresa, virou VP da AWS em 2016, e hoje é Tech Advisor no Nubank.

Então é óbvio que esse tipo de notícia causaria muito alarde.

A origem das publicações

É hora de fazer as honras aos originais publishers que falaram sobre o assunto e estou pegando carona nessa história.

Hoje, 4 de MAIO, David Heinemeier Hansson, Criador de Ruby on Rails , co-proprietário e CTO da 37signals ( Basecamp & HEY ), autor de best-sellers ( REWORK , It Doesn’t Have to Be Crazy at Work , REMOTE ), publicou o post:

Even Amazon can’t make sense of serverless or microservices

The Prime Video team at Amazon has published a rather remarkable case study on their decision to dump their serverless, microservices architecture and replace it with a monolith instead. This move saved them a staggering 90%(!!) on operating costs, and simplified the system too. What a win!

https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580

Vale muito a pena a leitura.

Eu tomei conhecimento do assunto hoje, ao ler um post do Otavio Lemos (LinkedIn) sob a publicação do David.

Assim, com a Amazon publicando seu paper no dia 22 de Março, David publicando no dia 4 de Maio,

Cronologia montada, agora fica claro entender quem falou o que sobre o que e quando.

Leitores de Manchete só falam abobrinha!

A chamada inclusive da publicação da equipe do Prime Video é bem chamativa. Mas é necessário olhar o detalhe, o que há no texto.

Como sempre, manchetes levam a interpretações equivocadas, exatamente pela natureza de tentar chamar a atenção da audiência.

Essa tentativa se pauta em falar verdades, mas sempre com um tom sensacionalista demais.

PS: Eu estou me referindo aos leitores desse post aqui. Não leiam apenas o título, a explicação fará diferença no entendimento

Economia de 90% ou custo de 1000%?

Se você olhar para o resultado que eles obtiveram com a adoção do monolito nesse software, podemos concordar que reduziram em 90%.

Entretanto, se olharmos com cuidado para o perfil de aplicação de que estamos falando, entendemos que essa aplicação não deveria NUNCA, sob hipótese alguma, ser quebrada em vários microsserviços.

Nossa equipe de análise de qualidade de vídeo (VQA) no Prime Video já possuía uma ferramenta para inspeção de qualidade de áudio/vídeo,

…

Nosso serviço consiste em três componentes principais. O conversor de mídia converte fluxos de áudio/vídeo de entrada em quadros ou buffers de áudio descriptografados que são enviados aos detectores. 

Os detectores de defeitos executam algoritmos que analisam quadros e buffers de áudio em tempo real procurando defeitos (como congelamento de vídeo, corrupção de blocos ou problemas de sincronização de áudio/vídeo) e enviam notificações em tempo real sempre que um defeito é encontrado. 

Para obter mais informações sobre esse tópico, consulte nosso artigo Como o Prime Video usa o aprendizado de máquina para garantir a qualidade do vídeo . O terceiro componente fornece orquestração que controla o fluxo no serviço.

trechos traduzidos automaticamente pelo google.

Se estendemos que a análise de audio e vídeo, está sendo feita por functions, e, ao mesmo tempo os buffers são armazenados no S3, dá para perceber que é uma ideia no mínimo equivocada.

Desculpe o meu francês, mas lá em casa chamaríamos de ideia estúpida.

Essa aplicação tem perfil para ser um único microsserviço, mas não para ser fragmentada em vários microsserviços.

O Youtube Downloader

Um dos projetos que estudamos no Cloud Native .NET é o Youtube Downloader, um projeto que apresentei no youtube algumas vezes em 2017, mas foi denunciado como se ferisse direitos autorais ao facilitar a pirataria.

Uma vez que não tinha onde publicar, resolvi trazer para o Cloud Native .NET, em 2019 ainda.

Uma das facilidades do projeto é usar um FileSystem em memória, ou seja, um FileSystem em que o backend dele é a memória.

Isso permite trocar arquivos entre processos em uma velocidade absurda, e foi isso que fizemos nessa prova de conceito.

A ideia é usar o YouTube downloader como base para baixar vídeos, e depois temos as demandas de encodar o áudio separado como uma demonstração de um pipeline assíncrono.

Então para uma PoC dessas, houve essa preocupação, em usar a memória para trocar arquivos de forma eficiente e reaproveitar mecanismos que lidam com arquivos como o ffmpeg. Por que esses caras não se preocuparam com isso na hora de modelar esse serviço da Amazon Prime?

Minha opinião: Simplesmente foram no automático e sequer cogitaram outra arquitetura, microsserviços com serverless pareceu a solução óbvia.

Diante de dificuldades, revisitaram as decisões arquiteturais e testaram essa mudança.

Veredito?

O que quero trazer para o debate é que esse tipo de problema enfrentado por eles é natural, normal, cotidiano, para esse tipo de operação com esse tipo de mídia.

Trazendo para as aplicações de negócio, é algo tão corriqueiro quanto transações em bancos de dados. Ou paralelismo no acesso a um objeto de banco. Coisas avançadas, mas corriqueiras de projetos dessa natureza.

É possível, de antemão, bloquear a abordagem e sequer nem deixar a ideia de fragmentar um projeto desses em microsserviços ir para a frente.

A minha visão é que esse projeto custou 10 vezes mais por um erro de design e arquitetura, uma visão equivocada do uso de functions.

Tudo que já falamos há anos na comunidade.

Sei que falar isso agora, soa como engenheiro de obra pronta opinando sobre o que não participou. Mas o lastro de conteúdo, demonstra só uma coisa:

Erraram, e erraram de forma previsível.

E esse é o tipo de erro que mais me dói no coração, porque errar novo, errar diferente, errar fazendo algo que ninguém fez, é uma coisa. Mas errar de forma previsível, tem um peso diferente.

Microsserviços se abalam com isso?

Esse case, relatado pela Amazon, retrata um projeto que consome streams de video e áudio. Isso faz desse projeto um projeto exótico.

As regras que regem esse tipo de projeto não são as mesmas que regem aplicações puramente baseadas em dados, como bancos, e-commerces e aplicações de negócio que estamos habituados etc.

Esse case de volta para Monolitos é exótico.

Por se tratar de processamento de mídia, tem dificuldades diferentes, e uma adoção de microsserviços fragmentados demais fazem desse projeto um projeto muito diferente, com esse potencial para custar 10 vezes mais consumo de infra.

Microsserviços normais, consomem bem mais infra do que em suas versões monolíticas, entretanto não chega sequer perto desse fator 10X.

10x é demais!

É como sair de um custo de 10 mil reais mensais, para 100 mil.
Ou de 100 mil para 1 milhão.

É aceitável que Microsserviços custem até 5 vezes mais, do ponto de vista de infra, com potencial para reduzir esse fator se um projeto de escalabilidade, com mensageria ou streams for desenhado para esse cenário para melhorar a eficiência.

Isso faz microsserviços caberem em qualquer lugar, em qualquer projeto?

Definitivamente não.

Não é o fato do projeto em questão ser diferente, ser exótico, que automaticamente podemos ignorá-lo.

O hype ainda é um problema e um desafio para o mercado, que não entendeu ainda que os requisitos não funcionais dos microsserviços podem ser obtidos com outras arquiteturas, inclusive monolitos.

São os aspectos de negócio, como independência, que de fato constituem
os benefícios únicos dessa arquitetura.

São benefícios únicos de arquiteturas distribuídas, e toda vez que isolamos componentes para a independência, temos oportunidades mas também desafios, principalmente no que diz respeito à maturidade.

Arquiteturas distribuídas vão exigir outro nível de maturidade para conseguir lidar com a fragmentação, e essa maturidade vai desde o controle de versão, a implantação, passando por gestão de pipelines, observabilidade, na maioria absoluta das vezes, mensageria, e por aí vai.

Se você quer entender o tamanho da jornada, visite cloudnative.net.br e veja cada tecnologia, cada padrão, e eu desafio qualquer um a me provar que algum assunto, tecnologia ou pattern não é útil demais no dia-a-dia desse tipo de projeto.

Claro, a partir de certo nível de maturidade.

Encerro esse post com uma parte de um prefácio muito relevante.

Esse é o prefácio da segunda edição do livro Criando Microsserviços do Sam Newman, vale a leitura, inclusive e principalmente desses detalhes e dessas pistas que ele solta no livro.

Conclusão

Microsserviços são incríveis, mas nunca serão para todo mundo.

Microsserviços são vezes mais caros que monolitos, do ponto de vista de infraestrutura, equipe, tecnologia, governança, . Entretanto, quando você de fato entrega a tal independência, e consegue entregar features para seu cliente de forma mais rápida, aí esse custo adicional, se justifica.

É nesse momento que os microsserviços ficam mais baratos que monolitos.
Quando o entrave e a dificuldade de produzir novas releases ou realizar mudanças atrapalha o negócio. É nesse momento que uma adoção de um arquitetura complexa, distribuída, se justifica, só se ela entregar a tal:

INDEPENDÊNCIA