 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon North America 2020, virtual, brought to you by Red Hat, the CloudNative 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, Software Development Engineering for MasterCard and he's a founding member of the CNCF, the CloudNative Computing Foundation. Ken, great to see you. Yeah, great, thank you for having me. I've enjoyed theCUBE over the years and I'm glad to be part of it again. Yeah, so 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 have been on in LA a couple of years ago where I was kind of drifting around that show. I don't think I 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, you know, 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, you know, CloudNative. Certainly it's a good place to be. Yeah, yeah, definitely. It's been a great ride. You know, in our industry, we go through these sort of time frames every decade or so where something big kind of comes along and you get involved in it 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 CloudNative itself, you know, 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, you know, configurations, of doing management of infrastructure and it really needed something different and something to kind of help, you know, it's called orchestration, of course, but you know, at the time, we didn't know it was called orchestration, right? We knew we needed, you know, things like service mesh, but they weren't called service meshes then. They were, you know, more like control planes and how do you kind of custom create all of these different pieces? And the great thing about, you know, the CNCF is that when we started it, we had very simple, you know, foundational principles we wanted to follow, right? One was we wanted to have end users involved. A lot of foundations, as you know, become very vendor driven and very vendor centric and you kind of lose your core base of the practitioners, as you call us, right? That the guys who actually need to solve problems and are trying to make a living, you know, solving problems for the industry, not just selling products, right? And so it was important that we get those end users involved and that's probably the biggest change is it's a great technology body. It's, we had great technologists, great engineers and the foundation, but we also have a huge over 150 end users that have been engaged and been very involved and contributing to the end users. The end user contributing to the foundation now and it's been awesome to see that come to fruition over the last three years. Yeah, it's certainly part of the magic of open source that's been so transformative. And, you know, we've seen that obviously with servers and Linux and what that did, but we've been talking a lot lately too about kind of the anniversary 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 because 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, you know, 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 app person, you got to build something that fits into this. Now with an app centric world is 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 that was the big missing piece for all those years was how do you get to this dynamic environment, right? That embraces change, embraces risk to some extent, not risk like you've heard in the past with risk avoidance is so important to have, right? It's really more how do you embrace risk and fall 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 caught as much as you could in the earlier phases of your development life cycle and that's been, like you said, that dynamic piece has just been such the difference I think in why it's been taken off in the industry this last five years now that we've been around. Yeah, for sure. So then the next one, I'm just going to go through there's three kind of main tenets of this thing. These techniques enabled loosely coupled systems that allow engineers to make high impact changes frequently and predictably with minimum toll. I mean, 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 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 technologists, 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. 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 VMs 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. It is. And open source, there were discussions about open source for 20 plus years, trying to get more into open source, intruding the open source in an enterprise mindset. And it could never really take off because 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 says, here's the set of democratized, we're not gonna have king makers in this organization. We're gonna have a lot of open solutions, a lot of good options for companies to look at. And we're not gonna lock you in to anything because that's another piece of that open source model. Open source still can lock you in, right? But if you have open choices within open source, there's less lock in potential. And lock in 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 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 joke about open stack, right? If I have to email two guys, if I find an issue in open stack 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 keeping it kind of high level here, because one of the things 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 a ton of regulation, but still you're asking how and you're asking why. Definitely, and those are the two questions that I keep coming back to in the industry because they're not asked enough in my opinion. I think for the reasons you brought up, there's too much pushback or there's a, you don't want to be viewed as someone who's being difficult, right? And there may be other reasons why you don't want to ask that, but I like to ask the why first because 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 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 DSUC 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 to ask, kind of find out where in this path there's a problem. And the guy tells me 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 cleaning crew had come through and unplugged it. And so I learned early on in my career 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 HUD 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 because it may take you 20, 30 minutes to kind of do a good analysis of a problem, but then your solution, you're not gonna spend weeks trying to troubleshoot when it doesn't work because you put the time up front 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 wanna be in 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? 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 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 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 was a, when I had younger kids, I always laughed because I put these warnings on those, I don't know what they call them, but the kids stand up in them. Right, the little, the little pruners. 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 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, I don't think it's that dangerous of a situation 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, model it to go forward. Right, right. No, we have a rule around here too. It's the reason we have every rule is because somebody blew it at some point in time. That's why we have the rule. I want to shift gears a little bit and talk about automation, right? Because automation is such a big and important piece of this whole story, especially as the system scales, scales, scale. And we know that people are prone to errors. I mean, I had seen that story about the cleaner accidentally unplugging. 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 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, as you've heard me say before, is 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 you point always a fat finger or someone deleted an IP address from the IPAM system. There's all kinds of errors that 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 is code or software defined infrastructure, right? So the networking teams and the storage teams and the security teams are probably the furthest behind and adopting automation in their jobs, right? And their jobs are probably the most critical pieces of your infrastructure, right? And so those are pieces that I really highly encourage them to think about how can they automate those areas. The second piece that 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 tens to 20%, right? And your test coverage is a direct correlation to how well your application is going to behave in production in terms of failures, right? So if you have low test coverage, you're gonna have high failure rates. It's sort of 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 thinking through your user stories and the acceptance criteria and having good test coverage 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 GUI metal 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 metal piece can become really a problem from a security and from a availability issue. And so those are the two pieces that I say really focus on is that, that GUI metal 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 retro, to retrospectives, to not necessarily a postmortem, which I thought is interesting to say retrospective versus a postmortem, because this is an ongoing process for continuous improvement. And then finally, what seems, you know, 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 the, you know, that culture we want to create in a cloud native world, right? We want to be open to, you know, thinking about how we can solve problems better, how we can have minimal, more, you know, each iteration we want to look at, how do we have less toil, have less issues? How do we improve the, I like to hide the light in your experience. How do you make your developers and your customers, 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, you know, 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 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? You may, they may, you know, they'll hold adage, I like users, you know, 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 curve 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 curve 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 or maybe a 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 works out in the schedule, but actually put that in your calendar, 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 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 an engineer's goal, right? We'd never like to fail, we never like to do something twice, right? We don't wanna, we wanna 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 because I've been part, not at MasterCard, but other companies, parts of companies that will 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 investigate 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 gotta deliver iteratively. If you don't, the point I like to always make is you're never gonna be ready, right? It's like, when are you ready to have kids? You're never ready to have kids, right? You just have to go and you go learn as you go. You know, so. I love that. Well, again, can you have so much great stuff out there for technical people that wanna dive in deep? So I encourage them just to do a simple YouTube, or excuse me, YouTube search or Google search, but I wanna give you the last word. One word, I'm gonna 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. You know, where does that come from? And I just love that you keep reinforcing 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 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'm a developer by background, by trade today. I still develop, I still contribute to open source. And I've had this mantra, my pretty much my entire career is that you have to get into the weeds and understand what everyone's experiencing in order to figure out how to solve the problems. You can't be in an ivory tower and look down and say, oh, there's a problem, I'm gonna 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 they're not gonna be helpful, they're not gonna be thankful that you solved the problem they don't have, right? They want you to solve the problem that they have. And so I think 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 two organizations out there and all of the in the world. So CNCF has been great. It's still growing. We're always looking for end users. I'd love to talk to you or you can reach out 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 are a community within the CNCF that is not, there'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 wanna 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 I hear the support that end user community any way we can. So thanks again for having us and looking forward 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.