“Isaque, tu tá maluco, bicho? Que diabos tem a ver Paulo Freire com microsserviços e com a Amazon?”

Primeiramente, boa tarde, glr, afinal de contas, comecei a escrever esse texto no meu intervalo do almoço do dia 05/05/2023 depois de ler um monte de manchetes, títulos de blogs e postagens do twitter (hoje eu vi uma pá de gente falando sobre essa *****) e após uma reação inicial do tipo “Eita”. Já adianto que qualquer reação de espanto é infundada. Não há nada demais na escolha arquitetural feita pelo time da Amazon.

Pra quem não tá ligado, acontece que num post de 22 de março e que APENAS AGORA alcançou reverberação suficiente pra inflamar a bolha dev, um engenheiro de confiabilidade da própria amazon detalhou em um post intitulado “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%” como eles decidiram abandonar uma arquitetura de sistemas distribuídos baseada em microsserviços em favor de uma redução de custo em até 90% do custo originalmente alcançado. O post original é uma coleção de informações como motivações e escolhas feitas pela equipe, análises e conclusões que levaram a tomada de decisões e alguns diagramas arquiteturais.

Adiante falo um pouco melhor sobre isso mas, ao contrário do que uma inifinidade de textos secundários quer nos fazer crer, o artigo aponta apenas os perigos da ‘adoção precoce’ (early adoption) da arquitetura de microsserviços e com certeza indica que fazer isso também adotando uma abordagem ‘serverless’ com objetivo de reduzir custos também não foi a melhor das escolhas, porém tudo o que uma parte significativa da comunidade de desenvolvimento (leia-se ‘bolha que observo e sigo’) parece ter conseguido entender foi “Nem mesmo a Amazon conseguiu dar algum sentido ao uso de arquitetura de microsserviços“. Isso é um caso típico de falta de leitura, de contextos, ou em outras palavras: Falta de muito, mas muito Paulo Freire mesmo. Também li muitos não-brasileiros que na esteira da postagem original, expuseram suas opiniões e defesa da arquitetura monolítica enquanto teciam críticas carregadas de fortes razões para se esquecer o equívoco que é ‘arquitetura de microsserviços’, e dentre eles alguns defenderam em algum nível o retorno ao SOA e também lhes faltou aplicar em algum nível uma boa dose de contextualização… De verdade, esse é um problema que considero inerente a textos rápidos de opinião escritos como postagens de blog: Na maioria das vezes não há um contexto exposto e nem detalhes suficientes para se tirar uma conclusão mas a gente quer e precisa tirar uma conclusão a qualquer custo.

Pois bem! Vamos lembrar as palavras do saudoso educador: “A memorização mecânica da descrição do elo não se constitui em conhecimento do objeto. Por isso é que a leitura de um texto, tomado como pura descrição de um objeto é feita no sentido de memorizá-la, nem é real leitura, nem dela portanto resulta o conhecimento do objeto de que o texto fala.” Tomo liberdade e parafraseio essas palavras: “A leitura de uma postagem de blog como pura descrição de uma realidade feita no sentido de apoiar um ponto de vista carregado de pré-conceitos, nem é real leitura, nem dela portanto, resulta qualquer conclusão que mereça valor quanto àquilo sobre o que o texto fala”. Uma real leitura obrigatoriamente perpassa pelo entendimento dos fatores que circundam o autor, os fatores que levaram à ocorrência do evento descrito e claro, o contexto em que está inserido o próprio leitor. Assim quando lemos uma opinião, olhamos para quem a está expondo (você pode estar fazendo isso agora mesmo), vemos o objeto ou fato a que a opinião se refere e aplicamos ali também o nosso contexto. Constantemente nosso contexto influencia a leitura assim como o contexto do opinante influencia sua escrita/fala. Nós e ele somos vulneráveis a preconceitos e isso é meio que resultado da forma como nosso cérebro funciona por padrão escolhendo sempre o caminho de menor esforço possível. Buscamos opiniões para concordar ou discordar e pouco atentamos para o objeto que realmente está em discussão. Assim, quando alguém fala negativamente sobre algo, tendemos a rejeitar a fala por termos preconceito ou a rejeitar o objeto por aquela opinião ressoar em nós mesmos. Talvez essa seja a razão porque Paulo Freire seja tão odiado: o caminho da leitura que ele propõe e que explica muito o sucesso do método de alfabetização de adultos parece muito complicado para nós que já sabemos ler e decodificar letrinhas, embora nos falte chaves para decodificar o mundo.

Voltemos um pouco e vejamos um pouco de interpretação

No post original, o autor ressalta que já na versão inicial, o serviço [ de monitoramento de fluxos ou streams de vídeo] era composto na forma de componentes de sistemas distribuídos orquestrados por Step Functions. Para quem não está familiarizado com o nome, nada mais é do que um serviço que simplifica a orquestração de workflows ou fluxos de trabalho. Isto quer dizer que havia uma esteira de processamento e que havia dependência entre o passo seguinte e o passo anterior. No entanto há muitas coisas que não ficam claras ali no texto original. Há alguns desenhos de alto nível mas sinceramente bem parecidos com jibóias que engoliram elefantes. Se você tiver imaginação, vai conseguir extrair algo deles, se não, eles servem muito pouco para raciocinar e descobrir como tudo funcionaria e realmente poder dizer: entendi!

O serviço em si visava garantir uma qualidade consistente para os vídeos transmitidos e uma melhor experiência para os clientes. Nisso o primeiro gargalo financeiro: O serviço executava múltiplas transições de estado para cada segundo de fluxo de vídeo monitorado e a conta chegou mais alta em função disso: No nível gratuito das Step Functions, você pode realizar até 4000 transições de estado por mês, passando disso, do cliente é cobrado 25 centavos de dolar a cada 1000 transições de estado. Imagina que em uma stream de apenas um filme de 2 horas você tem 7200 segundos, já excedendo a quota gratuita mensal em 3200s só na primeira execução… Imagine streams concorrentes do mesmo filme para n usuários no Brasil… A conta não saiu mesmo barata. (Hummmm… eu posso estar equivocado no cálculo acima? Se estiver e alquém quiser me corrigir, tudo bem. É na antítese que se forma o conhecimento e se encontrarem um erro, é por que realmente leram).

Um segundo gargalo financeiro acontece em função da necessidade de trafegar os dados dos vídeos entre os componentes do serviço, resultado da tentativa de reduzir custos com operações de conversão de vídeo em tempo real porque escolheram utilizar um outro microsserviço responsável apenas por dividir os fluxos em imagens que seriam carregadas para um bucket S3 de onde microsserviços de detecção de erros/defeitos as obteriam e processariam, o que saiu a um custo mais elevado do que o esperado.

Então todo o problema de custos não foi causado pela escolha arquitetural APENAS. Há um conjunto de fatores que formam um contexto um tanto mais complexo que apenas ‘má decisão de um time de engenheiros’. Já havia pressão em torno do custo, pressão em torno do prazo, pressão em torno da expectativa da qualidade e porque não reconhecer, o tradicional deixa pra resolver o problema quando o problema aparecer. Tivessem mais tempo, teriam antecipado esses gargalos e talvez nem tivessem optado por já iniciar como sistemas distribuídos na forma de microsserviços utilizando componentes serverless, esse é o ponto.

Bom, talvez eu esteja vendo errado também e eles realmente tiveram tempo suficiente mas enfim, essa é a parte mais subjetiva e envolve outras coisas como, por exemplo, essa pode ter sido aquela chance de fazer aquele projeto que resulte num caso de uso de sucesso e possa ser aproveitado pela própria companhia para vender seus serviços, enfim, 2 possíveis casos de sucesso numa tacada só. Me parece que foi isso que aconteceu.

Monolito é melhor

É um equívoco escolher a ‘melhor abordagem’ sem ter insumos, sem saber como a coisa vai se comportar e sem tempo pra planejar, analisar e discutir as implicações de cada direcionamento tomado. Assim, pode ser que um monolito seja, sim, a melhor forma de começar um projeto para ‘captar’ a alma da coisa e depois, com mais insumos, você possa decidir por manter o monolito ou por criar um ecossistema de microsserviços. E mais: Monolito não é desculpa para desorganização. Da mesma forma que microsserviço não te dará a certeza de sucesso. Há um balanço nisso. Cada modelo arquitetural tem sua aplicabilidade e no fim, um microsserviço é também um ‘monolito’, só que menor, mais coeso e organizado. Ninguém deve esperar a chance de trabalhar com microsserviços para escrever código organizado. A organização do código fala muito sobre a qualidade do software.

– Ok, mas é uma má idéia você começar algo já utilizando arquitetura em sistemas distribuídos baseada em microsserviços?

Se você não tiver insumos o suficiente para planejar, é uma péssima ideia sim. Pode haver aquele caso em que você tem tudo o que precisa para tomar a decisão, como por exemplo, pessoas que dominam o contexto nas posições certas dentro do projeto, expertise inconteste na área de atuação da empresa, enfim… isso é raro, irmão, muito raro.

Deixo pra você a tarefa de avaliar o que faz mais sentido:

1 – Assumir que arquitetura de microsserviços é mais uma invenção do tipo do Bathroom Buddy que tinha tudo pra dar certo mas nunca funcionaria de verdade

2 – Admitir que no mundo real há uma infinidade de opções e contextos e nem sempre você vai escolher certo e que tá tudo bem, é assim mesmo e da próxima vez, você procurará obter insumos o suficientes para determinar e justificar sua escolha.

Não seria muito dizer que não devemos ler apressadamente e nem tirar conclusões antes de chegar ao fim de um texto, assim como sempre devemos evitar o ‘viés de confirmação‘.

É isso…

PS.: Se você leu até aqui, aproveita e dá uma olhada nesse post do gago que fez uma análise técnica bem apurada da situação toda entrando em detalhes e levando em conta o tal contexto e devo dizer que concordo com ele em muitas coisas ditas ali. Vale muito a leitura.