Por que a arquitetura baseada em filas de mensagens está perdendo popularidade hoje em dia?

xguru · 2024-06-21T11:03:01+09:00

Até o início dos anos 2010, falava-se muito sobre construir sistemas distribuídos baseados em MQ, mas hoje em dia quase não há textos sobre isso Tenho algumas teorias em mente e queria saber se é uma delas ou o que outras pessoas pensam O Redis cobre a maioria dos casos, inclusive cache, então operar um message broker separado deixou de valer a pena. O Kafka foi para uma escala realmente enorme. Os bancos de dados (em um sentido amplo) ficaram muito melhores em processamento em larga escala, então os processamentos “temporários” passaram a ser tratados no repositório principal Descobriu-se que arquiteturas baseadas em MQ não funcionam tão bem quanto se esperava, então agora usam-se outras abordagens Na verdade, a tecnologia de MQ entrou numa fase de maturidade, então já não é interessante o bastante para que as pessoas escrevam sobre ela. Mas continua sendo amplamente usada hnthrowaway_99 Muitas arquiteturas “populares” do fim dos anos 2000 até o início dos anos 2010 desapareceram depois que se percebeu que "você não é o Google. Sua empresa nunca vai ser o Google" Naquela época, havia um grande desejo de “construir do jeito que as grandes empresas bem-sucedidas construíam” Mas depois muita gente percebeu que 99% das empresas não precisam dessa complexidade À medida que o hardware e os bancos de dados padrão ficaram muito melhores, o número de empresas que precisam desses “truques de escalabilidade” vem diminuindo Meu critério para “há algum motivo para não fazer tudo isso com Postgres?” hoje é muito mais alto do que era 10 anos atrás Comentários nesta resposta Agora existem máquinas únicas muito maiores disponíveis a um custo razoável. Antes era preciso um pequeno cluster, mas agora um único sistema consegue suportar muitos tipos de carga Sinceramente, participei de vários projetos no Google para remover filas. Então talvez seja algo ainda maior do que “perdeu popularidade” biglain É uma visão cínica, mas acho que arquitetura MQ e os blogs sobre isso eram “Resume Driven Development”. Na prática, faziam coisas que caberiam num único notebook sem precisar escalar além de um monólito. Essas provavelmente eram as pessoas construindo desastres de microsserviços pesadelescos que custam dezenas de milhares de dólares por mês na AWS E agora “pessoas que colocam como prioridade de carreira acumular conquistas técnicas, em vez de resolver problemas reais de negócio de forma pragmática” estão fazendo hype sobre IA e escrevendo posts sobre isso tuckerconnelly Recentemente migrei de microsserviços para um monólito porque havia complexidade demais e muito código duplicado. Sem microsserviços, a necessidade de filas de mensagens diminui Para trabalho assíncrono, usei RabbitMQ em um projeto e parecia velho demais e excessivamente projetado E muitas ferramentas ao redor dele (Celery) não eram tão boas quanto ferramentas modernas construídas em torno do Redis (bullmq) Para processos em vários estágios no estilo DAG, prefiro, se possível, resolver tudo em uma tarefa grande ou dividir em poucas tarefas Se realmente precisar de DAG, existem ferramentas feitas especificamente para isso (Airflow). Mas ouvi dizer que é difícil depurar problemas, então é melhor evitar quando possível Acho a arquitetura multinó de Redis absurdamente complexa e problemática para escalar, então continuo com nó único. Mas fazer sharding manualmente funciona bem para mim Comentário de kypro sobre este texto Na minha experiência, monólitos não reduzem a complexidade; eles apenas a deslocam O maior problema do monólito é que, como as preocupações entre domínios não ficam clara e explicitamente separadas, com o tempo o codebase tende a virar um caos altamente interconectado de código espaguete Isso é ainda mais verdade em projetos grandes com muitos desenvolvedores, especialmente quando muitos deles não entendem toda a complexidade de domínio do código com o qual mexem Monólitos funcionam bem para projetos pequenos com poucos desenvolvedores, mas fora isso a maioria vai se arrepender em alguns anos de ter construído um monólito Também não concordo com a questão dos pontos de código duplicado. Se você usa a mesma linguagem e compartilha pacotes entre projetos, não vejo por que isso seria um grande problema De todo modo, nunca vivi esse tipo de problema trabalhando com microsserviços Também questiono se microsserviços são, em média, mais complexos que monólitos O que mais gosto em arquitetura de microsserviços é como é simples entender e contribuir para um microsserviço individual A arquitetura e o provisionamento dos microsserviços podem ser mais complexos, mas, do ponto de vista de quem trabalha neles, é muito mais simples do que um monólito democracy Acho que esta ideia está certa: "A tecnologia de MQ amadureceu a ponto de já não ser interessante o suficiente para render posts, mas continua sendo amplamente usada" Arquiteturas baseadas em mensageria são muito populares Comentários neste post casper14: concordo. Virou apenas mais uma ferramenta. Assim como ninguém mais escreve sobre como usar máquinas virtuais na nuvem bwhaley: essa é a resposta certa. Quase todo sistema distribuído executado em larga escala usa filas de mensagens em alguma capacidade ipsum2: parece plausível. Antigamente bombavam posts sobre reescrever Angular em React; hoje todo mundo simplesmente usa React ou escreve sobre reescrever React em Vue busterarm Vou dar uma resposta impopular Filas, streams e Pub/Sub são conceitos que a maioria dos engenheiros não entende bem Não sabem quando precisam disso, nem como usar direito, e usam para finalidades erradas Eu ainda trabalho com tudo isso (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) Trabalho numa empresa que contrata apenas os engenheiros mais “brilhantes”, vindos das 3 ou 4 melhores universidades da América do Norte, e para quase todos este é o primeiro emprego Nossos engenheiros já fizeram as seguintes loucuras: Enfileirar dezenas de milhares de mensagens de 100 MB no RabbitMQ em segundos e depois se perguntar por que tudo explodiu Enviar, de modo geral, mensagens bem grandes no RabbitMQ apesar de todos os avisos para não fazer isso Começar projetos novos em 2024 com a versão mais recente do RabbitMQ e tentar usar filas clássicas Criar filas quorum sem política de replicação, ou literalmente não fazer nada para garantir HA Expor clusters à internet com usuário administrativo guest/guest O arquiteto mais sênior da organização declarar um novo padrão de arquitetura, reunir a empresa toda e fazer uma demo Elogiar uma nova virtude/padrão em que você coloca uma mensagem na fila e depois cria um backchannel para um segundo consumidor processar sob demanda a mensagem que está na fila (e aí deixa de ser fila) E ninguém, exceto eu, disse “por que colocar na fila mensagens que precisam ser processadas em ordem?”, e esse “padrão” pegou! Usar Kafka como fila de mensagens padrão Enviar dados de um datacenter central para datacenters distribuídos globalmente, aplicar bloqueio global ao objeto e a todas as operações até que cada datacenter de destino confirme ter recebido o objeto atualizado, e ainda alegar que esse processo é assíncrono porque os dados foram enviados junto com uma requisição AJAX No fim das contas, as pessoas continuam conseguindo se virar mesmo sem precisar fazer nada tão grandioso. Então as ferramentas são mal usadas, abusadas ou subutilizadas Onde elas são bem usadas, você provavelmente não ouve falar disso Fato importante: na nossa organização há mais de 30 microsserviços por engenheiro. Por favor, me matem. Eu literalmente preferiria virar o Kurt Cobain a trabalhar em outra organização com um monorepo gigante e milhares de microsserviços Comentários neste post zug_zug: para sustentar essa teoria com dados reais Trabalhei em uma startup em Nova York que usava Akka (enfileiramento orientado a eventos em Scala) Por quê? Porque um gerente do emprego anterior “salvou” a empresa “quando tudo estava lento” usando isso, e então impôs essa abordagem no novo emprego? Que trabalho exigia fila? Só mostrar o 401k dos funcionários pelo site, permitir ajuste da alocação de ativos e enviar algumas centenas de e-mails por dia Como era de se esperar, quase ninguém fazia login no site do 401k Cerca de um ano depois de entrar lá, percebi que o servidor estava continuamente mal configurado e, basicamente, a concorrência para requisições web era 0 (Ninguém tinha percebido isso porque dois servidores de produção davam conta de todo o tráfego necessário) No fim, removeram o Akka por ser uma complexidade desnecessária e inútil No mês passado, a empresa fez outra rodada de investimento com opção de resgate em dinheiro; aparentemente a valuation subiu e ela ainda está indo bem scary-size: isso realmente não parece uma empresa que só contrata engenheiros “brilhantes”, né? roncesvalles: parece que não há processo de design review. E eu, pessoalmente, contrataria mais desenvolvedores com 2 a 5 anos de experiência de universidades sem nome do que recém-formados de faculdades famosas. O quanto um engenheiro de software aprende e cresce nos primeiros 5 anos de carreira é enorme, provavelmente mais do que no resto inteiro da carreira somado. burutthrow Acho que MQ virou bastante commodity Se você comprar Confluent, RedPanda ou MSK como serviço, não precisa mais administrar Kafka por conta própria Capture de dados de mudança (CDC) também ficou excelente e virou mainstream. Escrever dados no RDBMS e depois capturar as mudanças para propagá-las a outros sistemas ficou relativamente fácil Por exemplo, nesse padrão, a fila de mensagens é apenas o backbone usado pelo sistema de CDC para entregar mensagens, então isso pode dar a impressão de que as pessoas não escrevem mais sobre Kafka Essas arquiteturas claramente ainda existem e atendem às restrições da maioria das organizações Quando há filas do tipo write-once-read-many, como o Kafka, isso também serve para expor APIs a outras partes da organização. Muitas empresas usam esse padrão para compartilhar dados entre múltiplos times Equipes pequenas que possuem muitos microsserviços passam a impressão de desenvolvimento guiado por currículo, mas em empresas com mais de 100 engenheiros esse padrão faz sentido angarg12 MQ é uma ferramenta na caixa de ferramentas de sistemas distribuídos. Quando é apropriado, funciona muito bem Se a sua teoria estiver mesmo certa, acho que é esta: "as pessoas normalmente escrevem posts sobre coisas novas e brilhantes" Eu pessoalmente sempre uso filas no design, especialmente para transferir dados entre sistemas diferentes e com alto desacoplamento A única dor que tive foi quando um sistema upstream fez backfill de 7 dias de dados e a fila ficou entupida com requisições antigas Se eu tivesse deixado rodar normalmente, levaria mais de 100 horas para processar tudo, e a latência dos dados novos também dispararia A solução foi esvaziar a fila manualmente e repor manualmente os dados recentes que faltavam É preciso tomar cuidado com o tamanho não limitado das filas, mas ainda acho que é uma ferramenta excelente rossdavidh MQ, no Gartner Hype Cycle, está além do 'Peak of inflated expectations' além do 'trough of disillusionment' e subindo a 'Slope of Enlightenment', talvez até chegando ao 'plateau of productivity' robertclaus Acho muito interessante que o comentário “obviamente todos ainda usamos filas de mensagens e workers, só não escrevemos mais sobre isso” tenha ficado escondido no fundo por causa das discussões sobre microsserviços e escalabilidade real Um engenheiro júnior lendo esse tópico pode ficar com a impressão errada de que já não se deve mais descarregar computações pesadas do servidor web para workers pm90 Houve menos posts em blogs porque a tecnologia ficou entediante E isso é bom. Por exemplo, a documentação oficial do RabbitMQ está muito melhor e é muito útil As pessoas usam isso como usam Postgres/MySQL Nem é preciso tecnologia surpreendente para desenhar a arquitetura e afins Eu amo software entediante: "I love boring software" slowmovintarget A maioria dessas arquiteturas rodava em datacenters corporativos Com a migração para a nuvem e a criação de pequenos serviços stateless (e o surgimento de SPAs), sistemas complexos orientados a eventos em múltiplas etapas passaram a ser menos necessários Por exemplo, na AWS, usar SQS e um pouco de SNS, ou Kinesis para alguns casos, já basta. Nesse cenário, MQ deixa de ser o centro do design Arquiteturas baseadas em MQ são boas para processamento de dados, mas não servem tão bem para sites interativos; se a maioria das pessoas está construindo sites interativos, então a escolha parece óbvia Eu ainda projeto sistemas de eventos para processamento de dados (especialmente quando há novos fatos, mas os dados de negócio são imutáveis e você precisa saber o que estava “errado” ou qual era a informação conhecida em um momento anterior) Mas, para a maioria dos apps... não é necessário mannyv Nosso backend inteiro é baseado em filas Se é assíncrono e não precisa de tempo de resposta rápido, eu usaria fila. É simples, confiável, e a fila pode acionar Lambdas Além disso, com filas fica mais fácil coletar métricas e dados de performance Em cargas altas, a fila pode inchar para milhões de mensagens e depois ir esvaziando com o tempo Ou você pode subir centenas de Lambdas, se quiser, para processar tudo vishnugupta Pela minha experiência, MQ foi abstraído, não desapareceu Por exemplo, uma fila com SQS + polling virou um processo que chama menos vezes o servidor. Há uma fila de mensagens em algum lugar, ela só não está exposta O AWS SNS, um nível acima do SQS em termos de abstração, ficou tão rico em funcionalidades que na prática pode substituir o SQS Além disso, streaming virou uma tecnologia muito confiável, então casos de uso que usavam filas como pipeline de streaming migraram para soluções dedicadas de streaming memset Talvez isso aconteça porque Lambda (cloud functions) se popularizou mais e passou a ser suportado em várias plataformas Quando você coloca algo numa fila, no fim alguém precisa tirar aquilo dali e processar. Uma Lambda faz isso em uma única invocação. E você também não precisa rodar ou escalar workers Acho que Kafka continua popular porque é usado como armazenamento temporário de dados e há um grande ecossistema para consumir streams Eu pessoalmente uso muitas filas e estou construindo uma alternativa open source ao SQS. Fico me perguntando se uma alternativa open source ao Lambda também seria útil liampulles "A tecnologia de MQ amadureceu a ponto de já não ser interessante o suficiente para render posts, mas continua sendo amplamente usada" É isso mesmo. Acho que o caso simples de uso de comunicação assíncrona com mensagens Pub/Sub simples é muito útil e não é difícil demais de usar Nós (como comunidade de desenvolvedores) superamos a fase de event sourcing, redes complexas e construção de escala desnecessária. Ou seja, passamos do ciclo de hype Nosso time usa NATS para Pub/Sub assíncrono e Request/Response síncrono É um modelo baseado em comandos, e temos uma tabela de log enorme com todas as mensagens que enviamos O schema e o uso dessas mensagens são internos ao nosso time, e elas são removidas do NATS depois de usadas Trabalhamos com at-least-once delivery e esperamos que os handlers de mensagem sejam idempotentes Tivemos um ou dois problemas com replay de mensagens ou perda de mensagens por causa de configuração errada do NATS, mas no geral foi um grande sucesso, e éramos um time de 3 desenvolvedores Na minha opinião, é como Kubernetes. Se você ficar no básico e não tentar ser esperto demais, funciona bem

(news.ycombinator.com)

49 pontos por xguru 2024-06-21 | 11 comentários | Compartilhar no WhatsApp

Até o início dos anos 2010, falava-se muito sobre construir sistemas distribuídos baseados em MQ, mas hoje em dia quase não há textos sobre isso
Tenho algumas teorias em mente e queria saber se é uma delas ou o que outras pessoas pensam
- O Redis cobre a maioria dos casos, inclusive cache, então operar um message broker separado deixou de valer a pena. O Kafka foi para uma escala realmente enorme.
- Os bancos de dados (em um sentido amplo) ficaram muito melhores em processamento em larga escala, então os processamentos “temporários” passaram a ser tratados no repositório principal
- Descobriu-se que arquiteturas baseadas em MQ não funcionam tão bem quanto se esperava, então agora usam-se outras abordagens
- Na verdade, a tecnologia de MQ entrou numa fase de maturidade, então já não é interessante o bastante para que as pessoas escrevam sobre ela. Mas continua sendo amplamente usada

hnthrowaway_99

Muitas arquiteturas “populares” do fim dos anos 2000 até o início dos anos 2010 desapareceram depois que se percebeu que "você não é o Google. Sua empresa nunca vai ser o Google"
Naquela época, havia um grande desejo de “construir do jeito que as grandes empresas bem-sucedidas construíam”
Mas depois muita gente percebeu que 99% das empresas não precisam dessa complexidade
À medida que o hardware e os bancos de dados padrão ficaram muito melhores, o número de empresas que precisam desses “truques de escalabilidade” vem diminuindo
Meu critério para “há algum motivo para não fazer tudo isso com Postgres?” hoje é muito mais alto do que era 10 anos atrás
Comentários nesta resposta
- Agora existem máquinas únicas muito maiores disponíveis a um custo razoável. Antes era preciso um pequeno cluster, mas agora um único sistema consegue suportar muitos tipos de carga
- Sinceramente, participei de vários projetos no Google para remover filas. Então talvez seja algo ainda maior do que “perdeu popularidade”

biglain

É uma visão cínica, mas acho que arquitetura MQ e os blogs sobre isso eram “Resume Driven Development”. Na prática, faziam coisas que caberiam num único notebook sem precisar escalar além de um monólito.
Essas provavelmente eram as pessoas construindo desastres de microsserviços pesadelescos que custam dezenas de milhares de dólares por mês na AWS
E agora “pessoas que colocam como prioridade de carreira acumular conquistas técnicas, em vez de resolver problemas reais de negócio de forma pragmática” estão fazendo hype sobre IA e escrevendo posts sobre isso

tuckerconnelly

Recentemente migrei de microsserviços para um monólito porque havia complexidade demais e muito código duplicado. Sem microsserviços, a necessidade de filas de mensagens diminui
Para trabalho assíncrono, usei RabbitMQ em um projeto e parecia velho demais e excessivamente projetado
E muitas ferramentas ao redor dele (Celery) não eram tão boas quanto ferramentas modernas construídas em torno do Redis (bullmq)
Para processos em vários estágios no estilo DAG, prefiro, se possível, resolver tudo em uma tarefa grande ou dividir em poucas tarefas
Se realmente precisar de DAG, existem ferramentas feitas especificamente para isso (Airflow). Mas ouvi dizer que é difícil depurar problemas, então é melhor evitar quando possível
Acho a arquitetura multinó de Redis absurdamente complexa e problemática para escalar, então continuo com nó único. Mas fazer sharding manualmente funciona bem para mim
Comentário de kypro sobre este texto
- Na minha experiência, monólitos não reduzem a complexidade; eles apenas a deslocam
- O maior problema do monólito é que, como as preocupações entre domínios não ficam clara e explicitamente separadas, com o tempo o codebase tende a virar um caos altamente interconectado de código espaguete
- Isso é ainda mais verdade em projetos grandes com muitos desenvolvedores, especialmente quando muitos deles não entendem toda a complexidade de domínio do código com o qual mexem
- Monólitos funcionam bem para projetos pequenos com poucos desenvolvedores, mas fora isso a maioria vai se arrepender em alguns anos de ter construído um monólito
- Também não concordo com a questão dos pontos de código duplicado. Se você usa a mesma linguagem e compartilha pacotes entre projetos, não vejo por que isso seria um grande problema
- De todo modo, nunca vivi esse tipo de problema trabalhando com microsserviços
- Também questiono se microsserviços são, em média, mais complexos que monólitos
- O que mais gosto em arquitetura de microsserviços é como é simples entender e contribuir para um microsserviço individual
- A arquitetura e o provisionamento dos microsserviços podem ser mais complexos, mas, do ponto de vista de quem trabalha neles, é muito mais simples do que um monólito

democracy

Acho que esta ideia está certa: "A tecnologia de MQ amadureceu a ponto de já não ser interessante o suficiente para render posts, mas continua sendo amplamente usada"
Arquiteturas baseadas em mensageria são muito populares
Comentários neste post
- casper14: concordo. Virou apenas mais uma ferramenta. Assim como ninguém mais escreve sobre como usar máquinas virtuais na nuvem
- bwhaley: essa é a resposta certa. Quase todo sistema distribuído executado em larga escala usa filas de mensagens em alguma capacidade
- ipsum2: parece plausível. Antigamente bombavam posts sobre reescrever Angular em React; hoje todo mundo simplesmente usa React ou escreve sobre reescrever React em Vue

busterarm

Vou dar uma resposta impopular
Filas, streams e Pub/Sub são conceitos que a maioria dos engenheiros não entende bem
- Não sabem quando precisam disso, nem como usar direito, e usam para finalidades erradas
- Eu ainda trabalho com tudo isso (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
Trabalho numa empresa que contrata apenas os engenheiros mais “brilhantes”, vindos das 3 ou 4 melhores universidades da América do Norte, e para quase todos este é o primeiro emprego
Nossos engenheiros já fizeram as seguintes loucuras:
- Enfileirar dezenas de milhares de mensagens de 100 MB no RabbitMQ em segundos e depois se perguntar por que tudo explodiu
- Enviar, de modo geral, mensagens bem grandes no RabbitMQ apesar de todos os avisos para não fazer isso
- Começar projetos novos em 2024 com a versão mais recente do RabbitMQ e tentar usar filas clássicas
- Criar filas quorum sem política de replicação, ou literalmente não fazer nada para garantir HA
- Expor clusters à internet com usuário administrativo guest/guest
- O arquiteto mais sênior da organização declarar um novo padrão de arquitetura, reunir a empresa toda e fazer uma demo
  - Elogiar uma nova virtude/padrão em que você coloca uma mensagem na fila e depois cria um backchannel para um segundo consumidor processar sob demanda a mensagem que está na fila (e aí deixa de ser fila)
  - E ninguém, exceto eu, disse “por que colocar na fila mensagens que precisam ser processadas em ordem?”, e esse “padrão” pegou!
- Usar Kafka como fila de mensagens padrão
- Enviar dados de um datacenter central para datacenters distribuídos globalmente, aplicar bloqueio global ao objeto e a todas as operações até que cada datacenter de destino confirme ter recebido o objeto atualizado, e ainda alegar que esse processo é assíncrono porque os dados foram enviados junto com uma requisição AJAX
No fim das contas, as pessoas continuam conseguindo se virar mesmo sem precisar fazer nada tão grandioso. Então as ferramentas são mal usadas, abusadas ou subutilizadas
Onde elas são bem usadas, você provavelmente não ouve falar disso
Fato importante: na nossa organização há mais de 30 microsserviços por engenheiro. Por favor, me matem. Eu literalmente preferiria virar o Kurt Cobain a trabalhar em outra organização com um monorepo gigante e milhares de microsserviços
Comentários neste post
- zug_zug: para sustentar essa teoria com dados reais
  - Trabalhei em uma startup em Nova York que usava Akka (enfileiramento orientado a eventos em Scala)
  - Por quê? Porque um gerente do emprego anterior “salvou” a empresa “quando tudo estava lento” usando isso, e então impôs essa abordagem no novo emprego?
  - Que trabalho exigia fila? Só mostrar o 401k dos funcionários pelo site, permitir ajuste da alocação de ativos e enviar algumas centenas de e-mails por dia
  - Como era de se esperar, quase ninguém fazia login no site do 401k
  - Cerca de um ano depois de entrar lá, percebi que o servidor estava continuamente mal configurado e, basicamente, a concorrência para requisições web era 0
  - (Ninguém tinha percebido isso porque dois servidores de produção davam conta de todo o tráfego necessário)
  - No fim, removeram o Akka por ser uma complexidade desnecessária e inútil
  - No mês passado, a empresa fez outra rodada de investimento com opção de resgate em dinheiro; aparentemente a valuation subiu e ela ainda está indo bem
- scary-size: isso realmente não parece uma empresa que só contrata engenheiros “brilhantes”, né?
- roncesvalles: parece que não há processo de design review. E eu, pessoalmente, contrataria mais desenvolvedores com 2 a 5 anos de experiência de universidades sem nome do que recém-formados de faculdades famosas. O quanto um engenheiro de software aprende e cresce nos primeiros 5 anos de carreira é enorme, provavelmente mais do que no resto inteiro da carreira somado.

burutthrow

Acho que MQ virou bastante commodity
Se você comprar Confluent, RedPanda ou MSK como serviço, não precisa mais administrar Kafka por conta própria
Capture de dados de mudança (CDC) também ficou excelente e virou mainstream. Escrever dados no RDBMS e depois capturar as mudanças para propagá-las a outros sistemas ficou relativamente fácil
Por exemplo, nesse padrão, a fila de mensagens é apenas o backbone usado pelo sistema de CDC para entregar mensagens, então isso pode dar a impressão de que as pessoas não escrevem mais sobre Kafka
Essas arquiteturas claramente ainda existem e atendem às restrições da maioria das organizações
Quando há filas do tipo write-once-read-many, como o Kafka, isso também serve para expor APIs a outras partes da organização. Muitas empresas usam esse padrão para compartilhar dados entre múltiplos times
Equipes pequenas que possuem muitos microsserviços passam a impressão de desenvolvimento guiado por currículo, mas em empresas com mais de 100 engenheiros esse padrão faz sentido

angarg12

MQ é uma ferramenta na caixa de ferramentas de sistemas distribuídos. Quando é apropriado, funciona muito bem
Se a sua teoria estiver mesmo certa, acho que é esta: "as pessoas normalmente escrevem posts sobre coisas novas e brilhantes"
Eu pessoalmente sempre uso filas no design, especialmente para transferir dados entre sistemas diferentes e com alto desacoplamento
A única dor que tive foi quando um sistema upstream fez backfill de 7 dias de dados e a fila ficou entupida com requisições antigas
- Se eu tivesse deixado rodar normalmente, levaria mais de 100 horas para processar tudo, e a latência dos dados novos também dispararia
- A solução foi esvaziar a fila manualmente e repor manualmente os dados recentes que faltavam
É preciso tomar cuidado com o tamanho não limitado das filas, mas ainda acho que é uma ferramenta excelente

rossdavidh

MQ, no Gartner Hype Cycle, está
- além do 'Peak of inflated expectations'
- além do 'trough of disillusionment'
- e subindo a 'Slope of Enlightenment', talvez até chegando ao 'plateau of productivity'

robertclaus

Acho muito interessante que o comentário “obviamente todos ainda usamos filas de mensagens e workers, só não escrevemos mais sobre isso” tenha ficado escondido no fundo por causa das discussões sobre microsserviços e escalabilidade real
Um engenheiro júnior lendo esse tópico pode ficar com a impressão errada de que já não se deve mais descarregar computações pesadas do servidor web para workers

pm90

Houve menos posts em blogs porque a tecnologia ficou entediante
E isso é bom. Por exemplo, a documentação oficial do RabbitMQ está muito melhor e é muito útil
As pessoas usam isso como usam Postgres/MySQL
Nem é preciso tecnologia surpreendente para desenhar a arquitetura e afins
Eu amo software entediante: "I love boring software"

slowmovintarget

A maioria dessas arquiteturas rodava em datacenters corporativos
Com a migração para a nuvem e a criação de pequenos serviços stateless (e o surgimento de SPAs), sistemas complexos orientados a eventos em múltiplas etapas passaram a ser menos necessários
Por exemplo, na AWS, usar SQS e um pouco de SNS, ou Kinesis para alguns casos, já basta. Nesse cenário, MQ deixa de ser o centro do design
Arquiteturas baseadas em MQ são boas para processamento de dados, mas não servem tão bem para sites interativos; se a maioria das pessoas está construindo sites interativos, então a escolha parece óbvia
Eu ainda projeto sistemas de eventos para processamento de dados (especialmente quando há novos fatos, mas os dados de negócio são imutáveis e você precisa saber o que estava “errado” ou qual era a informação conhecida em um momento anterior)
Mas, para a maioria dos apps... não é necessário

mannyv

Nosso backend inteiro é baseado em filas
Se é assíncrono e não precisa de tempo de resposta rápido, eu usaria fila. É simples, confiável, e a fila pode acionar Lambdas
Além disso, com filas fica mais fácil coletar métricas e dados de performance
- Em cargas altas, a fila pode inchar para milhões de mensagens e depois ir esvaziando com o tempo
- Ou você pode subir centenas de Lambdas, se quiser, para processar tudo

vishnugupta

Pela minha experiência, MQ foi abstraído, não desapareceu
Por exemplo, uma fila com SQS + polling virou um processo que chama menos vezes o servidor. Há uma fila de mensagens em algum lugar, ela só não está exposta
O AWS SNS, um nível acima do SQS em termos de abstração, ficou tão rico em funcionalidades que na prática pode substituir o SQS
Além disso, streaming virou uma tecnologia muito confiável, então casos de uso que usavam filas como pipeline de streaming migraram para soluções dedicadas de streaming

memset

Talvez isso aconteça porque Lambda (cloud functions) se popularizou mais e passou a ser suportado em várias plataformas
Quando você coloca algo numa fila, no fim alguém precisa tirar aquilo dali e processar. Uma Lambda faz isso em uma única invocação. E você também não precisa rodar ou escalar workers
Acho que Kafka continua popular porque é usado como armazenamento temporário de dados e há um grande ecossistema para consumir streams
Eu pessoalmente uso muitas filas e estou construindo uma alternativa open source ao SQS. Fico me perguntando se uma alternativa open source ao Lambda também seria útil

liampulles

"A tecnologia de MQ amadureceu a ponto de já não ser interessante o suficiente para render posts, mas continua sendo amplamente usada"
- É isso mesmo. Acho que o caso simples de uso de comunicação assíncrona com mensagens Pub/Sub simples é muito útil e não é difícil demais de usar
Nós (como comunidade de desenvolvedores) superamos a fase de event sourcing, redes complexas e construção de escala desnecessária. Ou seja, passamos do ciclo de hype
Nosso time usa NATS para Pub/Sub assíncrono e Request/Response síncrono
- É um modelo baseado em comandos, e temos uma tabela de log enorme com todas as mensagens que enviamos
- O schema e o uso dessas mensagens são internos ao nosso time, e elas são removidas do NATS depois de usadas
- Trabalhamos com at-least-once delivery e esperamos que os handlers de mensagem sejam idempotentes
Tivemos um ou dois problemas com replay de mensagens ou perda de mensagens por causa de configuração errada do NATS, mas no geral foi um grande sucesso, e éramos um time de 3 desenvolvedores
Na minha opinião, é como Kubernetes. Se você ficar no básico e não tentar ser esperto demais, funciona bem

11 comentários

finnchoi 2024-06-25

Há situações em que uma fila é necessária. Porém, na maioria dos cenários de escala e uso, usar uma fila ou operá-la em cluster muitas vezes aumenta a complexidade sem trazer grandes vantagens em termos de desempenho. Estruturas complexas das quais grandes empresas se orgulham, projetadas pensando em escalabilidade e grandes volumes de dados, talvez nunca cheguem a ser adequadas para o meu sistema.

Mesmo tecnologias novas com forte apelo técnico e arquiteturas elegantes exigem considerar problemas reais e escolher a solução adequada. Na maioria dos casos, não há tanto dado assim para processar, e muitas vezes o PostgreSQL dá conta.

Nós reconhecemos esse problema e estamos desenvolvendo um banco de dados com arquitetura simples, capaz de processar dados na casa dos TBs em um único nó. Com alguma cautela, recomendamos que você também considere essa opção.
Fazendo com que dados de jurisprudência fiquem prontos para busca rápida

dakbutfly 2024-06-24

A programação procedural é popularmente fácil de entender, mas acho que a abordagem com MQ não é algo que se compreende de imediato e pode ser difícil entender a estrutura. Em geral, nas empresas nem sempre todos têm o mesmo nível de conhecimento, e nesses casos, se o MQ for usado com conhecimento inadequado, parece que vira um inferno.

Acho que isso acontece não só com MQ, mas também com a maioria das tecnologias que exigem certo nível de conhecimento quando são aplicadas sem uma formação adequada.

nemorize 2024-06-21

No PHP, MQ é praticamente indispensável...

halfenif 2024-06-21

Ai!

Agora mesmo estou tocando um Toy Project com um nome que inclui Quee.

kandk 2024-06-21

Sinceramente, se o serviço for atender só dentro do nosso país em 99% dos casos, acho que nada disso é necessário..

superwoou 2024-06-21

Não seria mais importante do que o escopo do serviço a natureza do serviço e o quanto é preciso avaliar a eficiência de custo?

2024-06-21

[Este comentário foi ocultado.]

bus710 2024-06-22

Será que isso acontece porque, como o processo de tomada de decisão tende a ser vertical, algo mais “procedural” acaba sendo preferido ou considerado mais adequado?
Se cada departamento e equipe estiver organizado de forma mais frouxa, fico curioso se uma arquitetura menos procedural funcionaria de maneira mais fluida e, por isso, se aplicações dessas filas poderiam funcionar melhor.

savvykang 2024-06-21

Parece que desenvolvimento orientado a currículo é a palavra-chave que atravessa esse fenômeno de modismo.

hyeonseokoh94 2024-06-22

Nossa, isso é uma frase genial mesmo, desenvolvimento guiado por currículo...

savvykang 2024-06-23

Como variação, também existe o desenvolvimento guiado por hype