errordeveloper

Userspace networking had been around for quite a few years, yet didn't seem to have taken off, despite all the great benchmarks... I think the main blocker is that you cannot make apps use it without hacks. It looks like Snap requires a custom library that probably doesn't even have to implement BSD sockets, since that's something you don't have to care about at Google.

Some years ago I recall looking into this, and it looked kernel had limitations in higher speed ethernet (must had been 50GbE at the time), and it came down to single-threaded nature of the TCP/IP stack in the kernel at the time. So that's been one of the drivers for experiments in userspace. Looks like that might now be the case now [1], but if someone has more specific info I'd be quite curious to hear.

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...

Not everyone had the same experience.

There a few minor UX flaws that make it frustrating to use, e.g. having to set Docker host, shared filesystem performance is poor, networking in enterprise desktop environment is broken (just to name a few top most issues).

Also, a lot of folks end up running Docker for Mac and minikube VMs, why should they have to run two VMs?

Additionally, minikube is completely different from production-grade deployments (single binary, which means a rewrite of main function for etcd and all control plane components, as well as hard to debug basic performance issues in control plane, there is one large process and you don't know what is wrong, also there is no way to use your favourite network add-on).

Additionally, minikube is based on legacy Docker libmachine, it is not really maintained anymore.

It will be possible to run all your add-ons in the local setup, including networking. Multi-node is essential for some use-case, but arguably is not critical for most people, yet it is coming in the future.

At Weaveworks, we have a built a tool called Flux [1]. It is able to relate manifests in a git repo to images in container registry. It has a CLI client (for use in CI scripts or from developer's workstation), it also has an API server and an in-cluster component, as well as GUI (part of Weave Cloud [2]).

Flux is OSS [3], and we use it to deploy our commercial product, Weave Cloud, itself which runs on Kubernetes.

1: https://www.weave.works/continuous-delivery-weave-flux

2: https://cloud.weave.works

3: https://github.com/weaveworks/flux

Yeah, the point is that you should need to buy any hardware even for development, which is the biggest win to me!

Right, if you know how to set it up or have infrastructure in place... But most developers don't have time to read 600+ pages on how to run bind server OR simply have ops team that is very conservative at what goes in the DNS land.

Well, adding a library for supporting SRV records is not simple... If you use Weave [1], it gives a unique IP address to every service instance and a DNS record, all with zero configuration. That means you just stick any service in whatever default port it has, and it's all good. You can also have round-robin load balancing through DNS for free.

[1]: http://weave.works/net

It's really great to hear this is all happening now!

Hello, author is here, do let me know if you have any questions!

For example, here is the guide on using Weave for Kubernetes on Azure cloud: https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

I like OSv, just because it doesn't have TTYs.

OSv is a unikernel and isn't a container... but anyway, good point!

Yes. Grepping the code or fighting runtime errors are two complementary approaches I can think of... Not sure if there are other methods.

They don't have to, one can run static binary without any problems. It's just that most people keep throwing in a whole distro...

The exact approach described here is very extreme. It's a top-down method with a tool. I find the tool may be of some interest, but I think bottom-up method would be more practical . I have done some experiments with Yocto/OpenEmbedded and about to put that out one day, once I have time to document it ...

Well done, Kai! Cannot wait to try it out ;)

That'd be pretty amazing!

I have recently found this: https://github.com/rustcc/coroutine-rs

There is a lot community effort being put into Docker extensions to enable production use cases like what you have just mentioned.

In theory one can reimplement Node on Go runtime, instead of libuv and other libraries Node uses for binding the V8 to the OS.

Luke, congrats for releasing it!

Kai, it's really awesome to see this finally out!

Do checkout the demo [1] I and Luke did earlier, using Powerstrip adapters for Weave and Flocker. It shows how a database container can be moved from one machine to another, keeping it's data and IP address!

[1]: https://www.youtube.com/watch?v=8vVKtmd0ENw

I don't think it would be hard to use Kubernetes with Powestrip and Flocker. I and Luke worked on integrating Weave with Flocker together last week, and Powerstrip makes it really quite simple. There is not much that would get on the way of Kubernetes, if it moves a container, Flocker will move it's volume. That's the basics, of course, for something more advanced one will need to expose some features of Flocker in Kubernetes.

What would you do?

You will write code in Go to create flexible, easy-to-use tools for containers in development and in production. You will design and implement new tools for monitoring and managing container networks. You will help shape our vision of containerized software development. You will solve customer issues, write blogs to describe what you've done and participate in conferences and hackathons to grow your skills and reputation.

Core Engineer at VC-funded open-source project, Weaveworks, London

Weaveworks is a start-up founded by the team that created RabbitMQ and backed by one of the world’s leading tech investors. Headquartered in London, we are hiring engineers to work on our open source software product, Weave.

The purpose of Weave is to enable all developers, no matter what their background, to take advantage of container technologies such as Docker and build better software applications. We believe that containers will lead to much more software being built at greater speed and scale than ever before, so much so that many existing approaches will need to be reimagined.

We have an experienced team and welcome newcomers who want to progress fast, as well as domain experts in relevant technologies. Currently Weave is a set of network services written in Go, packaged to make distributed Docker applications much easier to construct. But we have considerable ambitions, and the space is evolving rapidly, so we especially seek developers with the right outlook and ability to adapt.

Ideally you have real world experience of building and running systems with a focus on resilience and uptime. You are as comfortable designing or debugging a distributed protocol as you are talking to customers building a web app or scaling a data service.

We hope to meet developers who share our values:

- Complete focus on the simplest possible user experience

- A real desire to innovate, and then measure success by happy customers not kudos from purists

- Relish being held accountable for work quality, but want to own how that work is done

- Want to participate in shaping the culture and technology of a fast moving company

- We communicate clearly and we respect everyone who uses our software

In short, you would be working on a highly visible and ambitious open source project with all the opportunities and responsibilities that come with that. We aim to be a market leader and want people who really feel they could be a big part of the team making that happen.

More info and application form at: http://weave.works/jobs/

An interesting project would be to implement a policy extension, one that would check where container image has the right versions of certain packages and would refuse to start a container with outdate JRE, OpenSSL or anything more recent...

If you are looking to build an extension, make sure to checkout the post by @binocarlos [1], it's just the right level of detail for you know and a full-blow implementation indeed!

[1]: http://weaveblog.com/2015/01/29/powerstrip-weave-a-docker-ne...

Perhaps I have had a wrong impression since I read on Nim quite a while ago last time and should checkout this article now. Thatnks for pointing this out!

I really wouldn't consider it reasonable comparison, when one language has a sufficient compiler that is written in itself for most part, and the other still only compiles to C.