Larry Peterson at Tetrate's Service Mesh Day 2019: A History of Networking and What’s Next
At Tetrate’s Service Mesh Day, ONF CTO Larry Peterson illustrated his session on the history and future of networking with a diagram depicting the evolution of the “narrow waist of the internet.” Peterson’s full slide deck
We’ve come far from the minimalism Peterson shared in the form of the IP protocol datagram created around 1980– a historical artifact and a “beautiful piece of computer science.”
In broad strokes, said Peterson, we’re moving toward a phase where we are concerned only with services, orchestrated and managed by what we might think of as service chains, running not on a world of networks but on a world full of clouds. Our task now is to figure out what we need to add to that narrow waist.
Peterson provided an example of a particular variation of protocol buffer that could be used as a kind of “hammer” for assembling disaggregated parts and to generate a lot of code.
With its centerpiece CORD project, the ONF is working to architect a “central office” data center that component projects can “plug in” to provide various component functionality. Once created, Peterson suggests we’ll next need something like a “service chain” to make it possible to construct functionality on behalf of individual users, subscribers, applications, and devices that stretch across that multicloud as well as on prem and wherever you go in your mobile world. This, said Peterson, is where service mesh is going to end up.
One of the challenges CORD is addressing is the question of how to automate the process of operationalizing a system built from disaggregated components. ONF’s approach is to make those parts adaptable and to centralize the control and operationalization of that system, to avoid having to manage each individual component independently.
“You want to manage it as a complete system as a complete service mesh, and not have to manage the individual parts,” said Peterson. “Disaggregation was good for innovation, but it’s what you’re working against as we try to integrate and operationalize.”
Another goal of this system is to enable the programming of services in the abstract, or the building of services out of services, as opposed to concrete implementations. “The service chains are basically combinations of instances that have been allocated to a particular use case,” said Peterson, “which could be a subscriber, an application, or an end device.”
But as we look to the future as all of these technologies are coming together, control and observability will be key features to pay attention to.
Some key takeaways:
- The access network is being codified.
- Operationalizing that edge is a really challenging problem.
- The access edge will be a critical part of the multi-cloud.
- We don’t know what the narrow waist is going to look like, but we can envision that everything will be a service, with meshes of functionality and service chains, the functionality allocated to individual subscribers.
- Fine-grain runtime control is going to be important
- Finally, there’s a rich opportunity now to get out of our siloes and think about problems that are exactly the same as you move up and down the stack.
“Whether your functionality is implemented in the Envoy proxy or in the switching pipeline, it’s still functionality that gets you from point A to point B, and it needs to be managed and operated,” said Peterson.