This is Part Four in the series “The Future of Networks”, to start at the beginning go here.
There are many possibilities as to where the previously mentioned trends drive networking. As I continue to interact with the community and evolve my thoughts about the Future of Networks, I am going to cover more of this. I am also going to continue this series past the 5th planned post. Although the original 5th and final post will still go out tomorrow as planned.
Networks are trending to commodity based switching hardware, this could be further embraced and follow a more programmable paradigm. The hardware could be open sourced along with the network operating system (some switches are already running Linux or derivatives). If things go in this direction, there is opportunity to leverage a large number of OSS projects and capabilities to rapidly evolve both the network and network devices. By leveraging all open technology and places some capabilities/services/workloads inside the switch itself, networks get access to new communities. These communities could be leveraged to further advance the move from running everything server side to moving the right components to the network and everyone would benefit.
Imagine a commodity network device that has virtual interfaces that work with containers, VM’s and can also support straight code execution. The containers/VMs/code run on CPU/memory in the network device. The network device itself is programmable for traditional Layer 2-4 tasks and also can route and manipulate data at Layer 7. This then allows direct attached scenarios and traditional switching scenarios described in yesterday’s post. The layer 7 capabilities could also be run in virtual switches or proxies allowing ubiquitous services running across any environment.
Speaking of proxies and where the Future of Networking is headed, I’m currently at Gluecon where yesterday the Istio project was announced. For those that missed it Istio incorporates the work that Lyft did with Envoy along with several new control plane components, operationalizing microservices. What is meant by operationalizing microservices? Specifically, enabling things like Kubernetes to have selective traffic management and request routing allowing canary deployments and A/B testing. It also includes service discovery and registration, along with authentication, policies, and more. The Envoy component acts as a sidecar/transparent proxy to each of the Kubernetes instances that is running to provide all of the network coordination and capabilities. The Istio project plans to support several other technologies besides Kubernetes including Cloud Foundry and Mesos. It is also worth noting that Istio has been running inside Google for quite a while now and Envoy runs in production at Lyft servicing over 2M requests per second.
How would our future network device work with something like Istio? Istio is a service mesh where the Envoy sidecar provides ingress and egress traffic management. Envoy is being controlled by the Istio-Manager, which would be ideal to run in our new network switch device. The Mixer would also run in our new network switch device. Dependent services that are either critical or are heavily used would also run on our new network switch, potentially being moved from a container server side to a container network switch side. The service registry and policies seem like great candidates as well to run here. The new network switch is critical to the system functioning, why not put the critical services there? If the network is down, none of the services will function anyway.
This may all seem like it is far away, but there are many indicators that this could be a done fairly quickly. The next post lists out some of the things that already exist that support the scenarios and thoughts from the previous posts.
Data Gravitas 
I just was listening to your packet pushers interview. Great thoughts. Also just read the blog, LOVE IT. Reading and hearing about it all makes me excited that there are other folks thinking about the need for a change
Have you looked at eBPF+XDP, and its ability to build filters on the host’s kernel layer. Add that with Reconfigurable Match Table chips, like tofino, for networking telemetry plus openflow, couple that with normal networking like MPLS (I know open flow is dead), there would be a great model there to have something that would shore up a lot of the distributed computing problems.
I would be interested to hear your thoughts,on some model like that.
I haven’t looked at eBPF+XDP but will look now, filter drivers on the host kernel makes sense as an entry point. Really all of this should be backed into the host OS the same way it is in VMkernel (but with more robustness and focus on telemetry, etc.). MPLS would add an interesting mix on things. The distributed computing problems could begin to be addressed as you said, the other option is to have devices that address the dist compute problems where they are appliances focused purely on this task (or virtual instances).
I plan to do my final post on this series next week and hopefully that will spark some new ideas as well.