¿Por qué la arquitectura basada en colas de mensajes está perdiendo popularidad últimamente?

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

Hasta principios de la década de 2010 se hablaba mucho de construir sistemas distribuidos basados en MQ, pero últimamente casi no se ven textos sobre eso Algunas teorías que se me ocurren son las siguientes; no sé si será una de estas o qué piensan los demás Redis cubre la mayoría de los casos de uso e incluso el caché, así que ya no vale la pena operar un broker de mensajes aparte. Kafka se fue a una escala realmente masiva. A medida que la DB (en un sentido amplio) se volvió mucho mejor para manejar grandes volúmenes, los procesos "temporales" se empezaron a resolver en el almacenamiento principal Nos dimos cuenta de que la arquitectura basada en MQ no funciona tan bien como se esperaba, así que ahora se usan otros enfoques En realidad, la tecnología MQ ya entró en una etapa de madurez, así que ya no resulta lo bastante interesante como para que la gente escriba sobre ella. Pero sigue usándose ampliamente hnthrowaway_99 Muchas arquitecturas "populares" de fines de los 2000 e inicios de los 2010 desaparecieron al final cuando se entendió que "tú no eres Google. Tu empresa jamás será Google" En esa época había un gran deseo de "construir como construyen las grandes empresas exitosas" Pero después mucha gente se dio cuenta de que el 99% de las empresas no necesita esa complejidad Como el hardware y las bases de datos estándar mejoraron muchísimo, cada vez hay menos empresas que necesitan estos "Scalability Trick" Mi umbral de "¿hay alguna razón para no hacer todo esto con Postgres?" es hoy mucho más alto que hace 10 años Comentarios a este comentario Ahora existen máquinas individuales mucho más grandes que pueden usarse a un costo razonable. Antes se necesitaban pequeños clústeres, pero ahora un solo sistema puede absorber muchísimas cargas de trabajo distintas Si soy sincero, participé en varios proyectos dentro de Google para eliminar colas. Así que quizá sea algo más que una simple pérdida de popularidad biglain Suena cínico, pero creo que la arquitectura MQ y los blogs sobre ella eran "Resume Driven Development". En la práctica, hacían cosas que podían correr en una sola laptop sin necesidad de escalar más allá de un monolito. Probablemente son las mismas personas que construyen desastres de microservicios de pesadilla que cuestan decenas de miles de dólares al mes en AWS Y la gente que "prioriza en su carrera acumular logros técnicos por encima de resolver problemas reales del negocio de forma práctica" ahora anda hypeando la AI y escribiendo blogs sobre eso tuckerconnelly Hace poco migramos de microservicios a un monolito porque los microservicios eran demasiado complejos y tenían demasiado código duplicado. Sin microservicios, disminuye la necesidad de colas de mensajes Para trabajo asíncrono usé RabbitMQ en un proyecto, pero me dio la impresión de ser demasiado viejo y excesivamente diseñado Y muchas herramientas de su ecosistema (Celery) no eran tan buenas como las herramientas modernas construidas alrededor de redis (bullmq) Para procesos estilo DAG de múltiples etapas, prefiero si es posible hacer todo dentro de un solo job grande o dividirlo en una pequeña cantidad de jobs Si de verdad necesitas un DAG, existen herramientas hechas específicamente para eso (Airflow). Pero he oído que es difícil depurar problemas ahí, así que conviene evitarlo si es posible Sigo usando Redis en un solo nodo porque su arquitectura multinodo me parece ridículamente compleja y problemática para escalar. Pero hacer sharding manualmente me funciona bien Comentario de kypro sobre este texto Según mi experiencia, un monolito no reduce la complejidad, solo la mueve de lugar El mayor problema del monolito es que, como las responsabilidades entre dominios no están separadas de forma clara y explícita, con el tiempo es muy fácil que la base de código termine convertida en un desastre de spaghetti code altamente interconectado Esto es aún más cierto cuando se construyen proyectos grandes con muchos desarrolladores, especialmente si muchos de ellos no entienden toda la complejidad del dominio del código que tocan Los monolitos son adecuados para proyectos pequeños con pocos desarrolladores, pero en otros casos probablemente en unos años terminarás arrepintiéndote de haber construido un monolito Tampoco estoy de acuerdo con lo del código duplicado. Si usas el mismo lenguaje y compartes paquetes entre proyectos, no veo por qué eso sería un problema tan grande En cualquier caso, trabajando con microservicios nunca me topé con ese problema Y también pondría en duda que los microservicios sean, en promedio, más complejos que un monolito Lo que más me gusta de la arquitectura de microservicios es lo sencillo que resulta entender y contribuir a cada microservicio individual La arquitectura y el aprovisionamiento de microservicios pueden ser más complejos, pero desde la perspectiva del desarrollador que trabaja en ellos, suele ser mucho más sencillo que trabajar en un monolito democracy Creo que esta idea es correcta: "La tecnología MQ ya maduró, así que ya no es lo bastante interesante como para escribir sobre ella, pero sigue siendo muy usada" La arquitectura basada en mensajería sigue siendo muy popular Comentarios sobre este texto casper14 : De acuerdo. Simplemente se convirtió en una herramienta más. Igual que ya nadie escribe sobre cómo usar máquinas virtuales en la nube bwhaley : Esta es la respuesta correcta. Apostaría a que casi cualquier sistema distribuido que corra a gran escala usa colas de mensajes en alguna capacidad ipsum2 : Esto suena muy probable. Antes eran populares las publicaciones sobre reescribir Angular en React; ahora todos simplemente usan React o escriben sobre reescribir React en vue busterarm Voy a dar una respuesta impopular Las colas, los streams y el Pub/Sub son conceptos que la mayoría de los ingenieros no entiende bien No saben cuándo se necesitan, no saben usarlos correctamente y los usan para cosas equivocadas Yo sigo trabajando con todo lo anterior (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) Trabajo en una empresa que contrata solo a los ingenieros más "brillantes" egresados de las 3 o 4 mejores universidades de Norteamérica, y para casi todos es su primer trabajo Nuestros ingenieros han hecho locuras como estas: Meter decenas de miles de mensajes de 100MB en RabbitMQ de golpe y luego preguntarse por qué explota Enviar mensajes bastante grandes por RabbitMQ de manera habitual, pese a todas las advertencias de no hacerlo Empezar proyectos nuevos en la versión más reciente de RabbitMQ en 2024 e intentar usar classic queues Crear quorum queues sin políticas de replicación o, literalmente, no hacer nada para tener HA Exponer el clúster a internet con el usuario de administración guest/guest Que el arquitecto más senior de la organización declare un nuevo patrón arquitectónico, convoque una reunión general y haga una demo Elogiando la nueva virtud/patrón de meter mensajes en una cola y luego crear un backchannel para que un segundo consumidor procese a demanda los mensajes que están en la cola (y así deje de ser una cola) Y nadie excepto yo dijo: "¿por qué poner en una cola mensajes que deben procesarse en orden?"; ¡y ese 'patrón' se terminó adoptando! Usar Kafka como cola de mensajes por defecto Transferir datos desde un centro de datos central a centros de datos distribuidos por todo el mundo, aplicar un bloqueo global sobre el objeto y todas las operaciones relacionadas hasta confirmar que cada centro de datos de destino recibió el objeto actualizado. Y como los datos se enviaban junto con una solicitud AJAX, afirmar que el proceso era asíncrono En consecuencia, la gente sigue logrando que las cosas funcionen aunque no estén haciendo nada tan grandioso. Así que estas herramientas se usan mal, se abusan o se aprovechan poco Donde se usan bien, probablemente ni te enteras Dato importante: en nuestra organización hay más de 30 microservicios por cada ingeniero. Por favor, mátenme. Preferiría literalmente convertirme en Kurt Cobain antes que trabajar en otra organización con un monorepo gigante lleno de miles de microservicios Comentarios sobre este texto zug_zug : Para respaldar esta teoría con datos reales Trabajé en un startup de Nueva York que usaba Akka (el sistema de colas orientado a eventos de Scala) ¿Por qué? ¿Porque un gerente de un trabajo anterior dijo que ese enfoque había "salvado" a una empresa cuando "todo era lento", y por eso lo impuso en su nuevo trabajo? ¿Qué trabajo realmente necesitaba colas? Básicamente solo mostrar los 401k de empleados en un sitio web, permitirles ajustar la asignación de activos y enviar unos cientos de correos al día Como era de esperarse, casi nadie iniciaba sesión en el sitio del 401k Aproximadamente un año después de empezar a trabajar ahí, me di cuenta de que los servidores seguían mal configurados y que, básicamente, la concurrencia de las solicitudes web era 0 (No se habían dado cuenta porque 2 servidores de producción siempre habían sido suficientes para manejar todo el tráfico) Al final eliminaron Akka por ser una complejidad innecesaria y redundante El mes pasado esta empresa hizo otra ronda de financiamiento con opción de cash out, su valuación claramente subió y parece que todavía le va bien scary-size : ¿Esto de verdad suena a contratar solo ingenieros "brillantes"? roncesvalles : Suena a que no tienen proceso de design review. Y yo preferiría contratar a un desarrollador con 2-5 años de experiencia de una universidad desconocida antes que a recién egresados de una universidad famosa. Lo que un software engineer aprende y crece en sus primeros 5 años de carrera es enorme, probablemente más que en el resto de su carrera combinada. burutthrow Creo que MQ se volvió bastante commoditized Si compras Kafka como servicio con Confluent, RedPanda o MSK, ya no necesitas administrarlo tú mismo El Change Data Capture (CDC) también se volvió muy bueno y pasó al mainstream. Es relativamente fácil escribir datos en un RDBMS, capturar los cambios y propagarlos a otros sistemas Por ejemplo, los message queues son solo la columna vertebral que usa un sistema CDC para entregar mensajes, así que este patrón implica que la gente no necesariamente escribe sobre Kafka Estas arquitecturas claramente siguen existiendo y satisfacen las restricciones de la mayoría de las organizaciones Cuando tienes colas de tipo write-once read-many como Kafka, puedes exponer APIs de datos a otras partes de la organización. Muchas empresas usan este patrón para mezclar y reutilizar datos entre varios equipos Tener muchos microservicios en manos de un equipo pequeño suena a desarrollo guiado por el currículum, pero en una empresa con más de 100 ingenieros este patrón sí tiene sentido angarg12 MQ es una herramienta dentro de la caja de herramientas de sistemas distribuidos. Cuando corresponde, funciona muy bien Si tu teoría realmente es cierta, yo apostaría por esta: "La gente normalmente escribe posts en blogs sobre lo nuevo y brillante" Yo personalmente siempre uso colas en mis diseños, especialmente para mover datos entre sistemas distintos con alto desacoplamiento El único dolor serio que tuve fue cuando un sistema upstream reinyectó 7 días de datos y la cola se atascó con solicitudes viejas Si lo hubiéramos dejado correr normalmente, procesar todos los datos habría tomado más de 100 horas y la latencia de los datos nuevos también se habría disparado La solución fue purgar manualmente la cola y volver a cargar manualmente los datos recientes faltantes Hay que tener cuidado con el tamaño no acotado de las colas, pero sigo pensando que es una gran herramienta rossdavidh MQ está en el Gartner Hype Cycle Ya pasó el 'Peak of inflated expectations' Ya pasó el 'trough of disillusionment' Y va rumbo al 'Slope of Enlightenment' o incluso al 'plateau of productivity' robertclaus Es muy interesante que el comentario de "claramente todos seguimos usando colas de mensajes y workers, simplemente ya no escribimos sobre eso" quede enterrado por las discusiones sobre microservicios y escalabilidad real Un ingeniero junior que lea este hilo podría quedarse con la impresión equivocada de que ya no conviene descargar el trabajo pesado del servidor web a workers pm90 Hay menos posts de blog sobre esto porque la tecnología se volvió aburrida Y eso es bueno. Por ejemplo, la documentación oficial de RabbitMQ ahora es mucho mejor y muy útil La gente la usa como usa Postgres/MySQL Ni siquiera se necesita una tecnología sorprendente para diseñar la arquitectura, etc. Amo el software aburrido: "I love boring software" slowmovintarget La mayoría de estas arquitecturas corrían en centros de datos empresariales Tras la migración a la nube y la creación de pequeños servicios stateless (con la llegada de las SPA), se volvió menos necesaria la compleja lógica de sistemas orientados a eventos por etapas Por ejemplo, en AWS basta con usar SQS y un poco de SNS, o Kinesis para unas cuantas cosas. Ahí MQ ya no está en el centro del diseño Las arquitecturas basadas en MQ son buenas para procesamiento de datos, pero no para sitios web interactivos; y si la mayoría de la gente construye sitios web interactivos, la elección parece obvia Yo todavía diseño sistemas de eventos para procesamiento de datos (sobre todo cuando hay hechos nuevos pero también datos de negocio inmutables donde antes se sabía otra cosa o había información "incorrecta") Pero en la mayoría de las apps... no hace falta mannyv Todo nuestro backend está basado en colas Si algo es asíncrono y no requiere tiempos de respuesta rápidos, usa una cola. Es fácil, confiable y la cola puede disparar lambdas Además, las colas facilitan recopilar métricas y datos de rendimiento. Cuando hay mucha carga, la cola puede crecer hasta millones de mensajes y luego bajar con el tiempo, o también puedes lanzar cientos de lambdas si quieres procesar todos los mensajes vishnugupta Según mi experiencia, MQ se abstrajo, no desapareció Por ejemplo, las colas con SQS + polling se transformaron en procesos que llaman menos al servidor. La cola de mensajes sigue ahí en alguna parte, solo que ya no está expuesta AWS SNS, que está un nivel más abstraído que SQS, se volvió tan rico en funcionalidades que en la práctica puede reemplazar a SQS Además, el streaming se volvió una tecnología muy estable, así que los casos de uso que usaban colas como pipeline de streaming migraron a streaming dedicado memset Puede deberse a que lambda (cloud functions) se volvió más popular y ya tiene soporte en varias plataformas Si agregas algo a una cola, al final alguien tiene que sacarlo y procesarlo. Una lambda hace eso en una sola invocación. Además, ya no necesitas correr ni escalar workers Creo que Kafka sigue siendo popular porque se usa como almacenamiento temporal de datos y porque tiene un gran ecosistema para consumir streams Yo personalmente uso mucho las colas y estoy construyendo una alternativa open source a SQS. También me pregunto si sería útil una alternativa open source a lambda liampulles "La tecnología MQ ya entró en una etapa de madurez, así que ya no resulta lo bastante interesante como para que la gente escriba sobre ella. Pero sigue usándose ampliamente" Sí, eso es correcto. Creo que los casos simples de comunicación asíncrona usando mensajería Pub/Sub simple son muy útiles y no tan difíciles de usar Nosotros (como comunidad de desarrolladores) ya superamos el event sourcing, las redes complejas y la construcción a escala innecesaria. Es decir, ya pasamos el ciclo del hype Nuestro equipo usa NATS tanto para Pub/Sub asíncrono como para Request/Response síncrono Es un modelo basado en comandos y tenemos una enorme tabla de logs con todos los mensajes que enviamos El esquema y el uso de esos mensajes son internos del equipo y se eliminan de NATS después de usarlos Hacemos at-least-once delivery y esperamos que los handlers de mensajes sean idempotentes Tuvimos uno o dos problemas por configuraciones incorrectas de NATS que provocaron replay o pérdida de mensajes, pero en general ha sido muy exitoso y éramos un equipo de 3 desarrolladores En mi opinión es como Kubernetes. Si te quedas con lo básico y no intentas ser demasiado listo, funciona bien

(news.ycombinator.com)

49 puntos por xguru 2024-06-21 | 11 comentarios | Compartir por WhatsApp

Hasta principios de la década de 2010 se hablaba mucho de construir sistemas distribuidos basados en MQ, pero últimamente casi no se ven textos sobre eso
Algunas teorías que se me ocurren son las siguientes; no sé si será una de estas o qué piensan los demás
- Redis cubre la mayoría de los casos de uso e incluso el caché, así que ya no vale la pena operar un broker de mensajes aparte. Kafka se fue a una escala realmente masiva.
- A medida que la DB (en un sentido amplio) se volvió mucho mejor para manejar grandes volúmenes, los procesos "temporales" se empezaron a resolver en el almacenamiento principal
- Nos dimos cuenta de que la arquitectura basada en MQ no funciona tan bien como se esperaba, así que ahora se usan otros enfoques
- En realidad, la tecnología MQ ya entró en una etapa de madurez, así que ya no resulta lo bastante interesante como para que la gente escriba sobre ella. Pero sigue usándose ampliamente

hnthrowaway_99

Muchas arquitecturas "populares" de fines de los 2000 e inicios de los 2010 desaparecieron al final cuando se entendió que "tú no eres Google. Tu empresa jamás será Google"
En esa época había un gran deseo de "construir como construyen las grandes empresas exitosas"
Pero después mucha gente se dio cuenta de que el 99% de las empresas no necesita esa complejidad
Como el hardware y las bases de datos estándar mejoraron muchísimo, cada vez hay menos empresas que necesitan estos "Scalability Trick"
Mi umbral de "¿hay alguna razón para no hacer todo esto con Postgres?" es hoy mucho más alto que hace 10 años
Comentarios a este comentario
- Ahora existen máquinas individuales mucho más grandes que pueden usarse a un costo razonable. Antes se necesitaban pequeños clústeres, pero ahora un solo sistema puede absorber muchísimas cargas de trabajo distintas
- Si soy sincero, participé en varios proyectos dentro de Google para eliminar colas. Así que quizá sea algo más que una simple pérdida de popularidad

biglain

Suena cínico, pero creo que la arquitectura MQ y los blogs sobre ella eran "Resume Driven Development". En la práctica, hacían cosas que podían correr en una sola laptop sin necesidad de escalar más allá de un monolito.
Probablemente son las mismas personas que construyen desastres de microservicios de pesadilla que cuestan decenas de miles de dólares al mes en AWS
Y la gente que "prioriza en su carrera acumular logros técnicos por encima de resolver problemas reales del negocio de forma práctica" ahora anda hypeando la AI y escribiendo blogs sobre eso

tuckerconnelly

Hace poco migramos de microservicios a un monolito porque los microservicios eran demasiado complejos y tenían demasiado código duplicado. Sin microservicios, disminuye la necesidad de colas de mensajes
Para trabajo asíncrono usé RabbitMQ en un proyecto, pero me dio la impresión de ser demasiado viejo y excesivamente diseñado
Y muchas herramientas de su ecosistema (Celery) no eran tan buenas como las herramientas modernas construidas alrededor de redis (bullmq)
Para procesos estilo DAG de múltiples etapas, prefiero si es posible hacer todo dentro de un solo job grande o dividirlo en una pequeña cantidad de jobs
Si de verdad necesitas un DAG, existen herramientas hechas específicamente para eso (Airflow). Pero he oído que es difícil depurar problemas ahí, así que conviene evitarlo si es posible
Sigo usando Redis en un solo nodo porque su arquitectura multinodo me parece ridículamente compleja y problemática para escalar. Pero hacer sharding manualmente me funciona bien
Comentario de kypro sobre este texto
- Según mi experiencia, un monolito no reduce la complejidad, solo la mueve de lugar
- El mayor problema del monolito es que, como las responsabilidades entre dominios no están separadas de forma clara y explícita, con el tiempo es muy fácil que la base de código termine convertida en un desastre de spaghetti code altamente interconectado
- Esto es aún más cierto cuando se construyen proyectos grandes con muchos desarrolladores, especialmente si muchos de ellos no entienden toda la complejidad del dominio del código que tocan
- Los monolitos son adecuados para proyectos pequeños con pocos desarrolladores, pero en otros casos probablemente en unos años terminarás arrepintiéndote de haber construido un monolito
- Tampoco estoy de acuerdo con lo del código duplicado. Si usas el mismo lenguaje y compartes paquetes entre proyectos, no veo por qué eso sería un problema tan grande
- En cualquier caso, trabajando con microservicios nunca me topé con ese problema
- Y también pondría en duda que los microservicios sean, en promedio, más complejos que un monolito
- Lo que más me gusta de la arquitectura de microservicios es lo sencillo que resulta entender y contribuir a cada microservicio individual
- La arquitectura y el aprovisionamiento de microservicios pueden ser más complejos, pero desde la perspectiva del desarrollador que trabaja en ellos, suele ser mucho más sencillo que trabajar en un monolito

democracy

Creo que esta idea es correcta: "La tecnología MQ ya maduró, así que ya no es lo bastante interesante como para escribir sobre ella, pero sigue siendo muy usada"
La arquitectura basada en mensajería sigue siendo muy popular
Comentarios sobre este texto
- casper14 : De acuerdo. Simplemente se convirtió en una herramienta más. Igual que ya nadie escribe sobre cómo usar máquinas virtuales en la nube
- bwhaley : Esta es la respuesta correcta. Apostaría a que casi cualquier sistema distribuido que corra a gran escala usa colas de mensajes en alguna capacidad
- ipsum2 : Esto suena muy probable. Antes eran populares las publicaciones sobre reescribir Angular en React; ahora todos simplemente usan React o escriben sobre reescribir React en vue

busterarm

Voy a dar una respuesta impopular
Las colas, los streams y el Pub/Sub son conceptos que la mayoría de los ingenieros no entiende bien
- No saben cuándo se necesitan, no saben usarlos correctamente y los usan para cosas equivocadas
- Yo sigo trabajando con todo lo anterior (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
Trabajo en una empresa que contrata solo a los ingenieros más "brillantes" egresados de las 3 o 4 mejores universidades de Norteamérica, y para casi todos es su primer trabajo
Nuestros ingenieros han hecho locuras como estas:
- Meter decenas de miles de mensajes de 100MB en RabbitMQ de golpe y luego preguntarse por qué explota
- Enviar mensajes bastante grandes por RabbitMQ de manera habitual, pese a todas las advertencias de no hacerlo
- Empezar proyectos nuevos en la versión más reciente de RabbitMQ en 2024 e intentar usar classic queues
- Crear quorum queues sin políticas de replicación o, literalmente, no hacer nada para tener HA
- Exponer el clúster a internet con el usuario de administración guest/guest
- Que el arquitecto más senior de la organización declare un nuevo patrón arquitectónico, convoque una reunión general y haga una demo
  - Elogiando la nueva virtud/patrón de meter mensajes en una cola y luego crear un backchannel para que un segundo consumidor procese a demanda los mensajes que están en la cola (y así deje de ser una cola)
  - Y nadie excepto yo dijo: "¿por qué poner en una cola mensajes que deben procesarse en orden?"; ¡y ese 'patrón' se terminó adoptando!
- Usar Kafka como cola de mensajes por defecto
- Transferir datos desde un centro de datos central a centros de datos distribuidos por todo el mundo, aplicar un bloqueo global sobre el objeto y todas las operaciones relacionadas hasta confirmar que cada centro de datos de destino recibió el objeto actualizado. Y como los datos se enviaban junto con una solicitud AJAX, afirmar que el proceso era asíncrono
En consecuencia, la gente sigue logrando que las cosas funcionen aunque no estén haciendo nada tan grandioso. Así que estas herramientas se usan mal, se abusan o se aprovechan poco
Donde se usan bien, probablemente ni te enteras
Dato importante: en nuestra organización hay más de 30 microservicios por cada ingeniero. Por favor, mátenme. Preferiría literalmente convertirme en Kurt Cobain antes que trabajar en otra organización con un monorepo gigante lleno de miles de microservicios
Comentarios sobre este texto
- zug_zug : Para respaldar esta teoría con datos reales
  - Trabajé en un startup de Nueva York que usaba Akka (el sistema de colas orientado a eventos de Scala)
  - ¿Por qué? ¿Porque un gerente de un trabajo anterior dijo que ese enfoque había "salvado" a una empresa cuando "todo era lento", y por eso lo impuso en su nuevo trabajo?
  - ¿Qué trabajo realmente necesitaba colas? Básicamente solo mostrar los 401k de empleados en un sitio web, permitirles ajustar la asignación de activos y enviar unos cientos de correos al día
  - Como era de esperarse, casi nadie iniciaba sesión en el sitio del 401k
  - Aproximadamente un año después de empezar a trabajar ahí, me di cuenta de que los servidores seguían mal configurados y que, básicamente, la concurrencia de las solicitudes web era 0
  - (No se habían dado cuenta porque 2 servidores de producción siempre habían sido suficientes para manejar todo el tráfico)
  - Al final eliminaron Akka por ser una complejidad innecesaria y redundante
  - El mes pasado esta empresa hizo otra ronda de financiamiento con opción de cash out, su valuación claramente subió y parece que todavía le va bien
- scary-size : ¿Esto de verdad suena a contratar solo ingenieros "brillantes"?
- roncesvalles : Suena a que no tienen proceso de design review. Y yo preferiría contratar a un desarrollador con 2-5 años de experiencia de una universidad desconocida antes que a recién egresados de una universidad famosa. Lo que un software engineer aprende y crece en sus primeros 5 años de carrera es enorme, probablemente más que en el resto de su carrera combinada.

burutthrow

Creo que MQ se volvió bastante commoditized
Si compras Kafka como servicio con Confluent, RedPanda o MSK, ya no necesitas administrarlo tú mismo
El Change Data Capture (CDC) también se volvió muy bueno y pasó al mainstream. Es relativamente fácil escribir datos en un RDBMS, capturar los cambios y propagarlos a otros sistemas
Por ejemplo, los message queues son solo la columna vertebral que usa un sistema CDC para entregar mensajes, así que este patrón implica que la gente no necesariamente escribe sobre Kafka
Estas arquitecturas claramente siguen existiendo y satisfacen las restricciones de la mayoría de las organizaciones
Cuando tienes colas de tipo write-once read-many como Kafka, puedes exponer APIs de datos a otras partes de la organización. Muchas empresas usan este patrón para mezclar y reutilizar datos entre varios equipos
Tener muchos microservicios en manos de un equipo pequeño suena a desarrollo guiado por el currículum, pero en una empresa con más de 100 ingenieros este patrón sí tiene sentido

angarg12

MQ es una herramienta dentro de la caja de herramientas de sistemas distribuidos. Cuando corresponde, funciona muy bien
Si tu teoría realmente es cierta, yo apostaría por esta: "La gente normalmente escribe posts en blogs sobre lo nuevo y brillante"
Yo personalmente siempre uso colas en mis diseños, especialmente para mover datos entre sistemas distintos con alto desacoplamiento
El único dolor serio que tuve fue cuando un sistema upstream reinyectó 7 días de datos y la cola se atascó con solicitudes viejas
- Si lo hubiéramos dejado correr normalmente, procesar todos los datos habría tomado más de 100 horas y la latencia de los datos nuevos también se habría disparado
- La solución fue purgar manualmente la cola y volver a cargar manualmente los datos recientes faltantes
Hay que tener cuidado con el tamaño no acotado de las colas, pero sigo pensando que es una gran herramienta

rossdavidh

MQ está en el Gartner Hype Cycle
- Ya pasó el 'Peak of inflated expectations'
- Ya pasó el 'trough of disillusionment'
- Y va rumbo al 'Slope of Enlightenment' o incluso al 'plateau of productivity'

robertclaus

Es muy interesante que el comentario de "claramente todos seguimos usando colas de mensajes y workers, simplemente ya no escribimos sobre eso" quede enterrado por las discusiones sobre microservicios y escalabilidad real
Un ingeniero junior que lea este hilo podría quedarse con la impresión equivocada de que ya no conviene descargar el trabajo pesado del servidor web a workers

pm90

Hay menos posts de blog sobre esto porque la tecnología se volvió aburrida
Y eso es bueno. Por ejemplo, la documentación oficial de RabbitMQ ahora es mucho mejor y muy útil
La gente la usa como usa Postgres/MySQL
Ni siquiera se necesita una tecnología sorprendente para diseñar la arquitectura, etc.
Amo el software aburrido: "I love boring software"

slowmovintarget

La mayoría de estas arquitecturas corrían en centros de datos empresariales
Tras la migración a la nube y la creación de pequeños servicios stateless (con la llegada de las SPA), se volvió menos necesaria la compleja lógica de sistemas orientados a eventos por etapas
Por ejemplo, en AWS basta con usar SQS y un poco de SNS, o Kinesis para unas cuantas cosas. Ahí MQ ya no está en el centro del diseño
Las arquitecturas basadas en MQ son buenas para procesamiento de datos, pero no para sitios web interactivos; y si la mayoría de la gente construye sitios web interactivos, la elección parece obvia
Yo todavía diseño sistemas de eventos para procesamiento de datos (sobre todo cuando hay hechos nuevos pero también datos de negocio inmutables donde antes se sabía otra cosa o había información "incorrecta")
Pero en la mayoría de las apps... no hace falta

mannyv

Todo nuestro backend está basado en colas
Si algo es asíncrono y no requiere tiempos de respuesta rápidos, usa una cola. Es fácil, confiable y la cola puede disparar lambdas
Además, las colas facilitan recopilar métricas y datos de rendimiento.
- Cuando hay mucha carga, la cola puede crecer hasta millones de mensajes y luego bajar con el tiempo,
- o también puedes lanzar cientos de lambdas si quieres procesar todos los mensajes

vishnugupta

Según mi experiencia, MQ se abstrajo, no desapareció
Por ejemplo, las colas con SQS + polling se transformaron en procesos que llaman menos al servidor. La cola de mensajes sigue ahí en alguna parte, solo que ya no está expuesta
AWS SNS, que está un nivel más abstraído que SQS, se volvió tan rico en funcionalidades que en la práctica puede reemplazar a SQS
Además, el streaming se volvió una tecnología muy estable, así que los casos de uso que usaban colas como pipeline de streaming migraron a streaming dedicado

memset

Puede deberse a que lambda (cloud functions) se volvió más popular y ya tiene soporte en varias plataformas
Si agregas algo a una cola, al final alguien tiene que sacarlo y procesarlo. Una lambda hace eso en una sola invocación. Además, ya no necesitas correr ni escalar workers
Creo que Kafka sigue siendo popular porque se usa como almacenamiento temporal de datos y porque tiene un gran ecosistema para consumir streams
Yo personalmente uso mucho las colas y estoy construyendo una alternativa open source a SQS. También me pregunto si sería útil una alternativa open source a lambda

liampulles

"La tecnología MQ ya entró en una etapa de madurez, así que ya no resulta lo bastante interesante como para que la gente escriba sobre ella. Pero sigue usándose ampliamente"
- Sí, eso es correcto. Creo que los casos simples de comunicación asíncrona usando mensajería Pub/Sub simple son muy útiles y no tan difíciles de usar
Nosotros (como comunidad de desarrolladores) ya superamos el event sourcing, las redes complejas y la construcción a escala innecesaria. Es decir, ya pasamos el ciclo del hype
Nuestro equipo usa NATS tanto para Pub/Sub asíncrono como para Request/Response síncrono
- Es un modelo basado en comandos y tenemos una enorme tabla de logs con todos los mensajes que enviamos
- El esquema y el uso de esos mensajes son internos del equipo y se eliminan de NATS después de usarlos
- Hacemos at-least-once delivery y esperamos que los handlers de mensajes sean idempotentes
Tuvimos uno o dos problemas por configuraciones incorrectas de NATS que provocaron replay o pérdida de mensajes, pero en general ha sido muy exitoso y éramos un equipo de 3 desarrolladores
En mi opinión es como Kubernetes. Si te quedas con lo básico y no intentas ser demasiado listo, funciona bien

11 comentarios

finnchoi 2024-06-25

Hay situaciones adecuadas en las que se necesita una cola. Sin embargo, para la mayoría de las escalas y formas de uso, usar una cola o hacerla funcionar formando un clúster suele aumentar la complejidad y, en términos de rendimiento, muchas veces no ofrece grandes ventajas. Puede que nunca llegue el momento en que esas estructuras complejas de las que presumen las grandes empresas, diseñadas pensando en escalabilidad y grandes volúmenes de datos, sean realmente adecuadas para mi sistema.

Aunque las nuevas tecnologías atractivas y las arquitecturas sofisticadas resulten técnicamente llamativas, es necesario pensar en los problemas reales y elegir una solución adecuada. En la mayoría de los casos no hay tantos datos por procesar, y muchas veces PostgreSQL es suficiente.

Nosotros reconocemos este problema y estamos desarrollando una base de datos capaz de procesar datos a escala de TB en un solo nodo con una arquitectura simple. Lo digo con algo de cautela, pero les recomiendo considerarlo como otra opción.
Cómo dejar los datos de jurisprudencia en un estado que permita búsquedas rápidas

dakbutfly 2024-06-24

En general, la programación procedimental es fácil de entender, pero el enfoque con MQ no se asimila de inmediato o puede resultar difícil comprender su estructura. En las empresas, muchas veces el nivel de conocimiento no es el mismo entre todos, y en esos casos, si se usa MQ con conocimientos equivocados, parece que se convierte en un infierno.

Creo que este problema no ocurre solo con MQ, sino con la mayoría de las tecnologías que requieren cierto nivel de conocimiento cuando se aplican sin una formación adecuada en términos generales.

nemorize 2024-06-21

PHP hace que una MQ sea prácticamente indispensable...

halfenif 2024-06-21

¡Qué golpe!

Justo ahora estoy trabajando en un toy project que lleva Quee en el nombre.

kandk 2024-06-21

Sinceramente, creo que si el servicio va a operar 99% solo dentro de nuestro país, nada de eso hace falta..

superwoou 2024-06-21

¿No será más importante que el alcance del servicio considerar la naturaleza del servicio y cuánto hay que evaluar la eficiencia de costos?

2024-06-21

[Este comentario fue ocultado.]

bus710 2024-06-22

¿Será que, como el proceso para tomar decisiones tiende a ser vertical, se prefiere o se considera más adecuada una opción más “procedimental”?
Si cada departamento y equipo estuviera organizado de forma flexible, me pregunto si una arquitectura menos procedimental podría funcionar con más fluidez y, por eso, también podrían funcionar mejor las aplicaciones de estas colas.

savvykang 2024-06-21

Parece que el desarrollo guiado por el currículum es la palabra clave que atraviesa este tipo de fenómenos de moda.

hyeonseokoh94 2024-06-22

Vaya, qué frase tan genial: desarrollo guiado por el currículum...

savvykang 2024-06-23

Como producto relacionado, también está el desarrollo impulsado por el hype.