docker.libchan

Perhaps not exactly what you/they are referring to. But this is interesting: https://github.com/docker/libchan

Docker is currently switching to their own microservices library called libchan - https://github.com/docker/libchan It is msgpack over SPDY+TLS. Every language that will want to talk to docker will need a libchan implementation eventually. disclaimer: I'm the co-founder of the project to build the node.js version: https://github.com/graftjs/jschan My actual goal is to pull this into the browser though, and figure out what we can do with that : https://github.com/GraftJS/graft Until that is ready though, we have already built out our own microservices 'toolset' that does the [1] docker based deployment, and a small library that handles the [2] REST API, and that handles the [3] logging to logstash/kibana 1. http://longshoreman.io 2. https://github.com/wayfin/waif 3. https://github.com/wayfin/dockstash

I think microservices is a new evolution of an old idea, that is growing to term in an environment that could allow it to blossom. As I posted elsewhere here, microservices are also explicit about being remote calls, and are built with the idea of assuming all your calls are always remote. For instance, Docker is already built using a microservice architecture, and they are standardising that as a project called LibChan : https://github.com/docker/libchan It's basically msgpack over SPDY+TLS, all the way down the stack. disclaimer: I am one of the co-founders of jsChan, the node.js/javascript port of libchan. https://github.com/GraftJS/jschan

The README looks interesting, but with zero API documentation, it is just a curiosity; see https://godoc.org/github.com/docker/libchan for how this package looks to GoDoc. Usage information and context is essential for encouraging other developers to adopt a dependency and start returning contributions.

This alludes to the fact that you can do this within the same process, simply by running goroutines and communicating over Go channels. Later, when you actually need to scale, your services already support the interface necessary to be exposed over unix sockets, websocket or spdy/tls: you just need to change the plumbing. To do this we take advantage of a low-level communication library called libchan: https://github.com/docker/libchan

Hi all, a quick warning: this is very rough and early, and not yet ready for production use. What we're aiming for is Unix-style composition. Because libswarm services communicate over unidirectional message streams (similarly to how goroutines communicate over channels [1]), they can be combined in a way similar to unix pipelines. This makes composition much easier, and is an elegant solution to the problem of hardcoded dependencies in service-oriented architectures (for service A to combine service B a C, it needs to know specifically B and C. Instead what you want the logic of A to be decoupled and re-usable with another component D, without changing it. That's what unix-style composition allows). TLDR: libswarm allows network services to be composed like unix commands. But it's still very early! [1] libswarm is built on a small librar