>> Presenter: From around the globe, it's theCUBE, with coverage of KubeCon and CloudNativeCon North America 2020 Virtual. Brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Hey, welcome back everybody, Jeff Frick here with theCUBE. We're coming to you from our Palo Alto Studios with our ongoing coverage of KubeCon + CloudNativeCon 2020, the digital version. It would have been the North American version but obviously everything is digital. So we're excited, we've been coming back here for years and we've got a founder of CNCF and also a practitioner, really great opportunity to get some insight from someone who's out in the field and putting this stuff into work. So we're joined in this next segment by Ken Owens. He is the Vice President of Software Development Engineering for MasterCard, and he's a founding member of the CNCF, The Cloud Native Computing Foundation. Ken, great to see you. >> Yeah, great. Thank you for having me, I have, I've enjoyed theCUBE over the years and I'm glad to be a part of it again. >> Yeah, so we're, we're psyched to have you on, and I think it's the first time I've got to talk to you. I think you might've been on in LA a couple of years ago, or I was kind of drifting around that show. I don't think I was a it was on the set that day, but before we jump into kind of what's going on now, you were a founding member of CNCF. So let's take a step back and kind of share your perspective as to kind of where we are now from where this all began and kind of this whole movement around Cloud Native. Certainly it's a good place to be. >> Yeah, yeah definitely. It's been a great ride. In our industry, we go through these sort of timeframes every decade or so, where something big kind of comes along and you get involved in and you participate in it. And it gets to be a lot of fun and it either dies or it evolves into something else, right? And with CloudNativeCon Cloud Native itself, this concept of just how difficult it was to really move with the type of agility and the type of speed that developers in the enterprise really need to move at. It was just, it was hard to get there with just traditional infrastructure, traditional ways of doing configurations of doing management of infrastructure and it really needed something different and something to kind of help, it was called orchestration of course but at the time we didn't know it was called orchestration right. We knew we needed things like service mesh, but they weren't called service meshes then. There were more like control planes. And how do you, how do you custom create all of these different pieces? And the great thing about the CNCF is that we, when we started it, we had very simple foundational principles we wanted to follow right. One was, we wanted to have end users involved. A lot of foundations as become very vendor-driven and very vendor-centric. And you kind of lose your, your core base of the practitioners as you call us right? The guys who actually need to solve problems they're trying to make a living solving problems for the industry, not just for selling products, right? And so it was important that we get those end users involved and that, and that's probably the biggest changes. It's a great technology body. We had great technologists, great engineers and the foundation but we also have a huge over 150 end users that have engaged and been very involved and contributing to the end users things of the community, contributing to the foundation now. And it's been awesome to see that come to fruition over the last three years. >> Yeah, it certainly part of the magic of open source, that's been so, so transformative. And we've seen that obviously with servers and Linux and what what that did, but we've been talking a lot lately too about kind of the anniversary of the of the Agile Manifesto and kind of the Agile Movement and really changing the prioritization around change and really making change a first class citizen as opposed to kind of a nightmare I don't want to deal with and really building systems and ways of doing things that adopt that. I want to just to pull up the Cloud Native definition 'cause I think it's interesting. We talk about Cloud Native a lot and you guys actually wrote some words down and I think it's worth reading them that Cloud Native Technologies empower organizations to build and run scalable applications in dynamic environments. Dynamic environments is such a key piece to this puzzle because it used to be, this is your infrastructure person, you've got to build something that fits into this. Now with an app-centric world has completely flipped over and the application developer doesn't have to worry about the environment anymore, right? It's spin it up and make it available to me when I need it. A really different way of thinking about things than kind of this static world. >> Definitely and then that was the big missing piece for all those years was how do you get to this dynamic environment, right, that embraces change and embraces risk to some extent. Not risk like you heard in the past with risk avoidance is so important to have, right. It's really more, how do you embrace risk and fail earlier in the process, learn earlier in the process so that when you get to production you're not failing, you're not having to worry about failure because you cut as much as you could in the earlier phases of your development life cycle. And that's been set, like you said that dynamic piece has just been such the difference. I think in why it's been taken off. >> Yeah. >> And industry this last five years now that we've been around. >> Yeah, for sure. So then the next one well, I'm just going to go through them 'cause there's three main tenants of this thing. These techniques and techniques enabled loosely coupled systems that allow engineers to make high impact changes frequently and predictably with minimum toil. I mean, those are, those are really hard challenges in a classic waterfall way with PRDs and MRDs and everything locked down in a big, giant Gantt chart that fills half of the half the office to actually be able to have loosely coupled systems. Again a really interesting concept versus hardwired, connected systems. Now you're talking about APIs and systems all connecting. Really different way to think about development and how do you build applications. >> Yeah and the interesting thing there is the very first definition we came up with five plus years ago was containers, containerized workloads, right? And being technologist, everyone focused on those words containers and containerized and then everything had to be a container, right? And to your point, that isn't what we're trying to do, right? We're trying to create services that are just big enough to support whatever is needed for that service to support and be able to scale those up and down independently of other dependent systems that may have different requirements associated with what they have to do, right. And it was more about that keeping those highly efficient type of patterns in mind of spinning up and spinning down things that don't have impact or cause impact to other larger components around them was really the key not containers or containerized. >> Right. >> Obviously that's one of the patterns you could follow to create those types of services and those patterns, but there is nothing that guarantees it has to be a container that can do that. Lots of BMS today and lots of Bare Metal Servers can have a similar function. They're just not going to be as dynamic as you may want them to be in other environments. >> Right and then the third tenant, three of three is fostering sustainable ecosystem of open source vendor neutral projects, democratizing state-of-the-art patterns to make these innovations accessible for everyone. So just the whole idea of democratization of technology, democratization of data, democratization of tools, to do something with the data to find the insight democratization of the authority to execute on those decisions once you get going on that, I mean the open source and kind of this democratization to enable a broad distribution of power to more than just mahogany row, huge fundamental shift in the way people think about things. And really even still today, as everyone's trying to move their organizations to be more data-centric in the way they operate, it is really all about the democratization and getting that information and the tools and the ability to do something with it to as broad a group of people as you can. And that's even before we talk about open source development and the power of again, as you said, bringing in this really active community who want to contribute. It's a really interesting way that open source works. It's such a fun thing to watch, and I'm not a developer from the outside, but to see people get excited about helping other people. I think that's probably the secret to the whole thing that really taps into. >> Yeah, it is. And open source, there were discussions about open source for 20 plus years trying to get more into open source contributing to open source in an enterprise mindset, right? And it could never really take off 'cause it's not really the foundation or the platforms or the capabilities needed to do that. And now to your point, open source was really the underlying engine that is making all of this possible. Without open source and some of those early days of trying to get more open source and understanding of open source in the enterprise, I think we'd still be trying to get adoption but open source had just gotten to that point where everyone wanted to do more with open source. The CNCF comes along and said, here's the set of democratized, we're not going to have kingmakers in this organization. We're going to have a lot of open solutions, a lot of good options for companies to look at, and we're not going to lock you in to anything. 'Cause that's another piece of that open source model, right. Open source still can lock you in, right. But if you have open choices within open source, there's less, lock-in potential and locking isn't really a horrible thing. It's just one of those tenants you don't want to be tied too tightly to any one solution or one hope, open source even program because that could 'cause issues of that minimal toil we talked about, right. If you have a lot of dependencies and a lot of, I always joked about OpenStack but if I have to email two guys, if I find an issue in OpenStack about security that's not really a great security model that I can tell my customers I have your security covered, right? So, you want to get away from emails and having to ask for help, if you see a big security issue you want to just address it right then and fix it fast. >> Right, right. So much to unpack there. And for those that don't follow you, you've done a ton of presentations. You've got a ton of great content out of the internet with deep technical dives, into some of this stuff and the operational challenges in your philosophies but good keeping it kind of high level here. 'Cause one of the themes that comes up over and over in some of the other stuff I saw from you is really about asking the right questions. And we hear this time and time again, that the way to get the right answer first you got to frame the question right. And you talk quite extensively about asking the why and asking the how. I wonder if you can unpack that a little bit as to why those two questions are so important and how do you ask them in a way that doesn't piss everybody off or scare them away when you're at a big company like MasterCard that has a lot of personal information, you're in the finance industry, you got ton of regulation but still you're asking how and you're asking why. >> Yeah, definitely. And those, those are two questions that I keep coming back to in the industry because they are, they're not asked enough in my opinion. I think they, for the reasons you brought up those there's too much pushback or there's, you don't want to be viewed as someone who's being difficult, right? And there maybe other reasons why you don't want to ask that but I like to ask the why first because it, you kind of have to understand what's the problem you're trying to solve. And it kind of goes back to my engineering background, I think right. I love to solve problems and one of my early days and you might have heard this on one of my, my interviews, right. But in my early days, I was trying to fix a problem that I was on an advanced engineering team. And I was tier four support in a large Telco. And for months we had this issue with one of our large oil based companies and no one could solve it. And I was on call the night that they called in. And I asked the guy a simple question, tell me which lights you see on this DHUC issue? Which is a piece of equipment that sits between a ATM network and a regular Sonnet network. So we're watching, I'm asking them as kind of find out where in this path, there's a problem. And the guy tells me where there's no lights on. And I'm like well, plug in the power and let me know when it boots up and then let's try another test. And that was the problem. So my, the cleaning crew would come through and unplugged it. And so I learned early on in my crew that if you don't ask those simple questions, you just assume that everything's working almost nine times out of 10, it's the simple, easy solution to a problem. You're just too busy thinking of all the complex things that could go wrong and trying to solve all the hard problems first. And so I really try to help people think about, ask the why questions, ask, why is this important? Why do we need to do this now? Why, what would happen if we don't do this? If we did it this other way, what's the downside of doing it this other way? Really think through your options, 'cause it may take you 20, 30 minutes to kind of do a good analysis of a problem, but then your solution you're not going to spend weeks trying to troubleshoot when it doesn't work because you put the time upfront to think about it. So that's sort of the main reason why I like to ask the why and the how, because it forces you to think outside of your normal, my job is to take this cog and put it over here and fix this, right. And you don't want to be in that, that mode when you're solving complex problems because you overlook or you miss the simple things. >> Right. So you don't like the 'cause we've always done it that way? (both laughing) >> I do not. And I hear that a lot everywhere I've been in the industry and anywhere, any company you have those, this is the way we've always done it. >> Yeah, yeah. Just like the way we've always traveled, right. And the way we've always been educated and the way we've always consumed entertainment. It's like really? I wanted to (indistinct) >> I have learned though that there's a good, I like to understand the reason behind why we've always done it that way. So I do always ask that question. >> Right. >> I don't turn around on someone and get mad at them and you say, Oh, we can't we have to do it differently. I don't have the mindset of let's throw that out the window because I realized that over time something happened. It's like when I had younger kids, I always laugh because they put these warnings on those whatever they call them at the kids stand up in them. >> Right, the little, the little (indistinct) >> Don't put them on top of the stairs right. These stupid little statements are written on there. And I always thought I was dumb. And if somebody told me, well that's because somebody put their kid near the pool and they drown. >> Right, right. >> You have to kind of point out the obvious to people and so, >> Yeah. >> I don't think it's that dangerous of a situation and in the work environment, but hopefully we're not making the same mistakes that have been prevented by not allowing just the, not because we've done it this way before modeled it to go forward. >> Right, right now we have a rule around here too. There's a reason we have every rules is because somebody blew it at some point in time. That's why we have the rule that I want to shift gears a little bit and talk about automation, right? 'Cause automation is such a big and important piece of this whole story especially as these systems scale, scale, scale. And we know that people are prone to errors. I mean, I had seen that story about the cleaner accidentally unplugging things. We all know that people fat fingers, copy and paste is not used as universally as it should be. But I wonder if you could share, how important automation is. And I know you've talked a lot about how people should think about automate automation and prioritizing automation and helping use automation to both make people more productive but also to prioritize what the people should be working on as well as lowering the error rate on stuff that they probably shouldn't be doing anyway. >> Exactly, yeah automation to me is, as you've heard me say before is it's something that is probably almost as big of a key tenet as open source should be, right? It's one of those foundational things that it really helps you to get rid of some of that churn and some of the toil that you run into in a production environment where you're trying to always figure out what went wrong and why did this system not work on this point in time and this day and this deployment, and it's almost to your point always a fat finger, someone deleted an IP address from the IPAM system. There's all kinds of errors that you can people can tell you about that have happened. But to the root of your question is automation needs to be thought about from three different primary areas in my view, in my experience. The first one is the infrastructure as code, software defined infrastructure, right. So the networking teams and the storage teams and the security teams are probably the furthest behind in adopting automation in in their jobs, right. And their jobs are probably the most critical pieces of the infrastructure, right? And so those are, those are pieces that I really highly encouraged them to think about how can they automate those areas. The second piece is I think is equally as important as the infrastructure piece is the application side. When I first joined multiple enterprises in the past, the test coverage is in the low 10's to 20%, right. And your test coverage is a direct correlation to how well your application is going to behave and production in terms of failures, right? So if you have low test coverage, you're going to have high failure rates. It's sort of over over all types of industries every study has shown that, right. So getting your test coverage up and testing the right things not just testing to have test coverage right. >> But actually. >> Right, right. >> Thinking through your user stories and acceptance criteria and having good test is really, really important. So you have those two bookends, right. And in between, I think it's important that you look at how you connect to these services, these distributed systems we talked about in the opening right. If you fully automate your infrastructure and fully automate your application development and delivery, that's great. But if in the middle you have this gooey middle that doesn't really connect well doesn't really have the automation in place to ensure that your certificates are there that your security is in place. That middle piece can become really a problem from a security and from a availability issue. And so those those are the two pieces that I say really focus on is that gooey middle and then that infrastructure piece is really the two keys. >> Right, right. You've got another group of words that you use a lot. I want you to give us a little bit more color behind it. And that's talking to people to tell them that they need to spend more time on investigation. They need to do more experimentation. And then and the one that really popped out to me was it was retro to retrospective to not necessarily a postmortem which I thought is interesting. You say retrospective versus the postmortem, because this is an ongoing process for continuous improvement. And then finally, what seems drop dead dumb obvious is to iterate and deliver. But I wonder if you can share a little bit more color on how important it is to experiment and to investigate and to have those retrospectives. >> Yeah definitely. And then it kind of goes back to that culture we want to create in a Cloud Native world, right. We want to be open to thinking about how we can solve problems better, how we can have each iteration we want, to look at, how do we have a less toil, have less issues. How do we improve the, I liked kind of delight in your experience, how do you make your developers and your customers specific, but specifically how do you make your customers so happy with your service? And when you think about those sort of areas, right. You want to spend some portion of your time dedicated to how do I look at and investigate better ways of doing things or more improvements around the way my customer experience is being delivered. Asking your customers questions, right. You'd be surprised how how many customers don't ever get asked for their opinion on how something works, right. And they want to be asked, they'd love to give you feedback. It doesn't necessarily mean you're going to go do it that next iteration, right? The old adage I like to use is if Henry Ford had listened to his customers he would have tried to breed a faster horse, right? And so you have to kind of think about what you want to try to deliver as a product and as an organization but at the same time, that input is important. And I think, I say carve it out, because if you don't, we're so busy today and there's so much going on in our lives. If you don't dedicate and carve out some of that time and protect that time, you will never get to that, right. It's always a, I'll get to that next year. Maybe our next iteration I'll try, right. And so it's important to really hold that time as sacred and spend time every week, every couple of weeks, whatever it works out in the schedule, but actually put that in your calendar and block out that time and use it to really look at what's possible, what's relevant, what kind of improvements you can have. I think those are really the key the key takeaways I can have from that piece of it. And then, the last one you asked about, which I think is so important, is the retrospective, right. Always trying to get better and better at what you do is, is an engineer's goal, right? We never liked to fail. We never liked to do something twice, right? We don't want to, we want to learn the first time we make a mistake and not make it over and over again. So that those retrospectives and improving on what you're doing iteratively. And to the point you brought up and I like to bring this up a lot, 'cause I've been part not at MasterCard, but at other companies parts of companies that would talk a great game come up with great stories, say here's our plan. And then when we get ready to go to deliver it, we go and we reinvestigate the plan and see if there's a better plan. And then we get to a point where we're ready to go execute. And then we go back and start all over again, right. And you've got to deliver iteratively, if you don't, you're the point I like to always make is you're never going to be ready, right. It's like, when are you ready to have kids? You never ready to have kids, right. You just have to go and you'll learn as you go. You know so. >> Right, right, I love that. Well again, Ken, you have so much great stuff out there for technical people that want to dive in deep? So I encourage them just to do a simple YouTube or excuse me, YouTube search or Google search but I want to give you the last word. One word, I'm going to check the transcript when this thing is over that you've used probably more than any other word while we've been talking for the last few minutes is toil. And I think it's really interesting that it brings up and really highlights your empathy towards what you're trying to help developers avoid and what you're trying to help teams avoid so that they can be more productive. You keep saying, avoid the toil, get out of the toil, get out of this kind of crap that inhibits people from getting their job done and being creative and being inventive and being innovative. Where does that come from? And I just love that you keep reinforce it and just kind of your final perspective as we wrap on 2020 and another year of CNCF and clearly containers and Kubernetes and Cloud Native is continues to be on fire and on a tear. I just wonder if you can share a little bit of your perspective as a founding member as we kind of come to the end of 2020. >> Yeah definitely. Thanks again for having me. It's been a great, great discussion. I am a developer by background, by trade today, I still develop. I still contribute to open source and I've had this mantra pretty much my entire career that you have to get into the weeds and understand what everyone's experiencing in order to figure out how to solve the problems, right. You can't be in an ivory tower and look down and say, Oh, there's a problem, I'm going to go fix that. It just doesn't work that way. And most problems you try to solve in that model will be problems that no other team has really experienced. And there not going to be help, they're not going to be thankful that you solved the problem they don't have, right? They want you to solve a problem that they have. And so I think that that's sort of a key for the reason why I spent so much time talking about that as I live it every day. I understand it. I talk with my development community and with a broader community of developers at MasterCard and understand the pains that they're going through and try to help them every day with coming up with ways to help make their lives a lot easier. So it's important to me and to to all organizations out there and in all of the, in the world. So, CNCF its been great. It's still growing. I'm always looking for end users. I'd love to talk to you. Well, you can reach out to, to the CNCF if you'd like to learn more, our website has information on how to get connected to the end user community. We community within the CNCF that is not, it's a private community. So you don't have to worry about your information being shared. If you don't want people to know you belong to the community, you don't have to list that information. If you want to list it, you're welcome to list it. There's no expectations on you to contribute to open source, but we do encourage you to contribute, and are here to support that end user community any way we can. So thanks again for having us and looking forward to, to a great show in North America. >> All right well, thank you, Ken, for sharing your information sharing the insight, sharing the knowledge really appreciate it and great to catch up. All right. He's Ken, I'm Jeff. You're watching theCUBE with our ongoing coverage of KubeCon + CloudNativeCon 2020 North America Digital. Thanks for watching. We'll see you next time. (gentle music)

>> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon North America 2020 virtual brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Hi, and welcome back to theCUBE. I'm Joep Piscaer, I'm covering KubeCon CloudNativeCon here remotely from the Netherlands. And I'm joined by Commvault, Mathew Pearson, he's a Senior Product Manager, as well as David Ngo, Vice President of Metallic Products and Engineering to talk about the cloud native space and data protection in the Cloud Native space. So both, welcome to the show. And I want to start off with kind of the why question, right? Why are we here obviously, but also why are we talking about data protection? I thought we had that figured out. So David, can you shed some light on how, data protection is totally different in the cloud native container space? >> Sure, absolutely, thank you. I think the thing to keep in mind is that, containers are an evolution and a revolution actually in the virtualization space in the cloud space. What we're seeing is that customers are turning more and more to SaaS based applications and infrastructure in order to modernize their data centers and their data state in their compute environments. And when they do that, they're looking for solutions that match how they deploy their applications. And SaaS for us is an important area of that space. So, Metallic is Commvault portfolio of SaaS delivered and SaaS native data protection capabilities and offerings to allow customers to take the advantage of the best SaaS that is easy to try, easy to buy, easy to deploy, no infrastructure required and combine that with the technology and experience of Commvault. It'll build over last 20 years to deliver an enterprise grade data protection solution delivered as SaaS. And so, with Kubernetes and deploying in the cloud and modernizing applications I think that's very appealing to customers to also be able to modernize their data protection. >> Yeah, so I get the SaaS part. I mean, SaaS is an important way of delivering services. It is especially in the mid-market, something customers prefer, they want to have that simplicity, that easy onboarding as well as the OPEX of paying a subscription fee instead of longer term fees. So, the delivery model makes sense that fits into, the paradigm of making it simple, getting started easily. I get that, but Metallic isn't a traditional backup solution in that sense, right? It's not backing up necessarily just physical machines or just virtual machines. It has a relevance in the cloud native space. And the way I understand it, and please, if you can shed some light on that, Matt, is how is it different? What does it do that kind of makes it stand apart? >> Yeah, look, what we've found is the application developers can be in control now. So it's not like a traditional backup, that's what's changed. At this point, the application developer is free to create the infrastructure that he or she needs. And that freedom has meant that a bunch of stateful applications, the apps that we didn't think were going to live in Kubernetes have made their way to Kubernetes and they're making their way fast. So why is Metallic different? Because it's taking its lead from the developer. So it's using things like namespaces and label selectors. So basically take input from the developer on what information is important and needs to be protected and then protecting it. So it's your easy button to keep that Kubernetes development protected while you keep pace with the innovation within the organization. >> So you raise a valid point, cloud native has many advantages. It also has an extra challenge to account for which is fragmentation, right? In the olden days, let's call it that. We had a virtual machine, maybe a couple dozen that made up an application. And it was fairly easy to pinpoint the kind of the sort of conference of an application. This is my application. But now with cloud native, applications data can basically live anywhere. In a single cloud vendor, in many different cloud accounts, across different services, even across the public clouds themselves, like in a true multi-cloud scenario and figuring out what is part of an application in that enormous fragmentation is a challenge I think is understated and underestimated in a lot of operational environments with customers, with their applications in production. And that's where I think a product needs to figure out how to make sure an application is still backed up, is still protected in the way that is necessary for that given application. So I wonder how that works with Metallic. How do you kind of figure out what part of that enormous fragmentation is part of a single application? >> Yeah, so Metallic effectively integrates and speaks natively with the kube-apiserver. So it's taking its lead from the system of truth which is the orchestrator, which is Kubernetes itself. So for example, if you say everything in your production namespace needs protection, every night or every four hours, whatever that may be, it steps out and asks Kubernetes what applications exist there. It then maps all of the associated API resources associated with that application including the persistent volumes and persistent volume claims, man throws up and grabs the data from them as well. And that allows us to then reapply or reschedule that application either back to that original cluster or to another one for application mobility, where they are. >> So how do you make sure you, it kind of, what's the central point where everything comes together for that given application? Is that something the developer does as part of their release process or as part of their CICD? How do you figure out what components are part of an application? >> That is definitely a big challenge in the industry today? So, today we use label selectors predominantly. We find developers have been educating us on what works for them. And they've said, "Our CICD system is going "to label everything associated with this app, "as namespaced, then non-named space resources. 'So just here, take my label, grab everything under that, "and you will be good." The reality is that doesn't work for every business. Some businesses drop things into a specific namespace. And then you've got the added challenge that all of your data doesn't actually just live in Kubernetes. What about your image registries? What about it HCD? What about your Source Code Control and CICD systems? So we're finding that even VMs as well are playing a part in this ecosystem right now until applications can fully migrate. >> Yeah, and then let's zoom out on that a little bit. I mean, I think it's great that developers now kind of have flipped the paradigm where backup and data protection used to be something squarely in the OPS domain. It's now made its way into the .dev domain where it's become fairly easy to tag resources as application X, application Y, and then it automatically gets pulled into the backup based on policies. I mean, that's great, but let's zoom out a little bit and figure out, why is this happening? Why are developers even being put in a position of backing up their applications? So David, do you want to shed some light on that for me? >> Sure, I think data protection is always going to be a requirement and you'll have persistent data, right? There are other elements of applications that will always need to be protected and data protection is often something that is an afterthought, but it's something that needs to be considered from the beginning. And Metallic in being able to support deployments, not just in the cloud, but on-premises as well. We support any number of certified distributions of Kubernetes, gives you the flexibility to make sure that there was apps and that data is protected no matter where it lives. Being able to do that from a single pane of glass, being able to manage your Kubernetes deployments in different environments is very important there. >> So let's dive into that a little bit. I hear you say, Certified Kubernetes Distributions. So what's kind of the common denominator we need to use Metallic in an environment? Because I hear On-Prem, I hear public cloud. So it seems to me like this is a pretty broad product in terms of what it supports in its scope. But what's the lowest common denominator for instance, in the On-Prem environment? >> Sure, so we support all CNCF certified distributions of Kubernetes today. And in the cloud, we support Azure with AKS and AWS with EKS. So you can really use the one Metallic environment, the one interface to be able to manage all of those environments. >> And so what about that storage underneath? Is that all through CSI? >> Yes. So we support CSI on the backend of the Kubernetes applications, and we can then protect all the data stored there. >> And so how does this, I mean, you acquired Hedvig about a year ago, I want to say. Not sure on the exact date, but you acquired Hedvig a little while ago. So how does that come into play in Metallic offering? >> Sure, the Hedvig distributed storage platform is a fantastic platform on which to provision and scale Kubernates's applications and clusters. And that having full integration with Kubernetes on the storage side, we support that natively and really builds on the value that Commvault can bring as a whole with all of its offerings as a platform to Kubernetes. >> All right. So, zooming out just a little more, I want to get a feel for the cover of the portfolio of Commvault, as we're ushering into this cloud native era, as we're helping customers make that move and make that transition. What's the positioning of Metallic basically in the transformation customers are going through from On-Prem kind of lift and shift cloud into the cloud native space? >> Yeah, so with today's announcements, our hybrid cloud support and our hybrid cloud initiatives really help customers manage data wherever it lives as I've mentioned earlier. Customers can start with workloads On-Prem and start protecting workloads that they either have migrated or starting to build in the cloud natively and really cover the gamut of infrastructure and hypervisors and file systems and storage locations amongst all of these locations. So from our perspective, we think that hybrid is here to stay, right? There are very few customers who are either going to be all on-premises or all in the cloud. Most customers have some requirement that keeps them in a hybrid configuration, and we see that being prevalent for quite some time. So supporting customers in their transformation, right? Where they are moving applications from on-premises to the cloud, either refactoring or lift and shift, or what have you. It's very important to them, it's very important for us to be able to support that motion. And we look forward to helping them along the way. >> Awesome, so one last question for Matt. I mean, Metallic is a set of servers, right? That means you run it, you operate it, you build it. So I wonder, is Metallic itself cloud native? How does it scale? What are kind of the big components that Metallic has made up of? >> So Metallic itself is absolutely cloud native. It is sitting inside Azure today. I won't go into all the details. In fact, David could probably provide far more detail there. But I think Metallic is cloud native with respect to the fact that it's speaking natively to your applications, your cloud instances, your Vms. And then it's giving you the agility and the ability to move them where you need them to be. And that's assisting people in that migration. So in the past, we helped people get from P to V. Now that there are virtualized, applications like Metallic can protect you wherever you are and get you to wherever you need to be, especially into your next cloud of choice. And there's always another cloud. What I'm interested to see and what I'm hoping to see out of KubeCon is how are we doing with KubeVirt and Kubernetes becoming the orchestrator of the data center. And how are we doing with some of these other projects like application CRDs and hierarchical namespaces that are truly going to build a multi-tenanted software defined, distributed application ecosystem, that Metallic I can speak natively to via Kubernetes. >> Awesome. Well, thank you both for being with me here today. I certainly learned a ton about Metallic. I learned a lot about the challenges in cloud native that'll certainly be an area of development in the next couple of years. As you know, that the CNCF will continue to support projects in this space and vendors to work with us in that space as well. So that's it for now. I'm Joep Piscaer, I'm covering for KubeCon here remotely from the Netherlands. I will see you next time, thanks. (bright upbeat music)

>> Host: From around the globe, it's theCUBE, with coverage of KubeCon and CloudNativeCon North America 2020 virtual brought to you by Red Hat, the cloud native computing foundation and ecosystem partners. >> Hi everyone, I'm John Furrier with theCUBE. We are here covering KubeCon and CloudNativeCon North America 2020, November 17th to the 20th, a virtual event. Normally we're there in person, but again, 2020 has been a crazy year, we're not going to be able to be there in person, but we're here remotely. We have two great guests, the co-chairs of KubeCon and CloudNativeCon Stephen Augustus senior, open source engineer VMware KubeCon CloudNativeCon chair and Constance Caramanolis principal software here at Splunk and you guys are co-chairs of KubeCon. Big responsibility, thank you for coming on. >> Thank you. Thank you for having us. >> Thank you for having us. >> Okay so we, the number one question every year is before it gets started is, how did you make the selections for the talks, what's the hottest thing going on, what's the focus for this KubeCon? >> Well, so actually we use a Ouija board to choose the talks. (laughing) No, I'm joking it doesn't happen that way. >> Yeah, yeah, it's pretty much all out of a hat, but seriously, we spent a lot of time with talks that showed, I guess diversity and integration in the community. So, what projects are starting to pick up steam? What projects are starting to integrate more deeply with other ones? So you'll see lots of commentary around, multi cluster items within cloud native technologies, as well as, lots of content on security, which I'm excited about. >> Yeah, and also things are like, there's a little bit like, kind of to your point about like things layered on, like we're starting to get to the point where people are talking about like hey, I deployed Kubernetes and Envoy and something else. And like, these are starting to be a lot more of these kind of joint talks there that actually even make it harder for us to place. Like, does it belong in networking? Does it belong in application development? Like there've been some really good challenges trying to figure out where things are slotted and what's right- >> You know one of the things I love about KubeCon besides being fun to go to while it's face to face is even with the virtual, it's still a great community. The talks are awesome, people are submitting talks. But you got the sixth year, I think it's a six year or fifth year. We've been there for all years. I think this is the sixth year for us, the maturation, the growth and of Kubernetes now it's pretty clear. This glue layer, is gluing things together the API is extending to service and more services. Can you guys comment on what you guys are seeing in terms of some of the practical projects and how they're playing out for developers? Because you're starting to see you know, more clusters you've got cloud you've got multi-cloud around the horizon. So you've got more of these conversations where you have more capabilities but the focus on the modern application building is the number one business focus. So, you know, the developers are trying to build out under the covers and say, how do I scale this? So, this seems to be the kind of a growth year and inflection point for that next level. It seems like next level. Steven, what's your thoughts and reactions to that? >> Yeah absolutely. So, as a former, I've been out a few cloud native companies at this point so more or less from Red Hat before heading over to VMware. And as a former field engineer and solutions architects at some of these places, we spent a lot of time thinking through what is the days, zero day one story, right? And it's very clear that as a community, we've gotten to the point where like that is officially the boring stuff, right? Seeing a lot of the features within projects like (indistinct) and Cluster API come to maturation. We start to focus a lot more on that developer story, right? And ultimately that's what we care about, right? Businesses are not necessarily looking for a new tool to play around with, right? There are business goals that are tied to the new technologies, right? So the velocity in which you deploy your applications, the feedback loop in terms of understanding, you know, what ties into your application, where things are going wrong and, you know, Constance can definitely speak to the, the observability layer for all of these cloud native applications that are out there. >> Constance, observability I hear is really hot right now, what's your take on it, I mean is observability everywhere? New startup comes out and you work at Splunk, they're the King King of observability, they started out with very small observation space now it's a full platform. You have to look at the observation space to get the data that's the internet. >> You do. >> That's semi application. What's hot in observability? Take us through your thoughts. >> I think what's also starting to like, so you're still like, there's some, I can think of like one talk right now, it's a little bit talking about like, you know, observability at scale in a sense of just like now we have these massive applications and saying we globally and to observe and monitor observe right now, I'm not going to use a tourism changeable. I know that's a total different debate the available topic, but for now, just keep it at that. But it's also now, I think one thing as observability space and maturing is we're not talking only about like, hey, I instrument my like application with metrics, logs, traces, or some other thing there. It's now being a little bit more critical about how, if I'm using all three of these are all different telemetries, like how to be smart about it. Like, okay, I'll need to use traces for some things and let me use logs for something else. And like kind of getting to reach a part of like, now that we have that data let's actually think about better ways to use that data. So we don't, you know, collect everything cause you can't collect everything as much as we want to. >> Well, I mean this is something that I want to get your both thoughts on because one of the conversations we're hearing from developers and we hear it from them on the business size everything is a service, that's like the ivory tower you know, the CXOs, everything is as a service and then it down into the developers in the engineering community and they're like, well, it's not that easy 'cause you got tools for every platform, right? And that's a problem because these siloed tools are tools that were built for a certain products. And then you've got the systems thinking you guys talk about this integration is a key area. So making everything is as a service, just isn't that easy, right? So the goal is to make it easy, right? So this is the systems conversation. How do you guys look at that from a KubeCon, CloudNativeCon because cloud native does enable a lot of, good things. It's horizontally scalable cloud from a resource standpoint, you've got programmability. You can look at it as a system but people are stuck with these tools for the platform. I mean, you have tools for this, tools for that and five different tools, how do you make observability work? How do you make security work? These are tough questions. What's your reaction to that? >> I think that a lot of it comes down to, from a building perspective and, you know, taking the builder perspective and then also taking the consumer perspective. For builders, and I actually spent some time with, at some developer heads in New York, we sat down for a dinner and kind of talked, talked through some of the problems in the space. And I think what it really comes down to is when we build tools we need to think about who we're building the tools for, right? There are multiple personas that you might look at in the cloud native space. And, you know, one might be the persona of that systems integrator, of the classic Opsy, DevOps SRE role, right? Then you've got someone who may be building tools on top of one of those Ops platforms, right? And then you've got the consumers that may be in your company maybe they're external, right? That's for their experience, they're really only interested in how do I ship my app, right? So whether we're talking about building out Kubernetes or whether we're talking about a server less platform, right? So sort of Alyssa and the cloud, right? You often hear the, it runs on, it's running on someone else's machine, right? You know, it's not really, so I think in that space you have to consider a developer experience, right? So I think one of the overarching themes that you'll see throughout this KubeCon is, how do we talk about the developer experience? Who are we building these tools for? How can we actually get outcomes that end users are looking for? Right, cause it's not, again, it's not about the tools it's about the outcomes for the respective businesses. >> Constance what's your reaction to this trend of tools. >> I think. >> Edge computing, 'cause you you don't want to have to build security for everything, single thing. I've got an edge device, I want to have that'd be software operated, right? It makes total sense. But making that happen is hard. >> Yeah, I think this is something that as a community like we're really, I guess like kind of how I use example like end user docs versus restaurants documentation. I think that we've been, done a really good job at creating these really powerful tools but like in terms of, we still need to simplify them for anyone who doesn't want to learn, like say Kubernetes or Envoy or open telemetry, like the back of their hand. And I think that's where we're starting to finally start to close that gap. And as I think also why KubeCon is getting a lot more popular is like now things are a little bit more accessible to those who don't have, you know, either don't have the bandwidth or it just it isn't in their interest to learn all these things in details. And so we're slowly going from those who want to be deep, deep experts into, yeah I kind of want to play around with it and make it more manageable. And, I do think we still have quite a bit of ways to go. Like I think, you know, what's been helpful like at least like our end user stories that we get and like the application development track, especially that one, like the case studies that there's no longer track but it is highlighted as like these talks and case studies. I think that shows it's kind of giving people more like, hey, these are stories of how I can take these tools and start making them more digestible in my own way. 'Cause going from like, oh, this feature does XYZ to, this is a whole story that you can do around it. It's been a little very gap, we're closing. >> Yeah, and I think one of the things about you kind of being shy there, I'll say, KubeCon, CloudNativeCon, CNCF in general has been very successful because of the end user focus I will say that. But also the ecosystem of the vendors that are there. So you have kind of the best of both worlds and they'll want to get better, right? So, but they al have to make money at the same time. So you have this balance, is open source, is what it is, it's out in the open. Can you guys comment on how the community is thriving and surviving? We're in a tough time with the pandemic. It's been a big challenge honestly, we're not in person we're remote. How is everything going with the community? Because it's such a great end user vendor community working together out in the open shipping code, trying to make things better. What's the state of the community? >> Yeah, so I would say that honestly, what it comes down to is that word community, we're all friends, right? There are people who, you know, as the, as we moved towards is kind of like cloud native consolidation of companies. A lot of us have worked together before, right? A lot of us are active in multiple communities and what comes out of that is really open and honest collaboration as a result. You know, even today there's a Twitter thread going, you know, I started talking about the Kubernetes release cadence, right? And if, and how it should change. Given 2020, we had an extended release cycle for 119, right? And questions became, what do we do? Like, do we continue with three releases a year? Do we try for, to do the switch back to four? Like, what does that look like? Right. And reaching out across the Kubernetes community across the CNCFC, the contributor strategy saying in CNCF and getting feedback from all of these people who depend on the products that we build day to day is huge. So I think what it comes down to really is, is open and honest collaboration. I think, you know, when you were strained I know that everyone has a lot going on in life right now. What's great about it is being forthcoming with that, right? We have all of these teams that are, that are built to support the people that are around them. So, if anything, I, you know, I'd love to see all of the collaboration and feedback coming from everyone who works on these projects day to day. >> Yeah. >> Constance what's your reaction? I mean when, I've talked of some developer friends of mine, they're like, hey, this is great, I can work virtually, I've been doing it for years anyway. So no big deal. It's not like the people who have to go to the office every day. So they're used to virtual format. The other comment was, I get more time to do some gaming too. Trying to make light out of the bad situation, but you know, it is serious. What's your reaction to the survival and the thriving continue thriving of the community? >> Yeah, I also want to eventually go back to cause you're making a comment about vendors and now this is my first time as vendor. I have interesting, I like, it's a really interesting perspective to come from, but let's talk about the community. I think like, you know, it's like one of the things that like I think actually has been one of the highlights of this year for me, for 2020, it like to be co-chair but it's also just to like be able to work with Stephen and Nancy and the rest of the CNCF community. And also like any attendees, like has actually even though this is a big year of change and it's, you know, it was a change that no one was planning. It has definitely been like really nice to just get like Kube, I guess would say as an example, the story like for KubeCon you, like I was surprised at how many people were engaged in the Slack channel and asking questions and like Priyanka has set up these happy hours and people are just joining and we're starting to talk and so it wasn't quite hallway track but we still had that connection. And there was definitely, there are people who are attending from all parts of the world. And I thought that was really nice. Like, we think CNCF has made it, like they have made the statement before that there will always be a virtual component to it to address the fact that, you know, our community we're so used to being in person, but that does, you know it does reduce accessibility to those who can't travel or for whatever reason they can't be there in person. So now it is becoming more open. And, I know, I mean kind of turning back a little bit a little bit derail, I'm a little bit derailing but to your point about like also like the vendors. And so this is my first time being a part of a vendor. And I think what's really interesting is like, there's this natural like, you know, tension between like, oh, some were like, oh, I don't want to do it from the vendors, or like, I only want things from end users. But I think the thing that I've kind of forget is that both of them are like active, you know, they're active in the community, both in either contributing or enabling others to be successful using CNCF projects. And so we all have, you know, valid points and perspectives on it really. You can maybe sometimes argue that sometimes being a vendor is almost a bonus because you get to talk to maybe more people who are trying to adopt the technology and you get to see trends. And then after as an end user, you could say like, hey, I have this really unique problem here and this is how I try to solve it and share that story with other people, so. >> Yeah, I mean, I think you're right. I mean, there's checks and balance I've observed over my years in open source you've seen certain things thrive certain ways. And I think that balance and, but having the mission and kind of a rules of engagement if always seen well, good, worked well for CNCF they embraced the vendors really well, but they're, I mean I will say paranoid cause that's my word. But like they're paranoid of the vendors I would be too, like, you know, only to get their fingers in the pie, but they're also contributing. So there's always been that checks and balance and that's, what's been magical I think about it is that they fostered the community, they fostered the engagement and they fostered that balance. And I think that's where the give and get comes in. And I think that's a healthy community and I just love to see and love to be involved with. So, it's super, super good approach. Now, putting back the vendor hat on, if I'm a vendor, I want a competitive advantage. So yeah, this brings us to the next gen conversation open source goes and going next gen, you're seeing a big focus on AI, you're seeing a big focus on, you know, edge computing which is going to be software operated, software defined, which cloud native will lead. I got to get your perspective on something. Steven said at the top was security. Every conversation for the past five months with Dave has been shift left. So, okay. Where are we going left? We're shifting left. This is about security. How do you build security in? This has been a big conversation. It's not easy problem. I know it's a top focus. I want to get your reactions Steve and we'll start with you then Constance I would like you to weigh in too. >> Yeah sure, so, security, security is already strict, right? And I think that people start to put the focus on security when it's a little too late, right? The move is always preventative as opposed to reactive, right? And security is an onion, right? So it's not enough to just think about security on one axis, right? It's, you know, how is this affecting, you know, how is this affecting my application, the systems that I build, the physical, you know, the physical restraints of the, you know, of the area, right? Infrastructure, the cloud providers that I'm running on, right? Are they a certain level of compliant, right? Especially when that comes up for federal customers, right? On the application side, right? You know, if you think of, you know, if you think of all the, the different ways that you can break an application that hurts security now with the cloud native space container security, right? Am I building a safe Docker files or build packs or what have you, however you package your application. And ultimately you have to, you know and then there's also the supply chain, right? Am I getting, how am I moving that stuff from some physical infrastructure or some cloud infrastructure into the hands of the developers, into the hands of the customers? How do I react to changes once those applications have actually been deployed? Right? So like all of these things to consider and when you look at that space, these are multiple teams, right? These are dozens and dozens of teams across, you know, multiple companies, right? You may not have, you may not have full control of your security story, right? So I think that, what, you know what you need to do is start the conversation internally about how we can build security at multiple layers, right? So some of the things that are kind of interesting to see pop up during this KubeCon and some of, you know, and some of the last ones, the continued work that's happening on OPA and Gatekeeper spiffy and Spire, right? And, you know, all of these, all these frameworks for authentication and authorization that are kind of cropping up, right? I think, you know, Spiffy and Spire really interesting story because, you know, the first thing that you think is I have these cloud native applications that I'm building and I also have these legacy applications, right? How can I build a bridge between the two? Right? And then you've also got things like, you know, service mesh, right? And you start to talk about service mesh and, you know, the security within applications that live inside a cluster or across cluster, right? And how you negotiate that. So tons of things to think about, and, you know, it's honestly going to it's honestly going to depend on where you are in your journey but I think that, you know, good security is only built by having the conversation and having the conversation across all teams and doing it before you get into trouble. >> Do it before you get in trouble have it baked in from the beginning, brush your teeth make sure you're all healthy. Constance your reaction, (laughing) your reaction. >> So I will say like, I am unfortunately one of those people that like security, well security is just not something that I guess going to say I find super exciting. And it mostly just because I, I really love observability and like service mesh and so I usually defer to the experts on that, but I do want to like, I guess plus when some of what Steven said, obviously using git hub, you know, terminology for plus and what you know, enhancing things like definitely started early and it, but I think, you know, start early, start a conversation. But I think we also need just be cognizant of like for any of the technologies, like if it's security say networking whatever, all of these things are behavior changes and just bucket more time than you think you're going to need. There's going to be so many roadblocks and especially when it comes like, especially when it comes to behavior changes. Like, if you're and behavior, but not like necessarily like a personal, but like, you know, technology behavior like you're used to sending things without MTLS, right? Or, you know, with our backs, things are going to fail and, you know, there's going to be that initial friction and so definitely trying to make this smooth as possible. >> Yeah, I mean, I think that's the focus I like to see more of which is having it be built in. So if you're really not into it, but you don't want to screw it up either so you want to be on top of it without doing it, right? That's the end game, right? That's what DevOps is about. So if you don't have programming infrastructure write code. So all these things, this is the trend this is the trend that we're seeing in cloud native. Can you guys share your thoughts this year on, on the most important stories that you think people should think about or lean into or at least look at for KubeCon? What are some of the things that attendees or people watching remotely or participating virtually or in the Slack channels, what should they pay attention to? >> So starting with, I think even with the last KubeCon and some of the products that have recently come out from certain vendors, we're starting to look a lot more at the, what is that conversion story for someone who is a classic CIS admin, right? Who may be learning all about cloud native technology for the first time, or how do we, you know, how do we welcome a new KubeCon attendee to the community? So I think one of the best things that we did was instantiate that's a one-on-one track, right? So with the one-on-one track, I think we got a bunch of great feedback. So we work to make sure that they were actually, we eliminated I believe we fully eliminated the lightning talks and work to include more one-on-one content as well as tutorials within this program. >> Constance, your reaction, Constance your reaction to thoughts on the most important story to pay attention to? >> I think it's more, right, cause, okay, I know this is like a common line that we say at KubeCon and like, you know, depends what group your on. But since so many more of our talks we're now talking about intersections between like, you know, using X and Y try to build Z, Zed. Oh my goodness I'm trying, I'm losing my Zeds. I think trying to like, you know looking for those talks that at least somewhat resonated like, hey, I've already talked to communities, let me see how I add Envoy. Like, trying to find those there because there's a lot more of that content now, right? Cause maybe you know, about like to even last KubeCon or like last KubeCon North America, a lot of the things were more focused on like one project, maybe a hint or you're just going to see more of these combinations. And so there are a lot more, there's a lot more of that content available for you to find. I'm doing two, three, maybe four, It's a lot of projects at once, adoptions and seeing how that works too. Oh yeah, one-on-one track has definitely been definitely like a great hit. I'm going to say, right? The first time it was launched and we got so many CFPs for one-on-one it was just amazing to see all these ways that people wanted to make KubeCon more accessible to everyone else who hasn't been a part of, you know. >> It's every year, it's every year the onboarding of new members of the community would be impressive. And having that tracker laddering or different ways to work as a community to help people along has been another thing I noticed you guys do really well on. There's a real camaraderie amongst the community. So a hat tip for you guys on that. Final question for you guys is more about the format. Obviously it's virtual this year the game is still the same. There's talks, there's people, there's hallways, but they're virtual, I guess you're virtually walking through Slack and discord or Twitter, whatever. What's the learnings from last event, as we're going into virtual, how does an attendee maximize their time, their engagement there's times to lean in and be present, attending a talk, you mentioned Slack Constance. What's some of the learnings that you guys have learned from virtual? And what can people think about and prepare for, for KubeCon virtual this year? >> Yeah, I think one way you start it. So, there's actually a resource, this came from our debrief for me, it was like there's a resource like, hey, let me help get the day off. And like, we even provided template to like provide to your, you know, direct to your managers. Say like can I please get this day off so I could focus on it? And I think that's one thing that and I think we'd all probably seen on Twitter and blogs is that even though it is virtual it is still a brain drain, well it's still, you know, you have to engage with a topic so set aside time. I would probably even say attend fewer talks, than you would normally do in person there is zoom fatigue, I guess it's been from on screen fatigue. So just give yourself a lot more space to consume the information and just debrief and also join the activities, right? Like ask questions in Slack. There's a lot of the virtual events like there's bingo there's even an escape room, which sounds like a lot of fun, all these different activities too that you can do with everyone. So like definitely enjoy that part, right? 'Cause you still get a little bit off until you just say like hey, you mentioned this project, let's chat offline. And then, you know, a few weeks later you may be on a four hour long Zoom meeting talking about some project. And so, yeah >> Yeah, I noticed the hang space kind of mindset of virtual was pretty cool. Be mindful to introduce yourself and either do a sidebar or jump on some back channel. I mean, there's plenty of tools, developers know what they are, so pretty good point I want to call that out. Good, good point Constance. Steven, your thoughts on learnings from the virtual format and then things this year people should pay attention to and jump in and use the site for. >> Yeah, so I would say if anything the previous attendees gave lots of thoughtful feedback about how to improve the overall program. One of my favorite parts of any conference and it's the part that I prioritize more than anything else in the conference even the talks, right? Is the hallway track, right? It's one of the few times, you know, especially with KubeCon and the various contributors across the cloud native space that's the, you know, the one time every quarter or so that I get an opportunity to see these people face to face, right? So, you know, we wanted to do our best to bring in experience that felt, you know, it's not the, you know, it's not the same as the physical hug, right? Or the, you know, or going out for, you know, going out for dinner after a long day. But we tried and we laughed through lots of crazy ideas that the event team, to see what they would come up with for me as a New York resident and having a conference that is any virtual but would have been in Boston, I thought it was important thinking about screen fatigue, as well as just the physicality of where people would have been at the time, is the start time of the conference, right? So as Constance was mentioning screen fatigue it's, I think with all of the virtual conferences going on, it's very hard to have that time during the day, right? So this KubeCon for folks on the East coast it starts basically at your lunchtime. So the idea is, hopefully you get some, you get some of your meetings in for the day, grab a bite to eat and then you sit down for lunch and you, and you dig into some KubeCon, so. >> Yeah, and you can have any lunch you want and then later of you will be able to eat lunch from the conference. That's awesome. The other thing I love about the, what you guys said is the hallway tracks. And I think one of the things I've noticed going to a lot of virtual events and doing them is, Constance you're right, it's mentally draining to lean into a talk because you're present, even though you're virtual. So taking time to get involved in the fun activities or just, you know, wandering Slack or doing a sidebar with the hallways is kind of a have some time off like the time to regroup and not be so, you know, leaned into a session, I find that to help on the fatigue side for sure. The other one is viewing parties. We popped into some, you know, Zooms together and we watched each other watch the session, right? So viewing parties has been one trick I've seen work well, other ones I've seen people toast beer at a certain time. The Germans obviously do at first, cause they're on the time zone, but you start to see these playful things. You know, people can share their kind of position where they are. So it's fun. We'll look forward to seeing that. Okay, final comments, Steven, Constance. What's the bumper sticker this year for KubeCon? >> Ooh, have we decided yet Constance? (laughing) >> Velvet jackets are required for entry. (laughing) I'll make word sense after you see a special message from us. (laughing) >> It's a lot of fashion on stage, on stage, right? >> All right we stumped the co-chairs. (laughing) We stumped the, well, I want to say thank you very much for coming on and sharing little color commentary on KubeCon around the program, some of the things when the virtual event too some of the talks, really appreciate it and we really appreciate what you do, the community does. It's been a hard year. We're not going to be there in person. We'll continue to ride the wave in to back to the normal. So thanks for doing what you doing and thank you for coming on. >> Thank you so much for having us. >> Yeah, thank you. >> Okay. This is theCUBE, virtual coverage of KubeCon CloudNativeCon virtual November 17th to the 20th. I'm John Furrier, your host for theCUBE. Thanks for watching. (upbeat music)