 Hi everyone. In this session, we'll be discussing protocols, specifically networking protocols. I'll cover some of the challenges we face deploying protocols to production and where we as a community can make it easier. Let's go. My name is Jonathan Berry and I work on an IoT startup. You can find me on Twitter at Berry Berry Kicks if you want to chat about protocols or anything else. We should probably begin our discussion with HTTP as it is the networking protocol most people are familiar with. It's the lingua franca of the web and a large percentage of web services are built using HTTP. Now, once you have your HTTP service, you're not done. You need a bunch of things to deploy to production and in the cloud. Things like load balancing, routing, security and observability. Since HTTP is a popular protocol, different projects and operators provide these things for HTTP at the box. Which is great, since you would otherwise have to build these things yourself. But HTTP isn't the only protocol you'll use all the time. There's also DNS, everyone's favorite service. You use it when you want to configure a server from after domain name or enable services within a cluster to discover each other. But what if you wanted to create a DNS service? Turns out this is a thing that people want to do. Well, you may not have realized that DNS is actually a suite of protocols. When you use services like Amazon route 53 or core DNS, those are actually implementations of DNS protocols. DNS, like HTTP, has similar things it needs in order to be deployed to production. However, since DNS is a less common protocol compared to HTTP, it isn't supported out of the box by many of the cloud-native projects. And therefore, you have to build a lot of these things for DNS yourself. And that makes it way harder to build your own solution than implements DNS. And there are a lot of application and industry protocols that are designed to fill a specific purpose. I've listed a few examples here, but they range from synchronizing game state to streaming WebRTC to the Internet of Things. And actually, IoT is what first got me interested in exploring the topic of implementing protocols in the first place. See, there are a ton of IoT protocols designed specifically for the needs of connecting physical devices to each other and to the Internet. Some are optimized for power, some are optimized for bandwidth. Others implement standardized industrial or consumer control points. Some are built on the Internet protocol, like UDP and TCP, while others simply can't use IP. As a startup, we're interested in implementing many of these protocols in our cloud solution. The challenge my startup faces in bringing IoT protocols to production is similar to DNS in that these protocols are less common than HTTP, a lot less in fact. And therefore, aren't supported easily by many of the projects, services, and clouds we might want to leverage. Therefore, we're faced with a challenge of implementing load balancing, routing, etc. from scratch all by ourselves. That means we can't leverage the wealth of open source from this community or take advantage of great solution providers. But I did say before the challenge of implementing protocols isn't specific to IoT. I want to see if other people in the community are also implementing new protocols and see what I can learn from them. So I started talking to other folks, like Game Server Devs working on Project Agonis, WebRTC Maintainers working on Pion, Calco folks from the network service mesh projects, and others. Turns out, they're all asking a similar fundamental question. How can we implement any protocol in a cloud native way? This is clearly a community challenge, something bigger than my startup or IoT. I'm a PM, so I did what we do best. Start a doc. You can go to it now at bit.ly slash beyond HTTP. It's a living doc that surveys a growing list of cloud native projects that might be used as part of a solution that implements a networking protocol. It tries to identify which projects are specifically focusing on supporting non-HTTP protocols and suggestions on where they can add additional hooks that we implementers might need. Feedback and contributions are greatly welcome. I started the doc over a year ago, and since that time, contributors and maintainers have helped shape it. At the same time, projects across the cloud native ecosystem have added upstreamed features that make it easier to implement new protocols. This progress is both exciting and encouraging. There's more projects than I have time to discuss in this session, but I wanted to highlight a few I think will be used by the most amount of folks. Kubernetes, Envoy, Service Mesh Interface, Cloud Events, and Network Service Mesh. Let's start with Kubernetes. Kubernetes has a concept of Ingress, which is an object that exposes networking traffic from outside the cluster to services within. The current stable Ingress implementation supports HTTP. Go figure. Within the networking sig, a group has been hard at work developing the new gateway API to replace Ingress. Like Ingress, a gateway routes traffic to a service that supports more protocols like UDP and TCP, among other things, with a goal to enable protocol implementers to create custom gateways in the future. They already have demos you can try, and it may be in an alpha release by the time you're watching this recording. Envoy, as a popular networking proxy, by its nature needs to support a protocol in order to act as a proxy for said protocol. Envoy has always had native support for HTTP, but due to its popularity, began implementing support for protocols like Redis and Postgres, albeit in a one-off fashion. Over the last year or two, the team has added UDP and TCP listeners, which make it possible for protocol implementers to use Envoy to proxy any protocol based on those layer four permatives, which covers a lot of potential protocol. Also, with the introduction of WebAssembly support, Envoy has now made it even easier for more people to implement custom protocols in the language of their choice. One more thing, since Envoy is used as a basis for other projects like service meshes and observability tools, it now becomes easier for projects like Istio and Prometheus to support custom protocols in the future. Next, I'd like to highlight service mesh interface for SMI, which is developing a standard for service meshes on Kubernetes. One aspect of a service mesh is how it manages traffic between services within a cluster. SMI defines a concept of traffic specs, a list of subspecs that define how traffic flows between the mesh. There are already subspecs for HTTP, TCP, and UDP. The intent is for protocol implementers to define their own traffic specs and eventually contribute them upstream to SMI, where it makes sense. You might notice some parallels between the Gateway API in Kubernetes and the traffic spec here in SMI. Gateways are about traffic coming into the cluster, while traffic specs are internal traffic within. So there's a potential for the two projects to work well together. I'm personally excited to see how these two efforts collaborate in the future. Cloud Events is a specification for describing event data in common formats to provide interoperability across services, platforms, and systems. It defines how to serialize events in different formats like JSON and protocols, which of course include HTTP. There's already subspecs for protocols like Kafka, MQTT, and Nats, and clear documentation on how to define custom slash proprietary protocol. Cloud Events is already being used today in projects like Knative, and I believe will become more commonplace among event-oriented microservices. So having a way to define custom protocol bindings will make it easier for services that leverage non-HTTP protocols to interoperate. The last project I'm going to touch on is network service mesh, not to be confused with the other kind of service mesh, or the service mesh interface. NSM is here to extend the existing Kubernetes networking model, but address networking use cases that need to go deeper in the stack, like L3 or L2 layers, or even Ethernet frames themselves. Inspired by Istio, network service mesh maps the concepts of a service mesh to L2, L3 payloads, hence the name. Telcos and the CNCF telecom user group are big fans of NSM, and one reason is how it enables them to implement cellular-specific protocol in a cloud-native way. 5G is propelling the telecom industry into fully embracing what they call cloud network functions. Many of the functions have been classically implemented in very expensive hardware found in cell towers that take a long time to physically operate. With cloud-native functions, telecom operators hope to build these capabilities as services that can be more easily upgraded over time. Lots of the functions are specific niche protocols that are part of the operation of 5G networks, and NSM provides the means to configure them on top of case more easily. I'm only scratching the surface of what NSM enables. Fun fact, because service meshes like Istio operate up the stack at L7 and L4, and NSM is L3 and below, you can use a service mesh with NSM. There's a bunch of advantages when combining these two concepts. I don't have time to dig into that now, but the NSM crew have some examples. With that, I want to conclude with what you could do to participate. If you're trying to create something with protocols other than HTTP, share your story. Documenting use cases, both real-world and aspirational, has been the single most effective tool to help improve protocol support. Create issues, hop on Slack, the CNCF, or Communities is a great place, or just hit me up on Twitter. And if you're a project maintainer, try to identify where your projects currently assume traffic is HTTP and look for places for extensibility. Oh, and ask your users what they think. And that's all I got. Thank you, everyone. Here's a link to that doc one more time and you can reach me on Twitter at HarryBearTicks. Cheers.