Análise anual: 2023 foi um ponto de viragem para microsserviços

Talvez estejamos fazendo microsserviços de maneira errada?

Esta foi a tese principal de “Towards Modern Development of Cloud Applications” (PDF), um artigo de um grupo de Googlers (liderados pelo engenheiro de software do Google Michael Whittaker) que foi apresentado em junho no HOTOS ’23: Proceedings of the 19th Workshop on Tópicos importantes em sistemas operacionais.

O problema, como Whittaker et al apontaram, era que os microsserviços, em grande parte, não foram configurados corretamente, do ponto de vista arquitetônico. Eles combinam limites lógicos (como o código é escrito) com limites físicos (como o código é implantado). E é aqui que começam os problemas.

Em vez disso, os engenheiros do Google sugeriram outra abordagem. Crie os aplicativos como monólitos lógicos, mas entregue-os a tempos de execução automatizados, que tomam decisões sobre onde executar as cargas de trabalho, com base no que é necessário para os aplicativos e no que está disponível.

Com essa latência, eles conseguiram reduzir a latência dos sistemas em 15x e o custo em até 9x.

“Se as pessoas simplesmente começassem com código modular organizado, poderíamos tornar a arquitetura de implantação um detalhe de implementação”, comentou Kelsey Hightower sobre este trabalho em outubro.

O que deu errado com os microsserviços?

Alguns meses antes, a equipe de engenharia da Amazon Prime Video postou uma postagem no blog explicando que, pelo menos no caso do monitoramento de vídeo, uma arquitetura monolítica produziu desempenho superior do que uma abordagem baseada em microsserviços e sem servidor.

Na verdade, a Amazon economizou 90% em custos operacionais ao abandonar uma arquitetura de microsserviços.

Para uma geração de engenheiros e arquitetos criados com base na superioridade dos microsserviços, a afirmação é realmente chocante.

“Esta postagem é uma vergonha absoluta para a Amazon como empresa. Incapacidade total de construir alinhamento interno ou comunicações coordenadas”, escreveu o analistaDonnie Berkholzque recentemente abriu sua própria empresa de análise industrial, Platify.

“O que torna esta história única é que a Amazon foi o garoto-propaganda original das arquiteturas orientadas a serviços”, ponderou o criador do Ruby-on-Rails e cofundador do Basecamp, David Heinemeier Hansson. “Agora, os resultados reais de toda essa teoria finalmente chegaram e está claro que, na prática, os microsserviços representam talvez o maior canto de sereia para complicar desnecessariamente o seu sistema. E a ausência de servidor só piora a situação.”

Experiência da Amazon Video com microsserviços

O sistema original de entrega de vídeo da Amazon.

A tarefa dos engenheiros da Amazon era monitorar os milhares de streams de vídeo que o Prime entregava aos clientes. Originalmente, esse trabalho era feito por um conjunto de componentes distribuídos orquestrados pelo AWS Step Functions, um serviço de orquestração sem servidor, o serviço sem servidor AWS Lambda.

Em teoria, o uso de serverless permitiria à equipe dimensionar cada serviço de forma independente. Descobriu-se, no entanto, que pelo menos na forma como a equipe implementou os componentes, eles atingiram um limite rígido de escalonamento de apenas 5% da carga esperada. Os custos de ampliação para monitorar milhares de fluxos de vídeo também seriam excessivamente caros, devido à necessidade de enviar dados através de múltiplos componentes.

Inicialmente, a equipe tentou otimizar componentes individuais, mas isso não trouxe melhorias significativas. Assim, a equipe migrou todos os componentes para um único processo, hospedando-os no Amazon Elastic Compute Cloud (Amazon EC2) e no Amazon Elastic Container Service (Amazon ECS).

“Microsserviços e componentes sem servidor são ferramentas que funcionam em alta escala, mas a decisão de usá-los no monolito deve ser feita caso a caso”, concluiu a equipe da Amazon.

Desvantagens dos microsserviços

Indiscutivelmente, o termo “microsserviços” foi cunhado por Peter Rodgers em 2005, embora ele o tenha chamado de “microserviços web”. Ele deu um nome à ideia que muitos estavam pensando, especialmente na era dos serviços web e da arquitetura orientada a serviços (SOA) que ganhava atração na época.

“O principal motivador por trás dos ‘micro serviços web’ na época era dividir grandes projetos ‘monolíticos’ em vários componentes/processos independentes, tornando assim a base de código mais granular e gerenciável”, explicou a engenheira de software Amanda Bennett em uma postagem no blog.

O conceito se consolidou, especialmente com a computação nativa em nuvem, nas décadas seguintes, e só começou a receber críticas em alguns setores.

O engenheiro de software Alexander Kainz contribuiu para o TNS com uma excelente comparação entre monólitos e microsserviços.

Em seu artigo, os engenheiros do Google listam uma série de deficiências na abordagem de microsserviços, incluindo:

• Desempenho: serializar e enviar dados pela rede para serviços remotos prejudica o desempenho e, se o aplicativo se tornar complicado o suficiente, pode até causar gargalos.
• Compreensão: Bugs são notoriamente difíceis de rastrear em sistemas distribuídos, dadas as muitas interações entre microsserviços.
• Problemas de gestão: Considera-se uma vantagem que diferentes partes de uma aplicação possam ser atualizadas de acordo com suas próprias programações. Mas isso faz com que os desenvolvedores tenham que gerenciar um grande número de binários, cada um com seu próprio cronograma de lançamento. E boa sorte ao executar um teste ponta a ponta com um serviço executado localmente.
• APIs ficam frágeis: a chave para a interoperabilidade de microsserviços é que, uma vez estabelecido um microsserviço, as APIs não podem ser alteradas, deixe-as interromper qualquer outro microsserviço que dependa da API. Portanto, as APIs só podem ser estendidas com mais APIs, criando inchaço.

Um novo tipo de microsserviço?

Quando o The New Stack cobriu pela primeira vez as notícias da Amazon, muitos rapidamente nos apontaram que a arquitetura que o pessoal do vídeo usava também não era exatamente uma arquitetura monolítica.

“Esta definitivamente não é uma história de microsserviços para monolito”, observou Adrian Cockcroft, ex-vice-presidente de estratégia de arquitetura de nuvem da AWS, agora consultor do Nubank, em entrevista ao The New Stack. “É uma história de Step Functions para microsserviços. E acho que um dos problemas é a rotulagem errada.”

Ele ressaltou que em muitas aplicações, especialmente aplicações internas, o custo de desenvolvimento excede os custos de tempo de execução. Nesses casos, Step Functions faz muito sentido para economizar tempo de desenvolvimento, mas pode custar caro para cargas de trabalho pesadas.

“Se você sabe que eventualmente fará isso em alguma escala”, disse Cockcroft, “você pode construí-lo de forma diferente em primeiro lugar. Então a questão é: você sabe como fazer a coisa e em que escala vai executá-la?” — disse Cockcroft.

O artigo do Google aborda esse problema facilitando a vida do desenvolvedor e, ao mesmo tempo, permitindo que as apostas na infraestrutura de tempo de execução descubram a maneira mais econômica de executar esses aplicativos.

“Ao delegar todas as responsabilidades de execução ao tempo de execução, nossa solução é capaz de fornecer os mesmos benefícios que os microsserviços, mas com desempenho muito superior e custos reduzidos”, escreveram os pesquisadores do Google.

Os microsserviços só sobrevivem aceitando a ficção de que a comunicação em rede é gratuita. https://t.co/6XmXB0cLdq

-Paul Snively (@paul_snively) 28 de dezembro de 2023

Um ano de reconsideração

Este ano houve muitas reconsiderações arquitetônicas básicas, e os microsserviços não são o único ideal sendo questionado.

A computação em nuvem, por exemplo, também está sob escrutínio.

Em junho, a 37signals, que executa o Basecamp e o aplicativo de e-mail Hey, adquiriu uma frota de servidores Dell e deixou a nuvem, contrariando uma tradição de décadas de transferir operações para fora do local para maior eficiência vagamente definida.

“Este é o engano central do marketing na nuvem, que tudo será tão mais fácil que você dificilmente precisará de alguém para operá-lo”, explicou David Heinemeier Hansson em um post no blog. “Eu nunca vi isso. Nem da 37signals, nem de qualquer outra pessoa executando grandes aplicativos de Internet. A nuvem tem algumas vantagens, mas normalmente não envolve um número reduzido de funcionários de operações.”

Claro, DHH é um piloto de corrida, então, naturalmente, ele quer se aprofundar no metal puro. Mas há outros dispostos a apoiar esta aposta. No final deste ano, a Oxide Computers lançou os seus novos sistemas na esperança de servir outros com um sentimento semelhante: executar cargas de trabalho de computação em nuvem, mas de forma mais económica nos seus próprios centros de dados.

E esse sentimento parece ser pelo menos mais considerado agora que as contas da nuvem estão vencendo. FinOps se tornou algo notável em 2023, à medida que mais organizações recorreram a empresas como a KubeCost para controlar seus gastos com nuvem. E quantas pessoas ficaram surpresas com a notícia de que um cliente da DataDog recebeu uma conta de US$ 65 milhões para monitoramento na nuvem?

Indiscutivelmente, uma conta de observabilidade de US$ 65 milhões pode valer a pena para uma empresa que gera bilhões em receitas. Mas à medida que os arquitectos-chefes analisam mais atentamente as decisões de engenharia tomadas na última década, poderão decidir fazer alguns ajustes. E os microsserviços não serão uma exceção.

O correspondente nativo da nuvem da TNS, Scott M. Fulton III, contribuiu para este relatório.

A postagem Revisão do ano: 2023 foi um ponto de viragem para microsserviços apareceu pela primeira vez em The New Stack.