 Good morning. Good afternoon or evening, depending on where you're joining us from welcome to our panel My name is Jamie Longmere and I work at Red Hat as the product manager for OpenShift Service Mesh Which is based on the products Istio, Envoy, Keali, and Yeager Today we have some panelists from the Istio community, KeyNative, and Contour as well to discuss their projects What's been going on in the year and what's coming up? Let's jump straight into the introductions First up, Nick, Nick Young. Could you introduce yourself? Hi everybody, my name is Nick Young I am a staff engineer with VMware and I'm the tech lead for Contour and Ingress controller for Kubernetes Thanks Nick. Lin Sun Hi everybody. I am a maintainer on the Istio project. I work for IBM I'm also a senior technical staff member and master inventor with IBM Thanks for joining us. Dan Berg also from IBM Hello everyone, I'm a distinguished engineer with IBM I'm responsible for the technical architecture of our Kubernetes and Red Hat OpenShift on IBM Cloud as well as a co-founder and member of the steering and technical committee of the Istio project Thanks, Dan. Brenda Chen from VMware Hi everyone, I'm Brenda. I am an engineering director at VMware and currently I serve on the Istio and committee for the K-Native community That's Brenda. Finally Paul from Red Hat Hey everybody, I'm Paul Mori. I'm a senior principal engineer at Red Hat I've lead our serverless engineering team and represent Red Hat on K-Native steering Thanks Paul. Thanks. Thanks everyone So let's let's just jump straight into our first question to help us get a little bit of context around these projects I'd like to understand where they fit into the ecosystem at large So assuming we're starting with Kubernetes, which I think most people have some familiar familiarity with where does your project fit in? I'll start with Nick on and Contour Sure. Well Contour is a Ingress controller It's that means that you can use Any of the resources we support which are currently Ingress our own CID HDP proxy and soon the new service APIs to Get the traffic To your to the pods that are running You know, we will do that regardless of what those pods are if they're running, you know vanilla old-style pods serverless pods or in a service mesh if we get as long as we can Do whatever MTLS you have then we'll Fit in there. So we aim to do a very wide range of Ingress Sounds good an urgent to Istio so Lynn or Dan. Do you want to give a give a shot at that? Happy to and I'm sure I'll miss since then we'll add So I think micro services as people starts to develop for micro services on Kubernetes They will encounter a lot of challenges on how they are going to connect the micro services How they are going to do traffic shifting how they are going to handle timeouts and retries So as people developers break their monolithic to micro services a set of new Challenges arise and Kubernetes doesn't really help to solve these challenges to help the micro service to connect to each other to help the micro service to secure established secure communication doesn't help the owners to Observe what might be going on within different micro services So it still is coming as a service mesh to help solving those challenges for developers Yeah, and I I would just add to that that obviously if you're building modern-day Microservices, I mean you can't but help to stumble across Kubernetes as a orchestration layer for your your containers Istio Has been developed from day one to work well within a Kubernetes environment It actually extends the control plane of Istio that manages All of the programming of that network service mesh is built as an extension to Kubernetes So its API capabilities are extending the Kubernetes Environment the benefit though is that it works natively with Kubernetes It also works if you works with native VMs as well But Kubernetes is central to the management of the Istio control plane and the Istio ecosystem itself Thanks guys, it's now to Knative Brenda or Paul. Do you want to take a stab at that? Sure. So what Knative aims to provide is a higher level sort of developer abstraction on top of Kubernetes. So Knative serving focuses on Allowing app developers to be able to roll out different revisions make changes easily Handles things like auto scaling and traffic rollout for you and then there's Knative eventing who handles sort of event triggered applications and essentially what Knative provides is Tying all of that experience together because if he were to do it manually, it's actually quite challenging right now Maybe I'll let Paul chime in here Yeah, I would say that's That's a good summary one thing that that maybe we'll talk a little bit about later on is that when we say serverless we a lot of folks tend to Conflate serverless and functions as a service And we do not currently have functions in Knative more of serverless building blocks for event activation and Scale to and from zero Thanks that that that's that's interesting So actually that kind of leads leads really well into my next question about your projects and maybe just just on that note I'll go in reverse order on this one So just given that you know, these are these are fairly fairly complex projects What are what are some of the most widely held miss misconception? What is the biggest most widespread misconception about your project and I'll go back to Knative because you're kind of heading in that direction Paul do you want to jump in on that? Yeah, I Think the the misconception I probably spent the most wall clock time talking with people about is That you do not need a service mesh to use Knative You really just need an ingress And I think this this misconception is probably rooted in Like a historical fact that in the very early days of the project It was there was a dependency on Istio, but we've since removed that a fairly long time ago And so you can use any Any of the supported ingress of course Istio is a supported ingress contours a supported ingress There's a courier ingress that came out of the three scale team at Red Hat But you don't need a service mesh to use Knative It's a good point So I'll go to Istio now. I'm curious what what what are some of the misconceptions that people might have about Istio? and Lynn or or or or Dan do you want to do either? Yeah, I want to try on that one Yeah, sure one of the ones that we hear and we've heard this from day one is Istio is too complex to get started with and a Lot has changed in the project over the over the years to simplify the getting started experience But I think a misconception here is that if you adopt a service mesh like Istio You have to adopt everything about that Istio about the service mesh and all the capabilities, which isn't true We have many people that adopt very much to what Paul was saying many people adopt Istio simply for the ingress capabilities and They do not enable and take advantage of the other features from day one. They gradually work their way into it And going down a path such as that the install simple the adoption of simple ingress Through the Istio gateway is an incredibly simple So it it doesn't have to be complex. It gets more complex as your application is more complex and takes advantage of more complex features Right, that makes sense with given the breadth of these these services. It does make sense to start to start simpler and work your way up Nick is there anything from from Contra's perspective that people might have misconceptions about Ironically enough we often get the question or the statement. So you're using envoy. Does that mean you're a service mesh? To which I say well, no Contra is not a service mesh It's using envoy as a like as a reverse proxy for for ingress only So that's probably the biggest misconception again to use Paul's phrasing. I've used to spend the most walk-alike time talking to people about Sounds good. Thanks. Thanks Nick So, you know, we touch on the fact that there are dependencies like Contra using our envoy and obviously with key native There's there's Istio and these projects are kind of part of a wider ecosystem. So given some of these dependencies between projects What's how does your community? Go about coordinating with other projects And I think in this time I'm going to go back again But yet another way so back back to you Nick with Contour and how do you work with the dependencies and other projects? Yeah, sure. Well, I think you know, obviously our major dependencies envoy We work as close as we can with with the envoy team You know, we done all the usual stuff to get signed up to the security announcement so that we can make sure we're keeping up with those things but yeah, we We've been doing the envoys XDS for a long time the same as you see effects have and so we've You had to start out with we didn't have when we started using it We didn't have the go control plane to available so we've written all our own stuff and the envoy folks have been really helpful as we look to move Towards go control plane to be able to make it easy to move towards XDS v3 and things like that With respect to coordinating with other projects. Um, well right now Matt Moore and some of the other folks from Knative have actually been really instrumental in pushing back a whole bunch of really great fixes for us and The fact that they've included contour in the testing for Knative has actually been really helpful They've caught a number of scale problems that our testing just wouldn't have been able to catch Which I was very appreciative for Right, that's that's that's great when it's a two-way street there So I'll throw the same question at because I mean SEO has the similar envoy dependencies to Flint Lynn or Dan if there's one one of you guys wants to take a shot on it So we do have the same dependencies with the envoy. We actually have our own Envoy within is your organization. I think of what goal is to get rid of it But for the longest time we had the mixer filter, which we now get rid of them now But we still have all our bars and stuff that's Build into is still I think the longer term is we want to consume upstream envoy directly but now we're still maintaining this a Small a little bit of folks version out of our way But we do think with the envoy upstream pretty frequently the other Kubernetes we worked really hard to get on quarterly releases which it matches the kind of matches Kubernetes release schedule We do because it's your interactive with a lot on the Kubernetes API and it's your resources Also build as Kubernetes customer resources So we have somewhat dependencies with Kubernetes and we learned in a hard way in recently It's your 1.7 When it first goes out We we kind of move up some of the API too fast and a break over user who's still on Cuban anyone 15 so we learned very hard and you're not moving too fast so we could potentially Support not really officially support, but at least doesn't break users who are on slightly older version of Q Make make sense some some good good lessons learned there Okay, so jumping to Knative, which I know has even even more dependencies. I'm curious how you guys manage Brenda or Paul do one of you guys want to take a stab at it? I think for for Knative. It's interesting. So as Nick mentioned, there's contour support. There's this to support And I think the worker blade and the TOC and the community have done a really good job Making sure that they're developing the right interfaces to connect with these different implementations I think the the community really wants to make Knative as portable as possible and In order to do that they understand that they need to make that experience with contour and is to enough shrimp Kubernetes Be successful as possible. So a lot of them do end up going to the various Community meet-ups or the SIG meetings or the workgroup meetings. That's applicable for the different workgroup leads Yeah, one one other challenge that we've had is that is And and this was a bit of an eye-opener for me having been historically focused on OpenShift where we we in The upstream Knative want to support a variety of different cubes And it was sort of eye-opening to see that they they really move at different rates if you look at the Cube as a service products from different cloud providers so We kind of have this this sort of sliding like Highest version of cube that we can get away away with and it's frequently behind The the cube that's under development or that was just released. So a balancing act there has been Doing things like before conversion web web hooks were pervasively available Doing sort of what we could until we were able to rely on that feature And then the other end of it is that Is that if if folks that are watching aren't aware the tecton project which you'll probably hear more about in Commons and I'm sure you're You'll hear more about a cube con is it actually started out as part of the Knative project and They have a dependency on some of our internal libraries in Knative. So there's a need for Really good communication around that like we call it the PKG package that tecton uses to Cool. Thanks. Okay. I think now we're going to jump into more of what's what's What's been happening in the products and what's what's coming? So I'd like to hear a little bit about what's What's been happening in the previous year. So I'll ask the question What from your perspective is the most important thing that's happened in the project and If it's if it's different, what's what's the best thing that's happened in your project? So I'll start with Nick for contour Yeah, I guess the the most important one is probably similar to the best one for us. Um, we Joined the CNCF as an incubating project in the last year. That is has been a really exciting Process to go through and it's really great that now we're officially part of the CNCF I've when talking to a bunch of users of contour. They've definitely found it very reassuring that that That we are now a CNCF open source project and to know that we're not going anywhere Yeah, I think that's probably one of the best things that's happened this year I mean, we've done a lot of releases released a lot of features and stuff We managed to keep to a monthly release cycle, which I'm super proud of But yeah, I think just the overall best thing has been joining the CNCF That's awesome. That's a big step So for for Istio Dan or Lynn do you want to talk about this year? Yeah, I would I would say probably one of the the best things or most notable things that has happened with Istio is the change in the Istio steering committee we created a new and voted in a new Charter for steering and held elections and changed the the actual structure of our Committee itself and the outcome of that has been a much a much more diverse steering committee and beyond just adding More diverse set of members to the committee We've also reduced the individual power of any one organization within the committee So that no one has a majority on onto themselves. So it's actually made a big difference We've noticed it now now that we've had the new members new ideas new dynamics have been added to the project And it's it's actually been a really nice change to to the project to have other voices beyond just the initial Founders in in the project. So I would say that's probably one of the most important things that has happened to the project Obviously, there's the looming. We did not go to the CNCF as we as we were hoping but What we have found is that the chain and the management of the trademark which was also in a pretty large event in the community Hasn't really changed the dynamics on a day-to-day basis of how the community and the Istio project runs it is rooted in a foundation of pretty solid group of Organizations and members that hasn't changed even with that Adjustment in how the trademark is managed Sounds good. Lynn and Chris. Do you have anything to add to that? Um, I definitely agree, you know what Dan said I would say on the technical side. I think the most There's so many accomplishments. We did certainly but the most impactful one is The Istio control plane actually went from microservices to monolithic to really help our user to Our operators who manages Istio to simplify their installation management experience And honestly, I would say it actually helped us For the maintenance on the project We actually see a lot less issue with Istio control plane by going back to monolithic So it's a really a win-win from a variety of different roles on the project Yeah, that was that was a nice nice change So jump jump over to k-native I'll start with Brenda on that. I'm Chris for you. What's uh, what would have been some of the biggest things this year for k-native? Yeah, this is a great question. Um I looked back at my Twitter account this past year and I saw All the changes we've been able to make within the k-native community in terms of clarifying the contribution ladder defining um the execution lead role for working groups um, I think the the highlights for me personally are Getting an elected TOC in back in March And just recently in september, we defined a new Uh process for how we might have an elected steering committee that can focus on community health and community growth And also a trademark committee where uh vendors who are actively contributing to k-native um can have a veto or I say in Um how the trademark is used Um, so that for me is really exciting That's huge. Yeah, that's that's huge. Uh jumping to paul From your perspective, what have been some of the big things this year? Well beyond the the governance stuff that uh that brenda mentioned, I would say that having uh serving and eventing reach The one level of maturity for their apis was pretty big. Um the You know, there's this like classic conundrum and open source where people Only want to use things that appear to be stable whether they actually are or not. So Getting to that v1 api version without an alpha or beta qualification to it is uh psychologically important for a lot of folks and uh my my hope is that uh My hope is that we'll uh We'll see an uptick in usage now that now that that's scary alpha and beta is out of the api Yeah, no that that makes a lot of sense. I know a lot of a lot of customers are uh, not confident to use something until it has that That big 1.0 uh steel uh seal um So that was looking looking uh looking behind now looking looking ahead this year I want to go back back to you guys and uh, basically ask what's what's exciting about what's uh, what's coming next What's uh, what's interesting there? Um, so again, I'll start with nick again on contour Um, well, we've got a bunch of uh stuff on our roadmap. Um for the next year you around adding in a bunch of so things into contour that uh, basically catching up is the is the real story there, but um You know things like rate limiting. Um, we've recently added external authentication Uh, which has been a hole for us for a while. Um, but um I think the the biggest thing that I'm looking forward to adding in the next year is support for the new service apis That are being built in the kubernetes signal working at the moment. Um, we've been involved in that uh project since uh Since its inception and I think that uh, it's a really great chance to remedy some of the uh deficiencies of the um thing that I mean which were things that we just missed that were just missed when Uh, people started building ingress because no one had done it before and no one knew What we needed but now everyone's been using ingress for some time And uh, now we kind of know know what it is that we need And so we're able to design a much better api It's going to fit more use cases and be much more applicable and hopefully You know at the end of the day, I think the thing we all want there is to not need You know over a hundred annotations on your, uh Ingress object to be able to control the stuff you need to do for your ingress Yeah, absolutely. I know we're very excited about the service api uh project as well. Um Jumping over to uh, istio, uh, uh, lin what what's what's interesting uh in the in the future for istio Yeah, so I I think we overuse are getting comfortable using istio at least on the common scenarios in single Single cluster. So a lot of focus of the project has been shift to how do we improve users experience? Beyond a single cluster. How do we onboarding users services on a vm securely and easily? How do we? How do we allow users to run services on different cluster? How do we? Federate different measures together So I've seen community has been kind of a shifting this notion of beyond single cluster experience Where we really want to expand The service machine, you know beyond a single kubernetes cluster. So for instance, we're being consolidate Or a multi cluster model into one single model, which I really like So for the longest time, you know, there was like two models and we got tons of questions from our user Why would you use this or that? Um, we've also introduced external control plane, which allows user and mesh admin to work with single cluster Where their control plane runs outside of the cluster and provide opportunity for Vendors who runs is still as a service for for the user. So these are exciting thing We are introducing in the community to improve users experience Whether it's single cluster or whether they want to grow the mesh beyond the single cluster to include VMs and multiple clusters Thanks. Yeah, I know there's a lot of things there. We're we're excited about as well Dan and anything else to add to that what's coming this year Thing the only thing I would add. I mean, I I definitely agree with Lynn I mean the multi multi cluster scenarios are pretty exciting space. I think also aligning with Uh, the changes that are coming in kubernetes Also a big a big deal the new kubernetes multi cluster services support is a is a big area obviously aligned with that same notion of the Multi multi cluster multi mesh scenarios these these keep coming up with our with our customer sets Continuing to expand on support for hybrid workloads because not everything is container So you do have legacy so being able to tie into those legacy aspects Is is pretty pretty key And also just the overall simplification of the use cases how to simplify Uh, the day two operations Doing problem determination through various CLI actions and analysis that's being added into the project to make it easier to detect problems and help you to resolve configuration problems that you may have throughout Throughout your use of the sdo project. So continuing to simplify The use cases and then as Lynn was pointing out the whole Multi multi cluster multi federation support is is pretty exciting work Absolutely exciting times. Um No jumping over to to k native, uh, paul. What do you see is exciting for uh, uh the coming year Well, one of the things that that To to to go back to what I previously said around hitting that v1 api version is we have not Actually released 1.0 yet. Um So the api and api version and the actual like version number of the software two different things Um, one of the things that I think related to the trademark committee that brenda mentioned earlier that became A lot more clear during our like community process for working through the governance stuff is exactly what the bounds of The the mark are going to be and I think that will allow us to declare a 1.0 version, uh, which is another really psychologically important thing in terms of adoption and then I I really just In looking forward to um In looking forward to having our steering elections That should be later this year at the end of the year and uh, I I feel like our community got a great jolt of Uh, you know good feelings around the tsc elections earlier, and I hope that uh, we'll get another good jolt from that in the community When when we do the steering elections Sounds good, uh brenda. Are there uh, is there more you want to add to that? Maybe um, one thing I'll add is we've seen a lot of excitement around forming a functions working group within the community Um, and I think that will be pretty exciting coming up. Um We've seen a lot of excitement a lot of people passionate about this topic Um, so I think that's probably something uh that people can look forward to That sounds good. So uh, lots lots to come uh final question that I'm going to go uh around with you guys on is uh So open source can have many interesting moments and there's a lot of uh benefit so I'd like to hear about what uh What's uh, what's your favorite open source moment that you've seen in your project? And I'm actually going to go back to paul first on this because I know that he this is one that He was interested to talk about so Yeah, like uh one one stands out in my memory and that is uh that During our Discussions on governance that we we shifted things into a 100 percent public mode uh because we had felt that um We had felt that we were sort of overdue for progress and we wanted our community to be able to participate in that process um and and I Brenda you'll have to correct me if I misremember the number of people but like i'm pretty sure in that first public meeting that we had we had about 55 or 60 people dialed in and uh, that was that was just a great feeling to To see that people were that interested in working through these things and uh Just just energizing to know that that other people cared about it as much as You know, I do and I know that Brenda does Sounds good. Brenda anything about that? That that's exactly the moment that came to mind for me as well. Um, I believe it was like 65 people On a zoom call or a hangout and it was just so good to know so many people cared about the success of this project and Um, everyone was open for discussion. There was no pointing fingers Everyone just wanted to make the community better and that that was a really nice feeling Nice nice, uh, so from so from an istio perspective. I know it's been an active year in the the istio community Uh dan or lindu do you want to chime in on that? Yeah, I was gonna I was gonna say and I'm gonna go beyond just this year. I'm gonna go back to 2019 um was One one event that I thought was incredibly interesting. It was kubekan in san diego And this was pre-covid obviously so we could actually get together Uh, but the problem was there we we wanted to do a meet-up for istio But we kind of organized it late And or we're not the best at some of these uh organizational skills if you will So we tried to organize one, but we ran out of space. There was no available locations that we could use But someone came up with a pretty novel idea and an approach and come to find out Our meet-up was uh later in the evening on a boat Which I've never had a meet-up on a boat before It is kind of odd when you're walking up and you're you're looking for the address and uh, lo and behold It is I forget the name of the boat someone's gonna when you you may remember the name of the boat, but it had a funny name Uh, and we were at the uh, we did the full meet-up on the boat, which was really awesome lots of people turned up obviously we had to keep the audience To a small number so it was it was basically an invite only meet-up which was a bit strange Uh, but we we had a packed house. Um, the other cool thing about that event that was the first time that we had as one of the discussions We actually when and I actually had to talk on that meet-up but it was the moment when we realized that Istio had been out for a little while and we have several several books on the istio topic At that meet-up we had every single author of all the books that have been written so far were at the meet-up So that I thought that was pretty cool that we had all the istio authors At the same meet-up on that but so that was pretty fun. That's that's great. Uh, Lynn uh perspective Well, that was great. Sorry. I don't remember the name either But that was like a really special evening Gosh, it's so interesting. I remember uh, somebody I think it was christian was trying to show a live demo on that boat Where there was no projector so everybody had to stare at his tiny monitor for his demo But it was uh, it was a really cool event. I actually saw I definitely agree. That's one of the signature moment, but I would add Um before I hear in dance, I was thinking, you know, gosh last year. I think we were rated like one of the top five Fatis growing open source project in all of github. So that was just amazing for the project itself really need So, uh, finally Nick I'm curious from the contour project a little bit bit younger than some of these but Would have been some of the months that have stood out for you Yeah, because we're such a we're so much a younger project and a smaller project than the others My stories are kind of different. I guess, um, you're One of one of the great open source moments for me has been being accepted into the cncf and being able to say Okay, you know, we're really open source and it's one of the things that's come with that is Greater visibility and more Comfort from people to come and talk to us about what they've been doing one of the things that I found When I became the tech lead for contour, which is about the same time as we uh, we were accepted was that You know a number of people had um, you know, we were a small team then and a number of people had Because they wanted features that we just couldn't build for them fast enough They'd gone off and decided to carry a full fork of contour And since then I talked to them and found out what the sort of things they needed And you know, we've been able to bring a couple of people back to You know to using the vanilla contour and to bring and to upstream the changes that they needed or equivalent ones one of the one of the great examples of Something like that was we had a request to to put a cause functionality into contour and We found it really difficult because of the way that we'd structured our our own crd to be able to find a place to Put that and so we recently merged Uh after A year of design talk The actual pr to to make that happen. Um, and that I think that was a testament to the people who really wanted the feature That the day that they stuck with it, you know, even though we weren't so great at getting it started but but they stuck with it and helped us out and And everyone has won in the end because the people who needed the feature got it And we got to good got them to build it for us I guess I said and this and the other thing is just all of the times, you know, again, I really want to thank Okay, native team for they've they've discovered two Pretty critical performance issues for us Because of the scale testing that they run on contour That yeah, we probably wouldn't have found until they went out wider And so yeah, that was another great open source moment where People who are not part of the core main maintenance group have really helped us and really You've been able to you know, drive improvements to the product even though it's not their main job Thanks. Thanks Nick. Uh, that's that's that sounds really exciting. I'm looking forward to see uh, to see more of how our project Contour continues. Um, well, that that's that's my our that's our last question Does anyone have any final thoughts they want to add before we uh, we close that All right Well, uh, thanks everyone for joining us. Uh, want to thank our panelists and also everybody else who's taking their time to To uh, to to spending the time with us. Um Yeah, I hope everyone enjoys the rest of OpenShift Commons and have a great day