3 ms·
We have an abstraction library at work we plan to release in coming weeks (although we've been saying that for a year now) called "drumbeat". We have libraries
by PaulRobinson 9y ago
We have an abstraction library at work we plan to release in coming weeks (although we've been saying that for a year now) called "drumbeat".
We have libraries in Ruby, Go and Java, and the concept is that developers should not have to worry about transports or how they work: you make it as simple as possible for most developers in the org to work with distributed systems, and they'll start working with distributed systems, and the arcane understanding of exactly what the trade-offs are between different vendors and messaging technologies can be centralised to a few devs with ops support instead of it being bikeshedded to death.
This is nice in that it becomes scalable and transparent with little refactoring in Go, but having multi-language support is useful, otherwise we'd probably drop drumbeat and use this instead.
It does suggest we should think about how best to do this in Go again though - I like the pattern a lot.
- lobster_johnson 9y agoHow does this compare to, say, gRPC? One of the ideas in the gRPC space is that the protocol, at the client and server level, is always plain HTTP/2 and DNS. To do discovery (that is, find the IP of a peer), load balancing, routing, retrying, throttling, circuit-breaking etc. you inject a proxy such as Istio [1] in the middle that modifies the connection with all the necessary intelligence. This way, the app stays super simple -- it needs no configuration. If it wants to talk a service called "foo", it just naively dials http://foo/ http://foo/ and does gRPC. If you write lots of apps in different languages, they only need the gRPC client/server glue, nothing else. [1] https://istio.io/ https://istio.io/