5 ms·
I've pretty much faced all of the problems mentioned in this article. An application is set of services with a certain complexity that work together. In some ca
by mavdi 12y ago
I've pretty much faced all of the problems mentioned in this article. An application is set of services with a certain complexity that work together. In some cases this complexity just gets transferred from service level to orchestration level.
Don't get me wrong, I love microservices and will try to use them in all my future work, but I think where people often go wrong is that they over commit to it without realising the downsides. I often see people casually using AMQP queues for pretty much everything, only when they need the worker service to talk back to the originating service that they realise they've made a wrong architectural decision.
- muffs 12y agoCan you elaborate on your latter point? Why is that considered an incorrect architectural decision?
- marktangotango 12y agoFor example if the caller needs the result of a possible long running task, ie success or fail, then it has to maintain state in a way to associate the async queue message back to the task. Zeromq has the concept of request/reply to handle this, its more problematic with plain old queues, the solution ive worked with is mq for tasks, rest calls for results. Yes it sucks.
- muffs 12y agoAwesome, thanks for the explanation.
- icedchai 12y agoI worked with some guys once who put every HTTP REST request in to AMQP. And every response. There were temporary queues all over the place to allow for communication between the front end and back end servers. It was a complete joke of a system.