
Weave and Docker for Mac: The bridge between local and remote services - hiphipjorge
http://blog.runnable.com/post/142665542481/weave-docker-for-mac-the-bridge-between-local
======
zeveb
Why not just run Linux locally? Mac OS X is BSD, not Linux, which means its
build tools & environment are subtly incompatible. You're always going to be
chafing if you develop anywhere other than in your deployment environment.

Linux is superlative for desktop & development use. It supports things like
tiling window managers far better than does a Mac. It's free. The hardware is
far more affordable. Although this is definitely a matter of taste, I find
Linux far more _usable_ than a Mac. I will grant that Mac laptops are
lightweight & thin.

It just seems weird to me to go through all these contortions to develop
software for Linux on a Mac or Windows box when it's far easier IMHO to just …
run Linux.

~~~
falcolas
I love Linux, but saying that the desktop use is "superlative" is a bit, let
me don my fire retardant suit, wrong. It's a decent enough desktop system, but
it falls markedly behind in terms of tooling.

There's simply a large number of high quality tools which are not available
for Linux, which means that you have to resort to an open source tool which,
while decent (and sometimes even fantastic), are still nowhere near the
quality of many closed source tools.

I wish this would change, and I do what I can to make it change, but the
simple reality is that depending on the tools you want to (or need to) use,
Linux is behind the game.

That said, I agree wholeheartedly with your very first statement: Why not just
run Linux locally? Except, I would recommend a local VM. Best(ish) of both
worlds.

~~~
crdoconnor
>There's simply a large number of high quality tools which are not available
for Linux

Developer tools? Like what?

~~~
falcolas
Visual Studio, XCode, Adobe <insert product here>, anything by Autodesk...

As good as alternatives like GIMP are, they simply can't compete with their
Mac/Windows alternatives like Photoshop.

~~~
cmiles74
Both XCode and VisualStudio are proprietary IDEs designed to support building
apps for their respective operating systems. If you're writing a Windows
native application, you will find Visual Studio on Windows to work the best,
likewise if you're developing a Mac OS X native application then XCode on OS X
is the smart choice.

In my opinion, neither one is well suited for building a native Linux
application nor the sort of applications that would need a Docker container in
which to run (web application, etc.)

~~~
falcolas
XCode has a fantastic interface for writing Swift, which is no longer specific
to Apple hardware. It also has a decent (if not fantastic) IDE for basic C and
C++ development. Visual Studio has some great plugins for not only generic C
and C++ development, it also has great integrations available for JavaScript
and Python (which many developers prefer to use over even JetBrains fantastic
cross-platform offerings).

If you look at Go, Python, and Ruby web development, there is nothing special
about the Linux environment that these programming languages do not provide
built-in solutions to. Sockets, file handles, threading and process management
are all abstracted to the level that you can run the same code on Windows,
Mac, and Linux.

So, in _my_ opinion, it comes down to which OS you enjoy the most for your
development work; you can make any of them work for whatever type of
development you want to do (particularly something as high level as web
development).

------
cjbprime
> sudo curl -L git.io/weave -o /usr/local/bin/weave

Do you want ants? Because that's how you get ants.

~~~
api
But it redirects to https. That's secure, right?

~~~
cjbprime
It redirects to HTTPS when you _aren 't_ being MITM'd with malware..

------
NetStrikeForce
Hey,

We provide an alternate solution ([1]Wormhole) that covers this scenario (and
others). The main differences with e.g. Weave are:

\- Non Docker-specific

\- Easier to deploy, in my opinion ofc :-)

\- Based on Open Source (You can just deploy SoftEhter's vanilla client as the
agent)

\- We don't use vxlan, just SSL encapsulation.

\- Actually, every client will only generate outbound SSL connections, so
chances are you won't need to reconfigure any firewalls or network gear for
Wormhole to work.

\- By default, chances are you won't overlap with the provided IP addressing
(non-public, non-RFC1918 IP space)

\- Multiplatform Windows / Linux / Os X

\- API available to create and deploy networks and clients

\- Our architecture requires traffic to go up to a central server and down to
destination, so there's added latency. In my tests I've found this to not
penalise performance for most applications as other solutions based on extra
layers (I.e. Vxlan) like Weave.

Don't get me wrong, I think Weave is brilliant. We're just an alternative that
aims for simplicity. There's some overlapping, but we probably have different
markets.

[1]: [https://wormhole.network](https://wormhole.network)

------
zephod
Offtopic, but does anybody know how the diagrams in this article were
generated? I'd love a simple piece of software to generate beautiful,
straightforward pictures like this to explain architectural problems.

~~~
ncke
I don't think that it generated these diagrams, but you should check out
planttext ([http://www.planttext.com/](http://www.planttext.com/)) - makes UML
diagrams easy.

------
fabiofumarola
Why do you need to connect to remote services using weave? Should the stage
environment be separated from you development one? Anyway nice article. Thanks

~~~
kernel_panic
We have around 18 different microservices each with their own configuration
and repos. Setting them all up, keeping them up to date and managing them
locally is a pain (and also turns my laptop into an inferno). Our staging
environment is on Runnable which spins up all 18 of these in an isolated stack
so I do no have to worry about configs or management.

------
simonebrunozzi
I dream of a company that installs Linux on some of the most popular desktops
PROPERLY, and charges users 100$ to install it, and helps you maintain your
Linux desktop over the years.

Many have tried, no one has succeeded.

Canonical had an opportunity to do this... Instead, they had to do
"Enterprise" stuff. Bah.

------
antman
HN discussion about Weave being slow [0]. I dont know if the issue has been
addressed since it was first posted.

[0]
[https://news.ycombinator.com/item?id=9498139](https://news.ycombinator.com/item?id=9498139)

~~~
fons
It has, now Weave is kinda fast :)

See [http://weave.works/weave-docker-networking-performance-
fast-...](http://weave.works/weave-docker-networking-performance-fast-data-
path/)
[http://rp.delaat.net/2015-2016/p50/report.pdf](http://rp.delaat.net/2015-2016/p50/report.pdf)

Full disclosure: I work at Weaveworks

~~~
DanielDent
It's terribly slow unless you don't care about encryption:
[https://github.com/weaveworks/weave/issues/1925](https://github.com/weaveworks/weave/issues/1925)

The per-packet processing overhead is a real and unresolved problem.

I'm using Rancher's networking now instead. It uses ipsec between hosts, so
everything gets handled by code paths which have been optimized in the kernel,
and performance is good (especially if you have a not-ancient CPU and have the
AES-NI instruction - then wirespeed gigabit works with acceptable overhead).

I like Weave's decentralized architecture and wish it were realistic to use
it.

If they are going to stick with a user-space solution they probably need to
use DPDK or one of the other high-performance software defined networking
toolkits, which tend to process packets using a SIMD approach.

~~~
__monadic
(weaveworks person here)

If you check out the PDF that fons posted above,
[http://rp.delaat.net/2015-2016/p50/report.pdf](http://rp.delaat.net/2015-2016/p50/report.pdf),
then you will see pretty extensive testing showing that Weave Net, flannel,
and Docker Networking have similar VXLAN performance for unencrypted traffic.
In all cases, it is good enough. Alas the testers were unable to get Calico
working.

The question is: when do you want top performance for encrypted traffic? Most
of users want encryption for the wide area or public cloud, and when they
can't use a VPC. Our solution is pretty good for these cases. Obviously at
some point we'll enable IPSEC too.

~~~
DanielDent
Widearea/public cloud & non-VPC use cases are my use cases.

I really wish this weren't true, but your solution is not pretty good yet. For
now, if you need encryption, it's useless.

Machines spend their life handling packet overhead. Application performance
suffers horrendously, and the scalability of the application goes from
excellent to terrible.

Weave looks really good if you give it easy tests involving big packets. But
if you give it a workload involving many small packets (which in today's
microservices architectures is not exactly uncommon), it stops working.

~~~
__monadic
What is a small packet here?

------
dmritard96
Must admit I thought this was the weave framework google/nest are pushing.

