HTTP and microservices

Posted Apr 12, 2017 3:22 UTC (Wed) by ssmith32 (subscriber, #72404)
In reply to: HTTP and microservices by fratti
Parent article: Connecting Kubernetes services with linkerd

I watched a little bit of the video - since the link started in the middle.
And how does he justify this statement? Particularly with respect to the web?

And given that he basically pitches the Enterprise Service Bus as the alternative model, I'm not sure why anyone should care? We should run the Web as a distributed app on top of some global queue. The world wide Rabbit?

Every place I've been at that went for tightly coupled services joined over something like thrift, etc,... let's just say there are areas of regret. It is needed in some places, but http and trying to be RESTful (I haven't seen anyone succeeded, but trying helps), is a vastly better place to start than tightly coupled protocols and IDL's.

It is by no means perfect, but the Web is an amazingly successful distributed system, and you need a little more than a diagram with little poop emojis to present a credible argument against following in it's footsteps.

HTTP and microservices

Posted Apr 12, 2017 9:29 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

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.