weavenetwork

@wmf, with respect, it's not garbage and actually works well for many cases. At the same time, it is quite possible to see ways to integrate weave with kernel features! We welcome your input and help on that -- why not get in touch? weave@zett.io

Weave is also topology agnostic - see the explanation vs Flannel (formerly "Rudder") here http://www.infoworld.com/article/2608941/application-virtual...

I think VPN is a use case for SDN. Weave is fundamentally a software network that provides a virtual switch at layer 2.

The most significant conceptual difference is that in rudder sub-nets are tied to hosts. So containers on different hosts will always be on different sub-nets. By contrast, in weave containers belonging to the same application reside in the same sub-net, regardless of what host they are running on. In other words, weave makes the network topology fit the application topology, not the other way round.

We are certainly aware of consul, and have indeed been thinking of weaving weave into it. Would love to see an experiment along those lines, if there are any volunteers.

> complex tricks with the existing network stack

To retain the essence of how weave operates, this would likely not just be complex but impossible, short of kernel hackery.

> you would really only need to do processing at the beginning of a connection and for some ARP request

Weave needs to look at every Ethernet packet. Well, the headers at least. It's a virtual Ethernet switch. It doesn't even really know about IP, let alone TCP streams. See https://github.com/zettio/weave#how-does-it-work

Weave itself does not provide addressability beyond IP. That is the situation now, but this area is very much high on the agenda for us - service discovery is definitely in scope for weave.

Meanwhile, two points of note:

1) In weave the IP addresses can be much "stickier" than in other network setups, i.e. a moving a container from one host to another can retain the containers IP. That means it is quite amenable to relatively static name resolution configurations, e.g. via /etc/hosts files.

2) Since weave creates a fully-fledged L2 Ethernet network between app containers, name resolution technologies like mDNS that rely on multicast should work just fine.

So, in summary, while weave currently does not have any built-in service discovery, existing solutions and technologies for that should be relatively easy to deploy inside weave application networks, until weave itself grows these capabilities.

re benchmarks...publishing some is on the TODO list. See https://github.com/zettio/weave/issues/37. Informally, weave is pretty fast but it's not saturating Gbit Ethernet. As you say, capturing with pcap and handling packets in user space carries an appreciable overhead.

We've got some issues filed to look at pcap alternatives and also generally aim to improve performance.

re suitability for NoSQL clustering... depends on where the bottlenecks are; if you want to cluster for HA rather than scale, i.e. there aren't any real bottlenecks, then weave will work well. Same if you want to cluster because of CPU or memory bottlenecks. If, otoh, networking is the bottleneck then adding weave into the mix isn't going to improve matters.

TCP and UDP is all you need. (And the UDP can actually be quite broken, just not completely)

We've created weave networks spanning hosts on EC2, GCE and local data centres.

Just having a look at Tinc.. one difference is completely non-technical - Tinc is GPL but Weave is Apache licensed so aligns better with the whole Docker ecosystem. More comments to come.

It is definitely changing fast, but that is not a reason to wait before trying out the technology in order to learn about it. If nothing else, the community will welcome your feedback :-)