 So just so everybody knows the room that they're in you're in the building the interconnected ecosystem Discussion on the container network interface and the OCI projects Abby wrote the title for me. So I had to read that so we're we're pleased to have a illustrious group of people Here to join us today for a panel discussion on container networking things that are happening at CNCF and OCI In fact, how maybe they relate to cloud foundry and our ecosystem and our platform So I'm going to start by letting everyone introduce themselves to you later. We'll open it up for questions I've got a few seed questions to start the discussion. So why don't we start with Chris? Hello Hello, hello. My name is Chris Anizek currently I'm acting executive director for the cloud native computing foundation and I'm also part of the Linux foundation serving as a vice president developer programs involved With the open container initiative and some other initiatives within the Linux foundation My name is Craig. I'm a product guide Google I work mostly in the compute space and was one of the co-founders of the kubernetes project I am number two it says so on my microphone. Sorry. My name is Richard Kauffman. I run a research group at samsung And we work on cloud native technologies for Use within the samsung group and for others Outstanding well, thank you all for for being here So let's start with a really simple question Why do we care about networks and containers? Who wants to field that one? Why do we care? So stuff has to talk to something sometime That's the technical answer So from a technical perspective, uh, so, uh, I am I'm constantly worrying about problems Like 400 million endpoints want to communicate to some kind of a central service So, um, I'm looking for exceptionally high performance low overhead ways for those connections to happen So for me, uh, because, uh, containers are the Selected efficient method mechanism for building and deploying applications and services How I can efficiently plumb those to those 400 million endpoints is Very very important And I would say just kind of You know building on that a little bit Containers represent this incredibly portable atom of deployment. So they've really solved, uh, an early problem Which was you know, how do I actually package and distribute a piece of software and how do I make it available in a given environment? And you know, one of the things that we really need to get to is a point where we have a very rich ecosystem of management capabilities for these containers that can go anywhere And those management capabilities those management platforms Need to be integrated into a very rich and diverse set of physical infrastructure environments And you know, one of the gnarliest challenges You know in the space really is how to actually map a container, which is an application level construct to The network and how do I control how it interacts with other pieces of the network and how to actually elevate, you know, some of the Concepts to almost the application level so that I'm able to intelligently program The network based on applications needs and so it's it's a really Tough and interesting problem And you know, we've obviously been working together as a community to try to you know, find nice clean simple ways to start handling that integration You have nothing That's they've said it pretty well All right, there it is chris's answer What they said All right fair enough. So I'll continue to ask questions, but we've got a mic in the middle I am actually going to pick on people in the audience if no one stands up there to ask a question. So a couple of you out there Might need to ask some questions Didn't we decide that the best question got promoted to the panel? Well, that might not be an incentive Although those are that's a great format. So actually I'm going to direct my next question to to craig cloud Foundry has been looking at The the problem within our platform of of container to container networking different ways that we could think about that problem You know, we're we're thinking through the abstractions that are appropriate for our users But being heavily involved in kubernetes kubernetes has selected the container networking interfaces its approach to Tie together containers So what what was the the kubernetes project's perspective in making that decision versus perhaps some of the other alternatives that are out there That's a great question. I mean there were There really two kind of viable alternatives at the time There was a lib network, which is docker's implementation of essentially this function and then there was A new relatively nascent project that was being sponsored by our friends at core os That was part of the apc specification And you know, we put a lot of time and thought into it. Obviously we we're very invested in docker as a as a container format as a runtime environment And you know as a as an ecosystem enabler but we really struggled when we started looking at how to tie a Kubernetes run container into the lib network infrastructure You can really think about docker as being, you know, perhaps three things and you know, I tend to think of it as Three discrete things in a way one is, you know, docker is a format a way to actually describe something you put in a container Docker is also a container runtime environment So actually that that local way to take that and run it and then docker is also at the highest level a complete stack That gives you everything you might need from, you know, describing container describing how it ties together And then you know deploying it out using something like swan and we really struggled in the early days to disentangle The lib network implementation from the rest of docker's infrastructure So if you actually look at the way that it's implemented it pulls through a tremendous amount of the core docker capabilities So for instance, it's tied to Something called lib kv Which is a you know a distributed key value store And so we'd have to have stood up a discrete key value store and run it in parallel with this thing And it wasn't neatly tied into our sort of ecosystem We also felt that the interface was a little overly complex given what we wanted to accomplish Um, and it was tied, you know deeply to things like the docker demon, uh, which You know necessitated, you know, even even further and deeper dependencies And then when we looked at uh, we looked at what the app see guys had proposed with With uh See, and I it was very simple like very simple api very simple surface area Clean really, you know well factored and we felt like it was something that could you know You know really You know build we could build on it and so for us it was really just a sort of Necessary thing it was it was it was very difficult to actually just use the lib network capabilities to disentangle it from a lot of the other Docker componentry And then you know look at that as a standard the the c&i interface was just so much cleaner Richard, how about your perspective on this? Parallels craigs quite a bit which is um When kubernetes was looking at networking interfaces, uh, there's a very influential blog post I'd point you to from tim hawkins that's posted on kubernetes to io about this But basically, you know, they tried using um live network and you know pretty much found out that by the time they pulled it up They found everything including somebody's kidney attached to the dependency chain And it was much easier, you know that they tried very hard to use it And only went a different direction because they were forced to and craig was talking about how simple the The c&i api has just got three entries add a network delete a network and look at its configuration It's also composable so you can basically have one implementation of it Inside another implementation so you can experiment with new networks and new versions in a nice clean and easy way um, but I think at the higher level point is you want Layers in the system to know what they're good at and only only work on their area You don't want big monolithic things. It's a religious war almost But you really want kubernetes to be good at orchestration You want the c&i layer to be really really good at at encapsulating networking technologies that work from everything from Like a development oriented network that's you know, a software sdn to something that would be used in massive production So it's better at Composability and separability of function and and not having complex dependencies Heats to the unix philosophy Are there any questions from the audience? Yeah, any chance I could get you to run over actually I'll come over to you How about that? I'll join the audience Hey, um, so the panel was about oci and c&i And I was if you haven't talked about this yet I'm curious how you see those two things fitting together As far as I can tell everyone who might be considering using c&i is also using runc to run the containers So is there some synergy? Are we going to make those two things work together more closely? So oci or open the open container initiative is really all about standardizing on the kind of how you manage the actual container runtime with like runc And also specifically how the image format is is defined networking per se is out of scope Within the oci so things like c&i wouldn't actually be part of oci, but they the intention of I'm making sure making sure things work together cleanly Is is definitely uh, you know part of the project but the actual hosting and development of c&i would it does not in scope of the actual Oci charter. So if you actually look if you go to the oci website, there's this wonderful thing called the oci scope table Which talks about which things are actually in scope of the project and which things are out of scope? Hopefully that answers your question. I have a follow-up. Um, sure. So I think you should be on the panel So Well for cloud foundry, we're moving towards using runc to run our containers and we're moving towards using c&i to drive networking And we're gonna end up building a little adapter that Fits in between those two things and um, is every container orchestrator going to be building their own version of this adapter? Should we try to standardize on one? So rocket has a c as a c&i plug-in built in When you say c&i plug-in you mean a thing that's driven through the c&i interface or a thing that drives through this like The thing that drives Is built in to rocket docker. There's a piece of plumbing That you have to plug in that lets it use a c&i plug-in That's what the calico and weave guys built. Um so, uh Let's see from the perspective of an application or service writer that the two things that The container initiative sorry the container initiative and the networking initiative have in common Is that they're two things that they never want to learn about never want to care about and never want to buy them in the butt and Just as much as they stay out of each other's hair is a good thing Why shouldn't I be able to take the input to a c&i plug-in and make that part of my runc bundle? Like why not add that as a field to runc A fair answer might be Politics or a fair answer might be out of scope technology It's out of scope. Yeah, I mean like It's you know one thing to think about is this um You know c&i is really just a way to express uh in an integration point with um, you know variety technologies Um, it's relatively early days. Uh, so, you know, there's obviously a lot of room to kind of innovate and extend and and uh progress Um You know docker is obviously Doing an amazing work, you know in a lot of areas But they're also looking at the problem holistically like they're trying to think about how to create a complete stack that goes from You know the way you could create a container the way you deploy a container the way you'd orchestrate a container The way you'd update a container the way you'd manage it and they're really thinking about the system You know in in my opinion like holistically and they're looking at that that holistically We're coming at it from a different angle like a lot of us who are active in this uh community are trying to look at a disaggregate Interesting set of pieces. We just have a different set of priorities. And so, um, you know, I would hope that of a time You know docker and you know Adopts c&i that it actually becomes sufficiently mature and sufficiently obvious that it's just a great way to go Um, but I think you know from their perspective they're they're trying to look at that that holistic story and try to create it that way So just a different set of priorities. I think um, but My expectation is that you know as this gets adopted as we actually have really, you know, high quality plugins You look at what the calico guys are doing. It's really neat technology, right? And if it's made it, you know available through c&i and that's the easiest way to integrate it I would expect that it will become more ubiquitous and in by necessity. We'll we'll end up in that direction Any other questions from the audience? Okay, so we we talked a little bit about You know the technology and whether or not particular run times need to Implement whether maybe we should standardize on that. But let's just talk about c&i itself c&i itself was was obviously created by core west as part of You know part of their work around containerization their set of opinions It's building a bit of momentum seeing kubernetes and claud foundry and others adopted What what's the right home for it? Does it belong in cncf? If so, is there you know an update on status? Is that happening? Any discussions occurring? I mean, yeah, I could talk a little bit to this So I did mention that you know Networking's out of scope and oci doesn't mean that it will be out of scope forever. So potentially the To be or the technical oversight board there could decide that all of a sudden networking's in scope and It makes sense to put c&i there. But for now, that's Not the current mindset where they are we've had some discussions within cncf to To see if c&i could could fit within the purview of cncf There is discussions of potentially putting a proposal together kind of in the short term, but there is a body of people within the cncf that essentially Make the decision of whether c&i maps to the overall mission of cncf And you know, whether the project meets some of the criteria of what it means to be a cncf project cncf is generally looking for kind of You know high velocity, you know really good quality Projects with kind of diverse, you know, committership c&i kind of falls on the You know, it's a super important project, but you know, it's it's a very small piece. It's like it's a very simple You know, you know code and an associated spec. So I mean, I'd like to add a little bit to that. I didn't mention this earlier But I was one of the initiating members of cncf and I'm the Chairman of the the board Group so The the interesting question is, you know, is and this is a this is a this is an ongoing debate inside our own community Is is cncf a stand as organization and I think the overwhelming Answer is no, it's not a stand as base group, right? Like we're actually a A organization that's responsible for homing technology like, you know, like implementations and creating a great framework so that those technologies work well together and over time Maybe Standards will emerge, right and that's that's that's the way we kind of approach this We didn't want to lead with the standard We didn't want to like come in this and say, you know, hey We're going to design the heck out of this api and it's going to be a standard And then we'll stand up and implementation later What we really wanted to do was say let's take it from the other side Let's see what people actually use. Let's get some great technology. Let's pull it together Let's see what people use And over time, you know, when it becomes clear that this is what people want This is the actual thing that is being universally deployed when it hits a certain threshold of critical mass We can then look at the api's and make a decision as to Is this api fit to become a standard? Can we promote it to become a standard? And so, you know, when we think about the evolution of cni And the role of cni in the space At the moment, there's you know, there's when we were having these conversations You know kubernetes had implemented cni But it was you know, we just hadn't seen a lot of you know, other organizations and groups that really adopted embrace it and and sort of use it We're at a very different point today. I mean if you actually look at what cf's doing It's like wow that actually adds a tremendous amount of legitimacy to this To this as a potential standard because actually Is now a common way to integrate between you know, two of the sort of preeminent ways to to orchestrate these systems You look at mesos actually cni and now it's like holy cow Like and now we actually have like pretty much all of the mainstream orchestrators supporting it And so I would argue that over time It would be really good to get to a point where we have a couple of projects under management of cncf that are actually implementing cni It has enough miles on it that we're pretty confident it covers the use cases And when we get to a point where we're getting a lot of demand from the vendor community when they're saying like Hey, this really needs to be a standard. We need to be able to bet on this We don't want to change it You know, we want like when the when the community really needs us to formalize that That's when we need to have the conversation around whether we would actually introduce the formal standard as part of of cncf But I think we're a little bit away from that still So kubernetes Tells applications How they network the pieces of their application together and how those talk to the outside world So there's a model of how every pod has an ip address and and how those are allowed to talk to each other So that's really valuable because that means I when I write my application and I deploy it someplace I know it's going to have that behavior. So what's the benefit of standardizing cni? Is in the plugins actually So is there an ecosystem of people like calico like on coro west flannel like, you know You can name a half a dozen other things that plug in there and work And I think there will be benefit to the community To have that ecosystem be supported by one of the foundations somewhere somehow but There's I think craig was showing that You know, you have to exercise taste and judgment as to when the right time comes to elevate That api as the way that you'll do that and When there is enough interest in the community to maintain that ecosystem So I think it's really fair. I I want to then I'm going to shift the conversation A lot of that was inside baseball. That's really important to maybe a lot of people that are here But it frankly it's industry inside baseball Within the cloud federal community, I I think there's two major user sets that we're thinking about This is a bit of an open-ended question. I'm looking for some, you know, your comments on this The first user community is the community is the obvious one. They're the application developer And for us, it's it's it's code to running system, right? It's kind of our general mantra And there's some challenges and questions about, you know, what level of knowledge does a software developer focused on business algorithms and, you know, solving business problems What level of knowledge do they need to have about how You know, any of the networking components actually work I think that's still a bit of an undiscovered, you know, undetermined level of knowledge The flip side though is that we have We live in the real world of data centers that exist in the enterprise that are a blend of platforms Everything from existing mainframes and, you know, networking equipment And this is something that most people live in the real world all the time Frequently without any type of software to find networking even existing And so we have these two different tensions. There's the infrastructure up perspective Where we want to tie cloud native platforms together with existing Quote legacy. My new my favorite new word for this is vintage systems I'll use that one next time. I'm sorry one second artisanal artisanal vintage systems. That was a wonderful year 1985 So we want to be able to solve for both of these problems Giving application developers just enough information But not getting their way to make it really simple for them to write apps focus on solving their problems Yet fit into a bigger data center strategy So that was a kind of an open-ended set of comments How does Samsung think about that? So sort of a continuation of what I said the last time which is For example kubernetes gives applications one model to understand their networking and then underneath that implementing that abstraction We have stuff like the cni plugins the um If you think about it from the perspective of the application writer of not wanting to know what how the network is implemented They kind of want to take the thing that's on their whiteboard which says, you know I've got these services that talk to these components that need to talk to these users and I want to You know map a network that has the least amount of exposed ports to the least amount of exposed other actors And then get that mapped onto hardware. So that that's that's what they want and uh The stuff that you were talking about type one or the application deployers type two are the infrastructure Deployers the type two infrastructure. Deployers want the described services to be to be deployable Instantly so that they meet the application constraints But in a way that the the infrastructure managers can understand what's going on and they can do their Wide level like, you know, their intrusion detection and their threat detection stuff So you've got multiple actors wanting to do it the only way that you have to implement it That makes sense is to have those split levels of abstraction You give the application writers an understanding that matches What they want to understand and no more and then you give the underneath that where the cni lives You want to give them the tool so that they can get in there and manage things And the only way you have a chance to build that ecosystem is to make each of those layers So shit simple that Another technical term underneath I like that technical term too. Yeah, I mean, I'd like to just sort of riff on that You know a little bit, you know one of the things that I think is kind of a real sort of seminal point around things like cloud foundry or communities only these these new Systems is that they're far more intrinsically dynamic than anything we've seen today, right? Like traditionally people would look at Sort of actively manage systems as really being, you know, the sort of front end systems that serve, you know varying Consumer oriented work. So so that's that's the classic place where you'd see like Dynamic systems in in most of these sort of architectures We're not getting to a point where like the dynamicism is pushed like right into almost every application class you have Right these systems will you know decide how many instances of something needs to run and create the right level of abstractions to to tie them together And you know as a result of that they're far more intrinsically operationally viable, right? The developer really shouldn't be aware of most of the operations functions a scaling event for them is a non-event They don't even they're not even aware of it. They're not they're not cognizant of it Things might get turned on and activated later, you know when they're needed And all of that should be completely opaque to the developer But to make that dream a reality You have to have a really smart system that's actually able to program the underlying physical infrastructure, right? You have to have a well-defined set of interfaces that work pretty much everywhere And a lot of these systems that are emerging have some really interesting and novel network models to make that possible And to get there, you know, it's actually to like unlock these these capabilities We have to have a really principled well-defined structured interface between These orchestrators and the fund the underlying systems and that should not be the purview of the developer like You know there's a there's a different operations team that actually figures out how to actually provide that cluster environment or that cloud foundry environment Or if you want to call it And then the developers are just focused on the application level pieces And the final piece of it is Often is not you want to be able to preserve the developer's intent Like you want to be able to say hey the service needs to talk to the service a lot Right that's going to like with high bandwidth and low latencies. They're very they're very code dependent And you need to be able to preserve that intent or provide a framework for the developer to express that intent So that when these dynamic systems under the covers are actually making informed decisions about where to place things and how many to run That intent gets passed through and can be used to actually Program the underlying network fabric and make sure you have the right quality of service between services and all those other pieces And so I think it's uh, it's it's a really interesting space I mean a lot of it is uh relatively nascent compared to I think it's going to go And I think you'll find that like that boundary between These systems in the modern sort of nfv or stn type subsystems are going to be Really important to get right Looks like we've got a question over here from the audience. We've got about three minutes left So matt you'll be the last audience question. This is when we get the hard question I don't know that it's a hard question just to kind of follow up on your statement Sounds like you have a number of things in mind and i'm kind of hoping that you can Discuss what the roadmap is for c&i because right now it's really really basic and really really easy But like you said there's a lot of things there when it comes to expression of a tenth expression of policy They're all lacking right now in the api and you leave it up to the limitations I'm just kind of curious if you have a notion of what that roadmap for the future of c&i might not look like I'll give the first easy answer which is that if you look at the github page For it you'll see the roadmap And the two things that are on the roadmap right now one is dynamic changes to the network Once the system is up and running Actually, I think that's two versions of that are just the only thing on the roadmap Here we go But dude check the github Okay, I'll develop in the open. I don't know what else I mean, it's a great question. I mean the answer is Only a very small portion of these decisions are going to be driven directly in the c&i context right A lot of this is being driven in like the cloud foundry organization or in the kubernetes organization Or in a lot of the dependent communities And so I don't think we can with a straight face like lay it out to you what the c&i roadmap is right now I think what we can say is that Each of the communities will create an an interesting and novel set of requirements Some of those requirements will be you know pushed into an evolution of the c&i interface A lot of it will actually exist above You know above above the c&i framework, but you know, I just I don't think anyone knows right now because We just haven't Had the the physical conversations around you know The discrete needs of each of these organizations and I'm ready to put that back to the So chris looks like yeah, this is that did you have one? No, you just look anxious One quick thing which is because I'm on this panel. I asked some folks in my team. Hey, what's going on with this Next thing I know I saw saw something that showed up in our roadmap We've got this little thing called kraken which makes it easy to Deploy kubernetes on to amazon or to a cluster of nuts or gce or wherever And all of a sudden c&i showed up on our roadmap So we're going to integrate it into kraken at some point So that's a public thing by the way if you want an easy way to test out kubernetes So abby kern says one quick question. I said that matt was the last but go ahead yell it out I and I wanted to wrap it up here because I do think we talked a lot about inside baseball is We've talked a lot about different projects c&i oci Some other acronyms. I'm sure that we could probably add into the mix abc One of the things that's been a really a big theme this week is interoperability And collaboration and maybe we can wrap up the panel with talking about how that makes us a better community Final thoughts collaboration across projects It's it's absolutely essential One of the key responsibilities we have is to support innovation at almost every level of the stack And if we exist in a world where you have to be You know this high to actually be able to solution because you have to deliver At every level of the stack We've let the community down but we need to create an opportunity where if you have a crazy awesome Is a visualization framework you can actually bring it to a plethora of environments If you have a crazy awesome way to actually do overlay networking you can bring it to these environments And so I think that Collaboration around you know getting these sort of really well-defined sort of capabilities so that An innovator doesn't have to pick their ecosystem an innovator doesn't have to say, you know what? I'm just betting everything on you know, Kubernetes. So I'm betting everything on cf. I'm betting everything on whatever They can actually You know look at something. It's like, you know what if I actually conform with the c&i interface I actually get everything And so I think I think collaborating as communities to actually start Extricating and and sort of standardizing all these pieces is is essential for the efficiency of the broader community Yeah, and with my kind of oci and cncf foundation had on I think it's kind of the role of foundations to kind of provide The avenue for this you know kind of collaboration and interoperability to happen So oci is providing, you know the standard, you know way to do Life cycle managed for the container runtime and also the image format, you know that will kind of be You know taking care of when people are collaborating there cncf kind of acting as your cloud native commons bringing together useful, you know cloud native technology under kind of one neutral umbrella where people could kind of Collaborate and Interoperate with other foundations. We may have technology in cncf like like at cd ends up in cncf Just another component that cloud foundry, you know may use and and so on so I think foundations play a very critical role in in enabling this interoperability to happen So the sociological and political side of this is really important But there's a technical aspect which is architecting tasteful apis That have minimal functions and certainly minimal dependencies and touch points But sufficient to be able to produce very high performance capable systems But not get in each other's hair all the time Excellent and with that I'll thank you all for coming up here and Participating so thanks everybody for coming. Thank you, bro. Thank you