

Docker libswarm - fredkelly
https://github.com/docker/libswarm

======
shykes
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 library called libchan:
[https://github.com/docker/libchan](https://github.com/docker/libchan)

~~~
kansface
How does libswarm compare to etcd/fleet?

~~~
shykes
The author of Fleet have started contributing a Fleet adapter :)

libswarm exposes a standard interface to systems like Fleet, Mesos, Consul
etc. It also has adapters for popular infrastructure providers, and for the
Docker API itself. That way you can compose your architecture from standard
building blocks, and change the building blocks over time without being locked
in.

There was huge demand for this in the Docker system because there are _so
many_ orchestration tools being announced and competing for the attention of
developers and sysadmins. Just at Dockercon, New Relic announced "Centurion",
Spotify announced "Helios", Google announced "Kubernetes". Having a standard
interface allows for these tools to continue competing without the risk of
fragmentation and lock-in.

Of course the interface has to be thin enough to not get in the way. That's
why we're focusing on keeping the codebase small, and the API as simple as
possible.

------
shykes
We introduced libswarm at Dockercon today, along with a few other projects.
Here is the presentation: [http://www.slideshare.net/shykes/docker-the-road-
ahead](http://www.slideshare.net/shykes/docker-the-road-ahead)

~~~
tlrobinson
Will videos of Dockercon talks be posted?

~~~
akerl_
They did confirm this morning that videos and slides will be posted. I've not
heard where/when that will happen.

------
dominotw
> Organize your application as loosely coupled services from day 1, without
> over-engineering.

Seems a little counterintuitive

~~~
shykes
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](https://github.com/docker/libchan)

~~~
moe
What if most of my services are not written in Go?

What if most of my services (postgres, redis, etc.) are not even written by
myself?

~~~
shykes
1: We plan on porting libswarm to every major language.

2: The idea is to use socket passing, so you can use libswarm for service
discovery. Place your postgres service behind a libswarm proxy, which
implements the "connect" verb: that allows a client to use libswarm for
discovery.

------
ndyg
What does libswarm offer over unix sockets?

Is the idea for the project to be a rallying point to normalize protocols for
different services that already talk over unix sockets?

------
philwhln
Blog post interview with Mr Hykes on libswarm can be found here
[http://bit.ly/libswarm](http://bit.ly/libswarm)

