HTTP and microservices

Posted Apr 12, 2017 9:29 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: HTTP and microservices by ssmith32
Parent article: Connecting Kubernetes services with linkerd

His analogy is a bit odd, but he's pinpointed a real problem - a distributed system can very well exhibit vicious loops caused by its own resiliency algorithms. A some sort of external overarching overseer system that can suppress them is really needed.

It has no real bearing on RESTfulness vs. classic RPC. I've seen retry-driven meltdowns in very REST-ful share-nothing microservice-based systems.

HTTP and microservices

Posted Apr 13, 2017 6:46 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

Ah ok, I watched the video from the point linked to, and until my next stop on the train. I guess if you're worried about some vicious loops... maybe?

I've never really seen *vicious* loops in prod systems. And the loops I've seen certainly never been worth tying your architecture to something like a service bus. Just dumb mistakes. I have seen a vicious loop relying on a subsystem of a generally restfulish system that had a daemon pulling a corrupted message off rabbit, failing to route the message (because it was corrupted) then some lame spring lib used in the component just put the message back, to be "transactional", pulled the same message back off again...Yeah.

To top it off, this is in a system where we can lose a message here and there and it's fine.

The reason given for the logic was "well then the rabbit queue backs up until it triggers an alert, and someone has to manually delete the message, so it's a *good* design, because it alerts us to corrupted message!". Instead of, I dunno, just alerting on corrupted messages??

Little poop emojis, and vicious cycles, that I've seen, are not solved by some grand design. They're solved by limiting the poop in your implementation of a design.

Thanks for the clarification, though, at least I get the logic, even if I disagree.