My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
Yeah, it's definitely overkill for his scope. Nonetheless, it's a viable solution that can easily grow if the project grows.
About your question, yes using message queues it's actually a fairly old solution when dealing with multiple intercommunicating services. Think about old approaches like Enterprise Service Buses or Java JMS specification.
In a microservice environment, it's actually a really solid solution because it adds a layer of abstraction (the message broker itself) between loosely coupled services and allows for fully asynchronous communications.
Remember, a cloud environment should be error-resilient and services must fail gracefully and not take down the whole application if one of them dies. With message queues if a microservice dies unexpectedly the broker can still receive incoming messages, store them for later (so that the dead service can recover them when it comes back online) and optionally send back a Last Will and Testament message to the other service saying that the receiver has died. Also, Push/Pull, Publish/Subscribe and Topic queue mechanisms give more flexibility and efficiency when designing inter-service communications, and the ability to send binary payloads allow for easy use of formats like Google ProtoBuff or MessagePack instead of JSON, which are much more efficient in terms of bandwidth usage.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
Yeah, it's definitely overkill for his scope. Nonetheless, it's a viable solution that can easily grow if the project grows.
About your question, yes using message queues it's actually a fairly old solution when dealing with multiple intercommunicating services. Think about old approaches like Enterprise Service Buses or Java JMS specification.
In a microservice environment, it's actually a really solid solution because it adds a layer of abstraction (the message broker itself) between loosely coupled services and allows for fully asynchronous communications.
Remember, a cloud environment should be error-resilient and services must fail gracefully and not take down the whole application if one of them dies. With message queues if a microservice dies unexpectedly the broker can still receive incoming messages, store them for later (so that the dead service can recover them when it comes back online) and optionally send back a Last Will and Testament message to the other service saying that the receiver has died. Also, Push/Pull, Publish/Subscribe and Topic queue mechanisms give more flexibility and efficiency when designing inter-service communications, and the ability to send binary payloads allow for easy use of formats like Google ProtoBuff or MessagePack instead of JSON, which are much more efficient in terms of bandwidth usage.
Very interesting thoughts, thank you ;-)
You gave me the idea to write a dedicated post about my experience with queues and RabbitMQ. Could be interesting, thanks to you :D
Please do it and let me know when it's finished!
Would love to hear about it too.
After a lot of time, I finally published it :D Please share your thoughts, I'd love to know what do you think.
dev.to/matteojoliveau/microservice...