Hoy en dia hay muchas alternativas open source y plug and play para hacer eso, aunque supongo que con amazon te ahorras hacerlo auto escalable. Pero me parece bastante costoso...
Tanto SNS como EventBridge son servicios muy buenos. Pero si quieres una solución integral para eventos lo más fácil sería EventBridge. Tiene features muy chulas, como por ejemplo lo que mencionó Rafa, el reply de los eventos. O sea, a medida que vas publicando eventos EventBridge los guarda y luego puedes "republicar" esos eventos desde EventBridge, lo que puede ser muy útil cuando conectas nuevos servicios y necesitas recolectar datos.
Cual sería la desventaja (ya que ni se plantea de ejemplo en el video) de conectar ya sea sns o event brigde directamente con lambdas sin pasar por sqs?
La principal desventaja de no anteponer una cola SQS antes de una lambda, es que si se generan demasiados eventos en un instante de tiempo especifico, y tu lambda no es capaz de procesarlos, entonces perderas eventos. Para solucionarlo tendrias q administrar la concurrencia de tu lambda y eso tiene un mayor costo. A diferencia de que si usas un SQS, entonces esta cola se encarga de "guardar ordenadamente TODOS los eventos" y se los va entregando a la lambda de forma ordenada a la velocidad que ella sea capaz de procesar. Normalmente esta estrategia es mas economica en hablando de dinero, asi como en la complejidad de la infraestructura (debes pensar q si ocurren 2 eventos "simultaneos" en los q se debe editar el mismo campo en la base de datos, tendras que considerar dichos casos en tu codigo de programación dentro de la lambda, sin embargo con SQS eso jamas pasará).
En el caso de SNS, por ejemplo, ¿qué aproximación recomendaríais? ¿Un topic por cada tipo de mensaje o un topic por cada contexto (si no me equivoco, este es el escenario que comentáis en el vídeo generalizando todos los eventos como domain_events)? Gran trabajo, chicos 👏
El topic es el message/event broker. Entonces, todos los mensajes o eventos se publican en el topic y se distribuyen a las diferentes colas. Además, como message/event broker, puedes conectar múltiples servicios/microservicios (incluyendo servicios/microservicios que no pertenecen al mismo equipo y a la misma compañía).
no hay una recomendación fija para esa pregunta, ambas estrategias funcionan exactamente igual. sin embargo en mi experiencia, esq mantener tantos topicos a nivel de infraestructura es costoso respecto a codigo y mantenibilidad. en cambio 1 solo topic para todos los eventos es mas simple de mantener, sin embargo tienes muchisimos tipos de mensajes en el mismo topico. Otra recomendación tiene q ver con la seguridad, quizas hay eventos q quieres q reciban sólo algunos equipos, entonces los puedes separar en 1 topic aparte y agregarle las politicas necesarias para que solo quien tu decidas se pueda suscribir a estos eventos mas "privados"
yo lo uso todo a la vez xd. Yo diria que no siempre uso sqs con sns y event bridge, a veces llaman directos a lambda. Supongo que me faltara contexto del video, o tengo la cabeza hecha un lio puede ser de tantos productos que tiene AWS
@@andrescolina8288 bueno en mi caso si necesito event, tengo muchas cosas diferentes pero si el mensaje viene de servicios de Amazon necesito el event bridge para ciertos asuntos, hay tantas opciones
Hoy en dia hay muchas alternativas open source y plug and play para hacer eso, aunque supongo que con amazon te ahorras hacerlo auto escalable. Pero me parece bastante costoso...
Más contenido de AWS y serverless porfa 🙏
Tanto SNS como EventBridge son servicios muy buenos. Pero si quieres una solución integral para eventos lo más fácil sería EventBridge. Tiene features muy chulas, como por ejemplo lo que mencionó Rafa, el reply de los eventos. O sea, a medida que vas publicando eventos EventBridge los guarda y luego puedes "republicar" esos eventos desde EventBridge, lo que puede ser muy útil cuando conectas nuevos servicios y necesitas recolectar datos.
Cuidado, entonces es un replay, no un reply. Reply sería poder responder a los eventos
@@boscodomingo Sí, sí. Tienes razón. Gracias por la corrección.
muy buen video! ¿con que hicieron esa presentacion animada?, muy buena!
Muy bien video, podrías hacer comparaciones pero con tecnologías para procesamiento de datos , cómo cuando usar lambda , vs glue vs emr
Cual sería la desventaja (ya que ni se plantea de ejemplo en el video) de conectar ya sea sns o event brigde directamente con lambdas sin pasar por sqs?
La principal desventaja de no anteponer una cola SQS antes de una lambda, es que si se generan demasiados eventos en un instante de tiempo especifico, y tu lambda no es capaz de procesarlos, entonces perderas eventos. Para solucionarlo tendrias q administrar la concurrencia de tu lambda y eso tiene un mayor costo. A diferencia de que si usas un SQS, entonces esta cola se encarga de "guardar ordenadamente TODOS los eventos" y se los va entregando a la lambda de forma ordenada a la velocidad que ella sea capaz de procesar. Normalmente esta estrategia es mas economica en hablando de dinero, asi como en la complejidad de la infraestructura (debes pensar q si ocurren 2 eventos "simultaneos" en los q se debe editar el mismo campo en la base de datos, tendras que considerar dichos casos en tu codigo de programación dentro de la lambda, sin embargo con SQS eso jamas pasará).
@@JorgeNocourBlanco super claro jorge, ahora entiendo, gracias!
Gracias cucurela!!
En el caso de SNS, por ejemplo, ¿qué aproximación recomendaríais? ¿Un topic por cada tipo de mensaje o un topic por cada contexto (si no me equivoco, este es el escenario que comentáis en el vídeo generalizando todos los eventos como domain_events)? Gran trabajo, chicos 👏
El topic es el message/event broker. Entonces, todos los mensajes o eventos se publican en el topic y se distribuyen a las diferentes colas. Además, como message/event broker, puedes conectar múltiples servicios/microservicios (incluyendo servicios/microservicios que no pertenecen al mismo equipo y a la misma compañía).
no hay una recomendación fija para esa pregunta, ambas estrategias funcionan exactamente igual. sin embargo en mi experiencia, esq mantener tantos topicos a nivel de infraestructura es costoso respecto a codigo y mantenibilidad. en cambio 1 solo topic para todos los eventos es mas simple de mantener, sin embargo tienes muchisimos tipos de mensajes en el mismo topico.
Otra recomendación tiene q ver con la seguridad, quizas hay eventos q quieres q reciban sólo algunos equipos, entonces los puedes separar en 1 topic aparte y agregarle las politicas necesarias para que solo quien tu decidas se pueda suscribir a estos eventos mas "privados"
Gracias chicos👌
y amazon mq que seria? como sqs?
yo lo uso todo a la vez xd. Yo diria que no siempre uso sqs con sns y event bridge, a veces llaman directos a lambda. Supongo que me faltara contexto del video, o tengo la cabeza hecha un lio puede ser de tantos productos que tiene AWS
Si tienes un mensaje que solo lo escucha 1 cola no hay necesidad ni de sns ni event bridge solo en este caso
@@andrescolina8288 bueno en mi caso si necesito event, tengo muchas cosas diferentes pero si el mensaje viene de servicios de Amazon necesito el event bridge para ciertos asuntos, hay tantas opciones
La otra alternativa dentro de AWS es el Kinesis.
¿Como así? Si acabo de ver el vídeo en LinkedIn y Rafita tiene corte de cabello nuevo 😮
pues a mi me parece un punto super negativo que eventbridge no garantice el orden de los mensajes😮
Por qué se pone pelucas? igual me he perdido algo
Service no System
Iba a decir lo mismo