Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Moving Cloud Native Beyond HTTP: Adding Protocols to Unlock New Use Cases - Jonathan Beri

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Keynote: Moving Cloud Native Beyond HTTP: Adding Protocols to Unlock New Use Cases - Jonathan Beri, Founder, Stealth

Kubernetes and related projects have first-class support for serving and managing HTTP traffic. This makes sense since the most common protocol used by web servers is HTTP. However, there are many popular protocols in the world that are *not* HTTP. These protocols are used across a variety of domains, from IoT to gaming to telephony and more. In order to build cloud native services with these protocols, we need to understand how and where networking protocols are supported to uncover roadblocks preventing new applications in domains like IoT & gaming. This talk will provide you with a deep understanding of various projects and their protocol support to uncover what’s available today, what’s being worked and opportunities for the ecosystem to collaborate.

https://sched.co/eoFA

A

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.

A

My name is jonathan berry and I work on an iot startup. You can find me on twitter at ferryberrykicks. 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.

A

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.

A

Different projects and operators provide these things for http out of 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.

A

You use it when you want to configure a server to map your 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.

A

Well, you may not have realized that dns is actually a suite of protocols and when you use services like amazon route, 53 or core dns, those are actually implementations of dns protocols.

A

Dns, like http, has similar things it needs in order to be deployed to production.

A

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 that implements dns.

A

And there are a lot of application and industry protocols that are designed to fill a specific purpose.

A

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.

A

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 plans.

A

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.

A

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 the challenge of implementing load, balancing routing, etc from scratch all by ourselves.

A

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.

A

I want to see if other people in the community are also implementing new protocols and see what I can learn from them.

A

So I started talking to other folks like game server, devs working on project, agonists, webrtc, maintainers, working on pion, telco, folks from the network service, mesh project and others turns out they're all asking a similar fundamental question.

A

How can we implement any protocol in a cloud native way? This is clearly a community challenge, something bigger than my startup or iot.

A

I'm a pm, so I did what we do best start a doc. You can go up to it now at bitly 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.

A

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.

A

I started the dock 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 upstream features that make it easier to implement new protocols. This progress is both exciting and encouraging.

A

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.

A

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 ingross like ingress a gateway routes, traffic to a service, but supports more protocols like udp and tcp, among other things, with a goal to enable protocol implementers to create custom gateways in the future.

A

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.

A

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. 4 primitives, which covers a lot of potential protocols 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.

A

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.

A

Next, I'd like to highlight service mesh interface or smi, which is developing a standard for service meshes on kubernetes.

A

One aspect of a service mesh is how it manages. Traffic between services within a cluster smi defines the concept of traffic specs, a list of subspecs that define how traffic flows between mesh there are already subspecs for http, tcp and udp.

A

The intent is for protocol implementers to define their own traffic specs and eventually contribute them upstream to smi, where it makes sense.

A

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. The two projects to work well together, I'm personally excited to see how these two efforts- collaborate.

A

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 proprietary protocol cloud. Events is already being used today in projects like keynative and, I believe, will become more commonplace among event.

A

Oriented microservices so having a way to define custom protocol bindings will make it easier for services that leverage non-http protocols to interoperate.

A

The last project I'm going to touch on is network service mesh not to be confused with the other kind of service map or the service mesh interface.

A

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.

A

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 protocols in a cloud-native way.

A

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.

A

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, l4 and nsm is l3 and below you can use a surface mesh with nsm there's a bunch of advantages when combining these two concepts.

A

I don't have time to dig into that now, but the nsm crew have some examples.

A

With that, I want to conclude with what you can 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 humanities 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.

A

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 garybearkicks, cheers.