>> Announcer: From around the Globe, it's theCUBE with coverage of Kube Con and Cloud Native Con Europe 2021 virtual brought to you by Red Hat, the cloud native computing foundation and ecosystem partners. >> Hello, and welcome back to theCUBE's coverage of Kube Con and Cloud Native Con 2021 virtual. I'm John Furrier, host of theCUBE, here with a great guest, I'm excited to talk to. His company, that he was part of founding CTO, was bought by Red Hat. Ali Golshan, Senior Director of Global Software Engineer at Red Hat, formerly CTO of StackRox. Ali thanks for coming on, I appreciate it. Thanks for joining us. >> Thanks for having me excited to be here. >> So big acquisition in January, where we covered it on SiliconANGLE, You guys, security company, venture backed amplify Sequoya and on and on. Big part of Red Hat story in their security as developers want to shift left as they say and as more and more modern applications are being developed. So congratulations. So real quick, just quick highlight of what you guys do as a company and inside Red Hat. >> Sure, so the company's premise was built around how do you bring security the entire application life cycle. So StackRox focuses on sort of three big areas that we talk about. One is, how do you secure the supply chain? The second part of it is, how do you secure infrastructure and foster management and then the third part is now, how do you protect the workload that run on top of that infrastructure. So this is the part that aligned really well with Red Hat which is, Red Hat had wanted to take a lot of what we do around infrastructure, foster management configuration management and developer tools integrated into a lot of the things they do and obviously the workload protection part was a very seamless part of integrating us into the OpenShift part because we were built around cloud native constructs and obviously Red Hat having some of the foremost experts around cloud native sort of created a really great asset. >> Yeah, you guys got a great story. Obviously cloud native applications are rocking and rolling. You guys were in early serverless emerges, Kubernetes and then security in what I call the real time developer workflow. Ones that are building really fast, pushing code. Now it's called day two operations. So cloud native did two operations kind of encapsulates this new environment. You guys were right in the sweet spot of that. So this became quite the big deal, Red Hat saw an opportunity to bring you in. What was the motivation when you guys did the deal Was it like, "wow" this is a good fit. How did you react? What was the vibe at the StackRox when this was all going down? >> Yeah, so I think there's really three areas you look for, anytime a company comes up and sort of starts knocking on your door. One is really, is the team going to be the right fit? Is the culture going to be the right environment for the people? For us, that was a big part of what we were taking into consideration. We found Red Hat's general culture, how they approach people and sort of the overall approach the community was very much aligned with what we were trying to do. The second part of it was really the product fit. So we had from very early on started to focus purely on the Kubernetes components and doing everything we could, we call it sort of our product approach built in versus bolted on and this is sort of a philosophy that Red Hat had adopted for a long time and it's a part of a lot of their developer tools, part of their shift left story as well as part of OpenShift. And then the third part of it was really the larger strategy of how do you go to market. So we were hitting that point where we were in triple digit customers and we were thinking about scalability and how to scale the company. And that was the part that also fit really well which was obviously, RedHat more and more hearing from their customers about the importance and the criticality of security. So that last part happened to be one part. We ended up spending a lot of time on it, ended up being sort of three out of three matches that made this acquisition happen. >> Well congratulations, always great to see startups in the right position. Good hustle, great product, great market. You guys did a great job, congratulations. >> Thank you. >> Now, the big news here at KubeCon as Linux foundation open-source, you guys are announcing that you're open-sourcing at StackRox, this is huge news, obviously, you now work for an open-source company and so that was probably a part of it. Take us through the news, this is the top story here for this segment tickets through open-source. Take us through the news. >> Yeah, so traditionally StackRox was a proprietary tool. We do have open-source tooling but the entire platform in itself was a proprietary tool. This has been a number of discussions that we've had with the Red Hat team from the very beginning. And it sort of aligns around a couple of core philosophies. One is obviously Red Hat at its core being an open-source company and being very much plugged into the community and working with users and developers and engineers to be able to sort of get feedback and build better products. But I think the other part of it is that, I think a lot of us from a historic standpoint have viewed security to be a proprietary thing as we've always viewed the sort of magic algorithms or black boxes or some magic under the hood that really moved the needle. And that happens not to be the case anymore also because StackRox's philosophy was really built around Kubernetes and Built-in, we feel like one of the really great messages around wide open-source of security product is to build that trust with the community being able to expose, here's how the product works, here's how it integrates here are the actions it takes here's the ramifications or repercussions of some of the decisions you may make in the product. Those all I feel make for very good stories of how you build connection, trust and communication with the community and actually get feedback on it. And obviously at its core, the company being very much focused on Kubernetes developer tools, service manage, these are all open-source toolings obviously. So, for us it was very important to sort of talk the talk and walk the walk and this is sort of an easy decision at the end of the day for us to take the platform open-source. And we're excited about it because I think most still want a productized supported commercial product. So while it's great to have some of the tip of the spear customers look at it and adopt the open-source and be able to drive it themselves. We're still hearing from a lot of the customers that what they do want is really that support and that continuous management, maintenance and improvement around the product. So we're actually pretty excited. We think it's only going to increase our velocity and momentum into the community. >> Well, I got some questions on how it's going to work but I do want to get your comment because I think this is a pretty big deal. I had a conversation about 10 years ago with Doug Cutting, who was the founder of Hadoop, And he was telling me a story about a company he worked for, you know all this coding, they went under and the IP was gone, the software was gone and it was a story to highlight that proprietary software sometimes can never see the light of day and it doesn't continue. Here, you guys are going to continue the story, continue the code. How does that feel? What's your expectations? How's that going to work? I'm assuming that's what you're going to open it up which means that anyone can download the code. Is that right? Take us through how to first of all, do you agree with that this is going to stay alive and how's it going to work? >> Yeah, I mean, I think as a founder one of the most fulfilling things to have is something you build that becomes sustainable and stands the test of time. And I think, especially in today's world open-source is a tool that is in demand and only in a market that's growing is really a great way to do that. Especially if you have a sort of an established user base and the customer base. And then to sort of back that on top of thousands of customers and users that come with Red Hat in itself, gives us a lot of confidence that that's going to continue and only grow further. So the decision wasn't a difficult one, although transparently, I feel like even if we had pushed back I think Red Hat was pretty determined about open-source and we get anyway, but it's to say that we actually were in agreement to be able to go down that path. I do think that there's a lot of details to be worked out because obviously there's sort of a lot of the nuances in how you build product and manage it and maintain it and then, how do you introduce community feedback and community collaboration as part of open-source projects is another big part of it. I think the part we're really excited about is, is that it's very important to have really good community engagement, maintenance and response. And for us, even though we actually discussed this particular strategy during StackRox, one of the hindering aspects of that was really the resources required to be able to manage and maintain such a massive open-source project. So having Red Hat behind us and having a lot of this experience was very relevant. I think, as a, as a startup to start proprietary and suddenly open it and try to change your entire business model or go to market strategy commercialization, changed the entire culture of the company can sometimes create a lot of headwind. And as a startup, like sort of I feel like every year just trying not to die until you create that escape velocity. So those were I think some of the risk items that Red Hat was able to remove for us and as a result made the decision that much easier. >> Yeah, and you got the mothership with Red Hat they've done it before, they've been doing it for generations. You guys, you're in the startup, things are going crazy. It's like whitewater rafting, it's like everything's happening so fast. And now you got the community behind you cause you're going to have the CNC if you get Kubecon. I mean, it's a pretty great community, the support is amazing. I think the only thing the engineers might want to worry about is go back into the code base and clean things up a bit, as you start to see the code I'm like, wait a minute, their names are on it. So, it's always always a fun time and all serious now this is a big story on the DevSecOps. And I want to get your thoughts on this because kubernetes is still emerging, and DevOps is awesome, we've been covering that in for all of the life of theCUBE for the 11 years now and the greatness of DevOps but now DevSecOps is critical and Kubernetes native security is what people are looking at. When you look at that trend only continuing, what's your focus? What do you see? Now that you're in Red Hat as the CTO, former CTO of StackRox and now part of the Red Hat it's going to get bigger and stronger Kubernetes native and shifting left-hand or DevSecOps. What's your focus? >> Yeah, so I would say our focus is really around two big buckets. One is, Kubernetes native, sort of a different way to think about it as we think about our roadmap planning and go-to-market strategy is it's mutually exclusive with being in infrastructure native, that's how we think about it and as a startup we really have to focus on an area and Kubernetes was a great place for us to focus on because it was becoming the dominant orchestration engine. Now that we have the resources and the power of Red Hat behind us, the way we're thinking about this is infrastructure native. So, thinking about cloud native infrastructure where you're using composable, reusable, constructs and objects, how do you build potential offerings or features or security components that don't rely on third party tools or components anymore? How do you leverage the existing infrastructure itself to be able to conduct some of these traditional use cases? And one example we use for this particular scenario is networking. Networking, the way firewalling in segmentation was typically done was, people would tweak IP tables or they would install, for example, a proxy or a container that would terminate MTLS or become inline and it would create all sorts of sort of operational and risk overhead for users and for customers. And one of the things we're really proud of as sort of the company that pioneered this notion of cloud native security is if you just leverage network policies in Kubernetes, you don't have to be inline you don't have to have additional privileges, you don't have to create additional risks or operational overhead for users. So we're taking those sort of core philosophies and extending them. The same way we did to Kubernetes all the way through service manager, we're doing the same sorts of things Istio being able to do a lot of the things people are traditionally doing through for example, proxies through layer six and seven, we want to do through Istio. And then the same way for example, we introduced a product called GoDBledger which was an open-source tool, which would basically look at a yaml on helm charts and give you best practices responses. And it's something you we want for example to your get repositories. We want to take those sort of principles, enabling developers, giving them feedback, allowing them not to break their existing workflows and leveraging components in existing infrastructure to be able to sort of push security into cloud native. And really the two pillars we look at are ensuring we can get users and customers up and running as quickly as possible and reduce as much as possible operational overhead for them over time. So we feel these two are really at the core of open-sourcing in building into the infrastructure, which has sort of given us momentum over the last six years and we feel pretty confident with Red Hat's help we can even expand that further. >> Yeah, I mean, you bring up a good point and it's certainly as you get more scale with Red Hat and then the customer base, not only in dealing with the threat detection around containers and cloud native applications, you got to kind of build into the life cycle and you've got to figure out, okay, it's not just Kubernetes anymore, it's something else. And you've got advanced cluster security with Red Hat they got OpenShift cloud platform, you're going to have managed services so this means you're going to have scale, right? So, how do you view that? Because now you're going to have, you guys at the center of the advanced cluster security paradigm for Red Hat. That's a big deal for them and they've got a lot of R and D and a lot of, I wouldn't say R and D, but they got emerging technologies developing around that. We covered that in depth. So when you start to get into advanced cluster, it's compliance too, it's not just threat detection. You got insights telemetry, data acquisition, so you have to kind of be part of that now. How do you guys feel about that? Are you up for the task? >> Yeah, I hope so it's early days but we feel pretty confident about it, we have a very good team. So as part of the advanced cluster security we work also very closely with the advanced cluster management team in Red Hat because it's not just about security, it's about, how do you operationalize it, how do you manage it and maintain it and to your point sort of run it longterm at scale. The compliance part of it is a very important part. I still feel like that's in its infancy and these are a lot of conversations we're having internally at Red Hat, which is, we all feel that compliance is going to sort of more from the standard benchmarks you have from CIS or particular compliance requirements like the power, of PCI or Nest into how do you create more flexible and composable policies through a unified language that allows you to be able to create more custom or more useful things specific to your business? So this is actually, an area we're doing a lot of collaboration with the advanced cluster management team which is in that, how do you sort of bring to light a really easy way for customers to be able to describe and sort of abstract policies and then at the same time be able to actually and enforce them. So we think that's really the next key point of what we have to accomplish to be able to sort of not only gain scale, but to be able to take this notion of, not only detection in response but be able to actually build in what we call declarative security into your infrastructure. And what that means is, is to be able to really dictate how you want your applications, your services, your infrastructure to be configured and run and then anything that is sort of conflicting with that is auto responded to and I think that's really the larger vision that with Red Hat, we're trying to accomplish. >> And that's a nice posture to have you build it in, get it built in, you have the declarative models then you kind of go from there and then let the automation kick in. You got insights coming in from Red Hat. So all these things are kind of evolving. It's still early days and I think it was a nice move by Red Hat, so congratulations. Final question for you is, as you prepare to go to the next generation KubeCon is also seeing a lot more end user participation, people, you know, cloud native is going mainstream, when I say mainstream, seeing beyond the hyperscalers in the early adopters, Kubernetes and other infrastructure control planes are coming in you start to see the platforms emerge. Nobody wants another security tool, they want platforms that enable applications handle tools. As it gets more complicated, what's going to be the easy button in security cloud native? What's the approach? What's your vision on what's next? >> Yeah so, I don't know if there is an easy button in security and I think part of it is that there's just such a fragmentation and use cases and sort of designs and infrastructure that doesn't exist, especially if you're dealing with such a complex stack. And not only just a complex stack but a potentially use cases that not only span runtime but they deal with you deployment annual development life cycle. So the way we think about it is more sort of this notion that has been around for a long time which is the shared responsibility model. Security is not security's job anymore. Especially, because security teams probably cannot really keep up with the learning curve. Like they have to understand containers then they have to understand Kubernetes and Istio and Envoy and cloud platforms and APIs. and there's just too much happening. So the way we think about it is if you deal with security a in a declarative version and if you can state things in a way where how infrastructure is ran is properly configured. So it's more about safety than security. Then what you can do is push a lot of these best practices back as part of your gift process. Involve developers, engineers, the right product security team that are responsible for day-to-day managing and maintaining this. And the example we think about is, is like CVEs. There are plenty of, for example, vulnerability tools but the CVEs are still an unsolved problem because, where are they, what is the impact? Are they actually running? Are they being exploited in the wild? And all these things have different ramifications as you span it across the life cycle. So for us, it's understanding context, understanding assets ensuring how the infrastructure has to handle that asset and then ensuring that the route for that response is sent to the right team, so they can address it properly. And I think that's really our larger vision is how can you automate this entire life cycle? So, the information is routed to the right teams, the right teams are appending it to the application and in the future, our goal is not to just pardon the workload or the compute environment, but use this information to action pardon application themselves and that creates that additional agility and scalability. >> Yeah it's in the lifecycle of that built in right from the beginning, more productivity, more security and then, letting everything take over on the automation side. Ali congratulations on the acquisition deal with Red Hat, buyout that was great for them and for you guys. Take a minute to just quickly answer final final question for the folks watching here. The big news is you're open-sourcing StackRox, so that's a big news here at KubeCon. What can people do to get involved? Well, just share a quick quick commercial for what people can do to get involved? What are you guys looking for? Take a pledge to the community? >> Yeah, I mean, what we're looking for is more involvement in direct feedback from our community, from our users, from our customers. So there's a number, obviously the StackRox platform itself being open-source, we have other open-source tools like the KubeLinter. What we're looking for is feedback from users as to what are the pain points that they're trying to solve for. And then give us feedback as to how we're not addressing those or how can we better design our systems? I mean, this is the sort of feedback we're looking for and naturally with more resources, we can be a lot faster in response. So send us feedback good or bad. We would love to hear it from our users and our customers and get a better sense of what they're looking for. >> Innovation out in the open love it, got to love open-source going next gen, Ali Golshan Senior Director of Global Software Engineering the new title at Red Hat former CTO and founder of StackRox which spread had acquired in January, 2021. Ali thanks for coming on congratulations. >> Thanks for having, >> Okay, so keeps coverage of Kube Con cloud native Con 2021. I'm John Furrie, your host. Thanks for watching. (soft music)

>> Announcer: From around the Globe, it's theCUBE with coverage of Kube Con and Cloud Native Con Europe 2021 virtual brought to you by Red Hat, the cloud native computing foundation and ecosystem partners. >> Hello, and welcome back to theCUBE's coverage of Kube Con and Cloud Native Con 2021 virtual. I'm John Furrier, host of theCUBE, here with a great guest, I'm excited to talk to. His company, that he was part of founding CTO, was bought by Red Hat. Ali Golshan, Senior Director of Global Software Engineer at Red Hat, formerly CTO of StackRox. Ali thanks for coming on, I appreciate it. Thanks for joining us. >> Thanks for having me excited to be here. >> So big acquisition in January, where we covered it on SiliconANGLE, You guys, security company, venture backed amplify Sequoya and on and on. Big part of Red Hat story in their security as developers want to shift left as they say and as more and more modern applications are being developed. So congratulations. So real quick, just quick highlight of what you guys do as a company and inside Red Hat. >> Sure, so the company's premise was built around how do you bring security the entire application life cycle. So StackRox focuses on sort of three big areas that we talk about. One is, how do you secure the supply chain? The second part of it is, how do you secure infrastructure and foster management and then the third part is now, how do you protect the workload that run on top of that infrastructure. So this is the part that aligned really well with Red Hat which is, Red Hat had wanted to take a lot of what we do around infrastructure, foster management configuration management and developer tools integrated into a lot of the things they do and obviously the workload protection part was a very seamless part of integrating us into the OpeShift part because we were built around cloud native constructs and obviously Red Hat having some of the foremost experts around cloud native sort of created a really great asset. >> Yeah, you guys got a great story. Obviously cloud native applications are rocking and rolling. You guys were in early serverless emerges, Kubernetes and then security in what I call the real time developer workflow. Ones that are building really fast, pushing code. Now it's called day two operations. So cloud native did two operations kind of encapsulates this new environment. You guys were right in the sweet spot of that. So this became quite the big deal, Red Hat saw an opportunity to bring you in. What was the motivation when you guys did the deal Was it like, "wow" this is a good fit. How did you react? What was the vibe at the StackRox when this was all going down? >> Yeah, so I think there's really three areas you look for, anytime a company comes up and sort of starts knocking on your door. One is really, is the team going to be the right fit? Is the culture going to be the right environment for the people? For us, that was a big part of what we were taking into consideration. We found Red Hat's general culture, how they approach people and sort of the overall approach the community was very much aligned with what we were trying to do. The second part of it was really the product fit. So we had from very early on started to focus purely on the Kubernetes components and doing everything we could, we call it sort of our product approach built in versus built it on and this is sort of a philosophy that Red Hat had adopted for a long time and it's a part of a lot of their developer tools, part of their shift left story as well as part of OpenShift. And then the third part of it was really the larger strategy of how do you go to market. So we were hitting that point where we were in triple digit customers and we were thinking about scalability and how to scale the company. And that was the part that also fit really well which was obviously, RedHat more and more hearing from their customers about the importance and the criticality of security. So that last part happened to be one part. We ended up spending a lot of time on it, ended up being sort of the outer three matches that made this acquisition happen. >> Well congratulations, always great to see startups in the right position. Good hustle, great product, great market. You guys did a great job, congratulations. >> Thank you. >> Now, the big news here at KubeCon as Linux foundation open-source, you guys are announcing that you're open-sourcing at StackRox, this is huge news, obviously, you now work for an open-source company and so that was probably a part of it. Take us through the news, this is the top story here for this segment tickets through open-source. Take us through the news. >> Yeah, so traditionally StackRox was a proprietary tool. We do have open-source tooling but the entire platform in itself was a proprietary tool. This has been a number of discussions that we've had with the Red Hat team from the very beginning. And it sort of aligns around a couple of core philosophies. One is obviously Red Hat at its core being an open-source company and being very much plugged into the community and working with users and developers and engineers to be able to sort of get feedback and build better products. But I think the other part of it is that, I think a lot of us from a historic standpoint have viewed security to be a proprietary thing as we've always viewed the sort of magic algorithms or black boxes or some magic under the hood that really moved the needle. And that happens not to be the case anymore also because StackRox's philosophy was really built around Kubernetes and Built-in, we feel like one of the really great messages around wide open-source of security product is to build that trust with the community being able to expose, here's how the product works, here's how it integrates here are the actions it takes here's the ramifications or repercussions of some of the decisions you may make in the product. Those all I feel make for very good stories of how you build connection, trust and communication with the community and actually get feedback on it. And obviously at its core, the company being very much focused on Kubernetes developer tools, service manage, these are all open-source toolings obviously. So, for us it was very important to sort of talk the talk and walk the walk and this is sort of an easy decision at the end of the day for us to take the platform open-source. And we're excited about it because I think most still want a productized supported commercial product. So while it's great to have some of the tip of the spear customers look at it and adopt the open-source and be able to drive it themselves. We're still hearing from a lot of the customers that what they do want is really that support and that continuous management, maintenance and improvement around the product. So we're actually pretty excited. We think it's only going to increase our velocity and momentum into the community. >> Well, I got some questions on how it's going to work but I do want to get your comment because I think this is a pretty big deal. I had a conversation about 10 years ago with Doug Cutting, who was the founder of Hadoop, And he was telling me a story about a company he worked for, you know all this coding, they went under and the IP was gone, the software was gone and it was a story to highlight that proprietary software sometimes can never see the light of day and it doesn't continue. Here, you guys are going to continue the story, continue the code. How does that feel? What's your expectations? How's that going to work? I'm assuming that's what you're going to open it up which means that anyone can download the code. Is that right? Take us through how to first of all, do you agree with that this is going to stay alive and how's it going to work? >> Yeah, I mean, I think as a founder one of the most fulfilling things to have is something you build that becomes sustainable and stands the test of time. And I think, especially in today's world open-source is a tool that is in demand and only in a market that's growing is really a great way to do that. Especially if you have a sort of an established user base and the customer base. And then to sort of back that on top of thousands of customers and users that come with Red Hat in itself, gives us a lot of confidence that that's going to continue and only grow further. So the decision wasn't a difficult one, although transparently, I feel like even if we had pushed back I think Red Hat was pretty determined about open-source and we get anyway, but it's to say that we actually were in agreement to be able to go down that path. I do think that there's a lot of details to be worked out because obviously there's sort of a lot of the nuances in how you build product and manage it and maintain it and then, how do you introduce community feedback and community collaboration as part of open-source projects is another big part of it. I think the part we're really excited about is, is that it's very important to have really good community engagement, maintenance and response. And for us, even though we actually discussed this particular strategy during StackRox, one of the hindering aspects of that was really the resources required to be able to manage and maintain such a massive open-source project. So having Red Hat behind us and having a lot of this experience was very relevant. I think, as a, as a startup to start proprietary and suddenly open it and try to change your entire business model or go to market strategy commercialization, changed the entire culture of the company can sometimes create a lot of headwind. And as a startup, like sort of I feel like every year just trying not to die until you create that escape velocity. So those were I think some of the risk items that Red Hat was able to remove for us and as a result made the decision that much easier. >> Yeah, and you got the mothership with Red Hat they've done it before, they've been doing it for generations. You guys, you're in the startup, things are going crazy. It's like whitewater rafting, it's like everything's happening so fast. And now you got the community behind you cause you're going to have the CNC if you get Kubecon. I mean, it's a pretty great community, the support is amazing. I think the only thing the engineers might want to worry about is go back into the code base and clean things up a bit, as you start to see the code I'm like, wait a minute, their names are on it. So, it's always always a fun time and all serious now this is a big story on the DevSecOps. And I want to get your thoughts on this because kubernetes is still emerging, and DevOps is awesome, we've been covering that in for all of the life of theCUBE for the 11 years now and the greatness of DevOps but now DevSecOps is critical and Kubernetes native security is what people are looking at. When you look at that trend only continuing, what's your focus? What do you see? Now that you're in Red Hat as the CTO, former CTO of StackRox and now part of the Red Hat it's going to get bigger and stronger Kubernetes native and shifting left-hand or DevSecOps. What's your focus? >> Yeah, so I would say our focus is really around two big buckets. One is, Kubernetes native, sort of a different way to think about it as we think about our roadmap planning and go-to-market strategy is it's mutually exclusive with being in infrastructure native, that's how we think about it and as a startup we really have to focus on an area and Kubernetes was a great place for us to focus on because it was becoming the dominant orchestration engine. Now that we have the resources and the power of Red Hat behind us, the way we're thinking about this is infrastructure native. So, thinking about cloud native infrastructure where you're using composable, reusable, constructs and objects, how do you build potential offerings or features or security components that don't rely on third party tools or components anymore? How do you leverage the existing infrastructure itself to be able to conduct some of these traditional use cases? And one example we use for this particular scenario is networking. Networking, the way firewalling in segmentation was typically done was, people would tweak IP tables or they would install, for example, a proxy or a container that would terminate MTLS or become inline and it would create all sorts of sort of operational and risk overhead for users and for customers. And one of the things we're really proud of as sort of the company that pioneered this notion of cloud native security is if you just leverage network policies in Kubernetes, you don't have to be inline you don't have to have additional privileges, you don't have to create additional risks or operational overhead for users. So we're taking those sort of core philosophies and extending them. The same way we did to Kubernetes all the way through service manager, we're doing the same sorts of things Istio being able to do a lot of the things people are traditionally doing through for example, proxies through layer six and seven, we want to do through Istio. And then the same way for example, we introduced a product called GoDBledger which was an open-source tool, which would basically look at a yaml on helm charts and give you best practices responses. And it's something you we want for example to your get repositories. We want to take those sort of principles, enabling developers, giving them feedback, allowing them not to break their existing workflows and leveraging components in existing infrastructure to be able to sort of push security into cloud native. And really the two pillars we look at are ensuring we can get users and customers up and running as quickly as possible and reduce as much as possible operational overhead for them over time. So we feel these two are really at the core of open-sourcing in building into the infrastructure, which has sort of given us momentum over the last six years and we feel pretty confident with Red Hat's help we can even expand that further. >> Yeah, I mean, you bring up a good point and it's certainly as you get more scale with Red Hat and then the customer base, not only in dealing with the threat detection around containers and cloud native applications, you got to kind of build into the life cycle and you've got to figure out, okay, it's not just Kubernetes anymore, it's something else. And you've got advanced cluster security with Red Hat they got OpenShift cloud platform, you're going to have managed services so this means you're going to have scale, right? So, how do you view that? Because now you're going to have, you guys at the center of the advanced cluster security paradigm for Red Hat. That's a big deal for them and they've got a lot of R and D and a lot of, I wouldn't say R and D, but they got emerging technologies developing around that. We covered that in depth. So when you start to get into advanced cluster, it's compliance too, it's not just threat detection. You got insights telemetry, data acquisition, so you have to kind of be part of that now. How do you guys feel about that? Are you up for the task? >> Yeah, I hope so it's early days but we feel pretty confident about it, we have a very good team. So as part of the advanced cluster security we work also very closely with the advanced cluster management team in Red Hat because it's not just about security, it's about, how do you operationalize it, how do you manage it and maintain it and to your point sort of run it longterm at scale. The compliance part of it is a very important part. I still feel like that's in its infancy and these are a lot of conversations we're having internally at Red Hat, which is, we all feel that compliance is going to sort of more from the standard benchmarks you have from CIS or particular compliance requirements like the power, of PCI or Nest into how do you create more flexible and composable policies through a unified language that allows you to be able to create more custom or more useful things specific to your business? So this is actually, an area we're doing a lot of collaboration with the advanced cluster management team which is in that, how do you sort of bring to light a really easy way for customers to be able to describe and sort of abstract policies and then at the same time be able to actually and enforce them. So we think that's really the next key point of what we have to accomplish to be able to sort of not only gain scale, but to be able to take this notion of, not only detection in response but be able to actually build in what we call declarative security into your infrastructure. And what that means is, is to be able to really dictate how you want your applications, your services, your infrastructure to be configured and run and then anything that is sort of conflicting with that is auto responded to and I think that's really the larger vision that with Red Hat, we're trying to accomplish. >> And that's a nice posture to have you build it in, get it built in, you have the declarative models then you kind of go from there and then let the automation kick in. You got insights coming in from Red Hat. So all these things are kind of evolving. It's still early days and I think it was a nice move by Red Hat, so congratulations. Final question for you is, as you prepare to go to the next generation KubeCon is also seeing a lot more end user participation, people, you know, cloud native is going mainstream, when I say mainstream, seeing beyond the hyperscalers in the early adopters, Kubernetes and other infrastructure control planes are coming in you start to see the platforms emerge. Nobody wants another security tool, they want platforms that enable applications handle tools. As it gets more complicated, what's going to be the easy button in security cloud native? What's the approach? What's your vision on what's next? >> Yeah so, I don't know if there is an easy button in security and I think part of it is that there's just such a fragmentation and use cases and sort of designs and infrastructure that doesn't exist, especially if you're dealing with such a complex stack. And not only just a complex stack but a potentially use cases that not only span runtime but they deal with you deployment annual development life cycle. So the way we think about it is more sort of this notion that has been around for a long time which is the shared responsibility model. Security is not security's job anymore. Especially, because security teams probably cannot really keep up with the learning curve. Like they have to understand containers then they have to understand Kubernetes and Istio and Envoy and cloud platforms and APIs. and there's just too much happening. So the way we think about it is if you deal with security a in a declarative version and if you can state things in a way where how infrastructure is ran is properly configured. So it's more about safety than security. Then what you can do is push a lot of these best practices back as part of your gift process. Involve developers, engineers, the right product security team that are responsible for day-to-day managing and maintaining this. And the example we think about is, is like CVEs. There are plenty of, for example, vulnerability tools but the CVEs are still an unsolved problem because, where are they, what is the impact? Are they actually running? Are they being exploited in the wild? And all these things have different ramifications as you span it across the life cycle. So for us, it's understanding context, understanding assets ensuring how the infrastructure has to handle that asset and then ensuring that the route for that response is sent to the right team, so they can address it properly. And I think that's really our larger vision is how can you automate this entire life cycle? So, the information is routed to the right teams, the right teams are appending it to the application and in the future, our goal is not to just pardon the workload or the compute environment, but use this information to action pardon application themselves and that creates that additional agility and scalability. >> Yeah it's in the lifecycle of that built in right from the beginning, more productivity, more security and then, letting everything take over on the automation side. Ali congratulations on the acquisition deal with Red Hat, buyout that was great for them and for you guys. Take a minute to just quickly answer final final question for the folks watching here. The big news is you're open-sourcing StackRox, so that's a big news here at KubeCon. What can people do to get involved? Well, just share a quick quick commercial for what people can do to get involved? What are you guys looking for? Take a pledge to the community? >> Yeah, I mean, what we're looking for is more involvement in direct feedback from our community, from our users, from our customers. So there's a number, obviously the StackRox platform itself being open-source, we have other open-source tools like the KubeLinter. What we're looking for is feedback from users as to what are the pain points that they're trying to solve for. And then give us feedback as to how we're not addressing those or how can we better design our systems? I mean, this is the sort of feedback we're looking for and naturally with more resources, we can be a lot faster in response. So send us feedback good or bad. We would love to hear it from our users and our customers and get a better sense of what they're looking for. >> Innovation out in the open love it, got to love open-source going next gen, Ali Golshan Senior Director of Global Software Engineering the new title at Red Hat former CTO and founder of StackRox which spread had acquired in January, 2021. Ali thanks for coming on congratulations. >> Thanks for having, >> Okay, so keeps coverage of Kube Con cloud native Con 2021. I'm John Furrie, your host. Thanks for watching. (soft 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 hey welcome back everybody jeff frick here with thecube coming to you from our palo alto studios with our ongoing coverage of kubecon cloud nativecon north america 2020 virtual it's virtual like everything else that we're doing in 2020 we're really excited by our next guest we're going to dive into a company that you probably know a little bit on the surface but probably don't know a lot of the stuff that's going on behind the surface so we're really excited to have our next guest he is jai chakrabarti he is the director of engineering for core infrastructure at spotify jai great to see you great to be here with you today so as a as a long-standing uh spotify fan and and customer and premium customer and family playing customer just so there's no question i'm a big fan the infrastructure to deliver what i want to hear basically any sound any song from the entire world it seems like i don't know what the actual uh percentage of every published song you guys have you know kind of at my fingertips searchable available now to listen to is an amazing accomplishment i can't imagine how big and significant and complicated the infrastructure you guys must be managing and and not only that but kind of the meteoric growth over the last several years so first off just talk a little bit about spotify scale how you guys think about it is there some things that you can share to help people really understand you know some of the some of the big iron that's behind giving me the songs i want to hear absolutely and thank you for the opportunity to let me talk about this so it's a as you say it's a pretty mammoth project to be able to deliver just about any song that's in the world or now any podcast that you might want to listen to to hundreds of millions of fans and also enable creators to be able to share their content with the consumers who are interested in consuming that content so some of the metrics that go behind us are we have thousands of microservices running in production we were one of the early adopters of microservices at scale and continued to build on that foundation with early entrants to dockerize services and now of course largely on kubernetes we also have thousands of data pipelines hundreds of uh websites as well as micro app features and we're doing about 20 000 deployments a day to give you kind of a scale of how fast things are changing and for us speed is a great virtue as we're testing out features doing ab tests and trying to roll out the next best thing for the audio network it's amazing and i'm and i'm curious in terms of execution on the business side i mean clearly you're in many many countries you know you're global are all the licensing agreements for the music different by country are you just like super micromanaging um you know kind of the the revenue streams and the licensing by geo or is is that just as complex as it feels like it might be or is there some some simplicity or some scale that you can bring to uh to bring a little bit of of clarification there yeah so that is an area of complexity as well um so you know licensing across the broad set of content that we have as well as the number of publishers and creators that we have to make sure that everything is well accounted for is also kind of a source of complexity in our organizational makeup and then and then the the piece that i don't think a lot of people know is you guys are huge consumers and contributors back to open source and clearly we're here at q con cloud native con you've talked already about kubernetes and containers but i wonder before we get into some of the specifics if you can talk about philosophically the role of open source and why you know you guys are such a big open source company versus kind of back in the old days when you would have a lot of proprietary technology that you would try to develop and keep in-house as part of the as part of the secret sauce yeah thank you for that question so philosophically we are big proponents of open source we believe in giving back to the community we believe that when we as a community come together to solve these problems at scale the end result is much better than if we were to try it alone if any one company were to try it alone so some of the projects that we've contributed or invested a lot of time in are envoy for example which we use to power our perimeter at spotify or kubernetes which we use for deployment purposes as many companies do but there are also a number of other open source projects that we're committing to so for example with cloud bigtable we have produced an auto scaler that's now fairly widely used to be able to manage costs better with cloud bigtable we've also invested in a open source time series database called heroic to manage millions of data points for a metrics platform and scales so those are just a few examples but philosophically we believe this isn't something that we want to do alone and we want to leverage and do this together with the community right another one that you didn't mention there but you've talked about i want to dig into is backstage and as you mentioned you have a lot of developer teams working on a lot of projects like i saw a statistic maybe in github of the number of of github projects you guys are working on it's a it's a lot so what is backstage all about give us the story there yeah so at spotify we have almost somewhere around 500 engineering teams and so you can think about backstage as kind of like a central nervous system to be able to help engineers interface across the wide landscape that is spotify's engineering ecosystems so if you're an engineer you can go into backstage and you can manage your services your data pipelines your micro features you can see what other teams are doing what the organizational structure is you can get recommendations and insights on your tech health so you can see where you might need to invest more time and get some recommendations on how to get back to the blessed stock so it's really a one-stop developer portal that engineers spend the bulk of their time in today we open sourced it uh earlier this year and we've been absolutely thrilled with the response we've gotten thus far a number of companies have already started using it and contributing back so we've seen you know a lot of contributions coming back to backstage which is of course one of the ideas to be able to get some of the great ideas uh on backstage so we're really excited about that and specifically within backstage something that my team has just released into the open is a product called cost insights so one of the problems that we were dealing with at spotify is how do we sustainably look at cloud costs but do it in a way that isn't like a compliance exercise isn't a focus on traditional top top down cost controls but really taps into developers innate desire to work on optimization because all of us who come from an engineering background know that optimization is fun at the same time premature optimization is the root of all evil as the saying goes and so what we've done within our cost insights product and backstage is really try to find a good balance between engineering love for optimization and letting people know what are the areas where cloud spend really matters so if making an investment here isn't going to move the needle for us we let people know that this isn't worth your time to worry about so let me unpack you touch on a couple things first off you talked about it gives you an assessment of your engineering health so does that mean that it's kind of uh compliance within a standard is that looking for i guess not quite red flags yet but yellow flags of things that that are known potential issues down the road is it you know tapping into maybe higher cost services or microservices versus less that maybe there's a less expensive way so so how do you define health and how do you you know keep track of people getting away from health and then you know steering them back to being more healthy yeah that's a great question so we have this concept at spotify called golden state which is a reflection of how far away are you from all of the blessed frameworks libraries that we recommend to engineers and the way we think about golden state is there ought to be clear value adds to going to a new service a new library version and so the way we try to express it is unless of course there's a kind of a direct security concern and there aren't really too many ways to get around that but we really tried to preserve engineering autonomy and say if you go to this new framework for example you're going to save this much time on average so the recommendations that you'll find there are going to be highly specific so for example if you adopt uh you know an auto scaler for bigtable you're going to save this much time and spend this much less that's in general how we phrase these things okay and then on the cost insights i mean clearly when a dev is working on a new feature or new uh you know experimenting maybe with a bunch of new features and you're you're setting up multiple a b testing this and that are they are they not really working worrying about cost at the front end of that or is really kind of the cost optimization and you mentioned you know don't optimize too early does that come kind of after the fact and after you've you know moved some new things into production they have potential and now we do maybe a second order kind of analysis of the appropriateness of that feature because i imagine if they're just if you're just trying to come up with new features and exploring and trying new things not really worrying about the you're not worrying about the cloud bill right you're just trying to get some feature functionality and make sure you don't have too many bugs and make sure you're going to get some good client value and some new customer experience yeah yeah no and and we agree with that perspective so we think about the world in terms of startup scale-ups and mature businesses at spotify so there are a lot of teams who are experimenting with new ideas that fall into the startup category and by and large they are not going to be worrying about costs that being said we as infrastructure teams have the notice on us to think about how do we provide shared services and frameworks that abstract away a lot of these questions around how do you properly manage your costs right so that that is on us as infrastructure teams but really our perspective is for startups to move as quickly as they can and really if that's an idea that's viable and you get to what we call the scale-up stage or you get to the mature business stage where it really is a core part of our business then that's where you know you might start to get some nudges or recommendations and cost insights so interesting so i'd love to you know your background you came from financial services and trading where clearly speed matters accuracy matters you know that that's i mean basically financial services is is a software game at this stage of the game and it's a speed game and i saw another interesting uh video getting ready for this i think it was with gustav soderstrom talking about the competitive advantage of the early days really being speed and speed to return a result and speed to start that stream and it just struck me very much like you know the early days of google which was that was their whole speed thing and they even told you how fast you got a return on your search when you're thinking about optimizing now with the huge suite of features and functionalities that you have how do you think about speed is it still speed number one how is kind of the priority changed and what are some of the design priorities that when things go from experiment to start to be into the scale realm and hopefully be successful in production that that need to be thought about and potentially rank ordered um in in the proper way yeah yeah that's it's a great question and so you know i'll just refer to daniel x quote around this which is we aim to fail faster than anyone else and so for us as a company and with our growth trajectory and investing in the areas that we are looking to invest into it's still absolutely critical that we move fast that we get the ideas of the startup phase out to be vetted and validated if we can go to the next phase to the scale-up phase so i see that just as important today if not more than when i first joined spotify uh you know over four years ago at this point and regarding financial services um there are certainly you know touch points in terms of the amount of data that we're processing and the scale of technology that it requires to process that kind of data but one of the things that i really love about spotify of course is that we get to move fast which is sometimes of course going to be a lot more difficult when you're talking about the financial service arena and various uh compliance bodies that are overseeing any changes that you might make yeah you guys are you guys were running a little bit ahead of the regs i think which is pretty typical uh in the music business napster was running a little bit ahead of the regs and you know then we saw the evolution with the itunes and then you know you guys really really nailing the streaming service really for the first time and and opening up this new con consumption bottle and i wonder if you could talk about you know kind of keeping the customer experience first and making sure that that's a positive thing i can't help but think of of the netflix experience where they spend so much time on people's interaction with the application to to get them to try new things a recommendation engine such an important piece of the of the puzzle and i think what you guys have really nailed is the discovery piece because it's one thing to be able to quickly access a favorite song and be able to listen to it but everyone loves discovery right and discovery is kind of an interesting and interesting process and you guys have taken a really scientific approach in terms of cataloging music and and different attributes of music and then using those to help drive the recommendation engine i wonder if you can share you know kind of your thoughts in terms of being you know kind of ultimately driven by the customer experience and their interaction with the application and these things called you know music or podcast which is such a such a a a very personal thing to interact with yeah so from the perspective of core infrastructure you know it's spotify our goal is to really enable the scale in which we are processing the amount of audio content that goes through our system and so podcast of course is a new category that wasn't there when i originally joined spotify but it's really to provide a platform so these experiments can be done seamlessly so we can have different ways of looking at discovery looking at user segmentation and being able to come up with new ways that are going to be compelling to our customers so that's very exciting and fulfilling for us to be able to provide that platform by which our sister teams can iterate very quickly knowing that they have the guard rails uh which you know in our on-premise days at times was a struggle and where we're in a very different place now yeah so last question before i let you go we're at cubecon cloudnativecon um and and it's just an interesting thing that i always think about when you're managing engineering teams that are heavily open source participants and you know it's such a big piece now of of a lot of engineers motivation to be active participants in open source and to and to show their work to others outside the company but at the same time they have to get company work done so i just wonder if you could share your perspective of how do you manage open source contributions how do you keep them you know working on company projects but also make sure you allocate time and priorities to open source contributions because that is a really important piece of the motivation for a lot of engineers it's not just working for the company and getting paid at the india at the end of every two weeks yeah it's a key motivation as you say and it's key to our recruiting strategy and also how we think about retaining engineers and spotify so there are different mechanisms that we use and there's a lot of focus that's modified on coming up with development plans for engineers that actually make sense um so you know i would say that all the way from the oft quoted 20 time is something that you might hear at spotify where you have engineers who are working on open source 20 of the time or you might see a variety of customized customized options depending on who the engineer is where they want to grow and really i think the key here is providing the right support structures so even if you have the time are you getting the mentorship are you getting the right kind of support system so you know how to connect with the community and so you have other like-minded people who are bouncing ideas and you don't feel like you're doing it yourself so that's something that i feel really excited about that we've grown those support structures over the last few years eyes have also been very intentional about giving engineers time to work on open source and you give them as much as 20 i'd never heard that before yeah in some cases some i mean if that is what where an engineer really wants to focus and grow there are a number of folks at spotify who are spending up to 20 of their time on open source wow that's amazing that that is a uh that's a it's just it's such a great commitment for the company to the engineer if that's their priority and then everyone's going to benefit from it both the engineer the company as well as the community so really a forward-looking you know point of view to take that long-term view versus the you know maybe we should only give them 10 we're losing 10 of their time working on a project so that is super super progressive and i'm sure you must be seeing great roi on it or you wouldn't continue to be such huge proponents of open source and such huge contributors back so that's that's a great story yeah terrific i mean you know we we want those contributions to be in line with where we're growing as a company and we see a lot of opportunities uh where that is happening so like envoy or kubernetes um just to name a couple of examples where folks have devoted time in those areas well thanks for uh thanks for sharing some of the the story behind the scenes you know again household name what what a tremendous success story and and and uh you know i'm a movie customer so i'm definitely a customer though no no doubt about it so uh thank you for your contributions congrats to the team and uh and really loved the story of how you guys are contributing back and and doing a lot more than just making great music available to us all and a great channel for uh for creators to get their stuff out there so thanks again thanks so much for your time i really appreciate it all right he's jai i'm jeff you're watching the cube's continuing coverage of kubecon cloud nativecon north america 2020 thanks for watching we'll see you next [Music] time you

>> 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)

>>from around the globe. It's the Cube with coverage of Coop Con and Cloud, Native Con Europe 2020 Virtual brought to You by Red Hat, The Cloud Native Computing Foundation and its ecosystem Partners. Hi, I'm stupid, man. And this is the Cube's coverage of Cube con Cloud Native Con Europe event, which, of course, this year has gone virtual, really lets us be able to talk to those guests where they are around the globe. Really happy to welcome back to the program. Liz Rice. First of all, she is the vice president of Open Source Engineering at Aqua Security. She's also the chair of the Technical Oversight Committee has part of Ah CN cf. Liz, it is great to see you. Unfortunately, it's remote, but ah, great to catch up with you. Thanks for joining. >>Yeah, Thanks for having me. Nice to see you if you know across the ocean. >>So, uh, you know, one of the one of the big things? Of course, for the Cube Con show. It's the rallying point for the community. There are so many people participating. One of the things we always love to highlight its not only the the vendor ecosystem. But there is a very robust, engaged community of end users that participate in it. And as I mentioned, you're the chair of that technology oversight committee. So maybe just give our audience a little bit of, you know, in case they're not familiar with the TOC does. And let's talk about the latest pieces there. >>Yes, say the TOC is really hit. C can qualify the different projects that want to join the CNC F. So we're assessing whether or not they're cloud native. We're assessing whether they could joined at sandbox or incubation or graduation levels. Which of the different maturity levels that we have for for project within the CN CF yeah, we're really there, Teoh also provide it steering around the What does cloud native mean and what does it mean to be a project inside the CN CF community? We're also a voice for all of the projects. We're not the only voice, but, you know, part >>of our role >>really is to make sure the projects are getting what they need in order to be successful. So it's it's really around the technology and the projects that we call cloud native >>Yeah, and and obliges Cloud Native because when people first heard of the show, of course, Kubernetes and Cube Con was the big discussion point. But as you said, Cloud native, there's a lot of projects there. I just glanced at the sandbox page and I think there's over 30 in the sandbox category on and you know they move along their process until they're, you know, fully mature and reach that, you know, 1.0 state, which is the stamp of approval that, you know, this could be used in production. I understand there's been some updates for the sandbox process, so help us understand you know where that is and what's the new piece of that? >>Yeah. So it's really been because of the growth off cloud native in general, the popularity off the CN CF and so much innovation happening in our space. So there's been so many projects who want Teoh become hard off the CNC f family on and we used to have a sponsorship model where members of the TOC would essentially back projects that they wanted to see joining at the sandbox level. But we ran into a number of issues with that process on and also dealing with the scale, the number of applications that have come in. So we've revamped the process. We made it much easier for projects to apply as much simpler form where really not making so much judgment we're really saying is it's a cloud native project and we have some requirements in terms off some governance features that we need from a project. And it's worth mentioning that when a project joins the CN CF, they are donating the intellectual property and the trademark off that project into the foundation. So it's not something that people should take lightly. But we have tried to make it easier and therefore much smoother. We're able Teoh assess the applications much more quickly, which I think everyone, the community, the projects, those of us on the TOC We're all pretty happy that we can make that a much faster process. >>Yeah, I actually, it brings up An interesting point is so you know, I've got a little bit of background in standards committees. A swell as I've been involved in open source for a couple of decades now some people don't understand. You know, when you talk about bringing a project under a foundation. You talked about things like trademarks and the like. There are more than one foundation out there for CN CF Falls under the Linux Foundation. Google, of course, brought Kubernetes in fully to be supported. There's been some rumblings I've heard for the last couple of years about SDO and K Native and I know about a month before the show there was some changes along SDO and what Google was doing there may be without trying to pass too many judgments in getting into some of the political arguments, help us understand. You know what Google did and you know where that kind of comparison the projects that sit in the CN cf themselves. >>Yeah, So I e I guess two years ago around two years ago, Stu was very much the new kid in the cloud native block. So much excitement about the project. And it was actually when I was a program co chair that we had a lot of talks about sdo at Cube Con cloud native bomb, particularly in Copenhagen, I'm recalling. And, uh, I think everyone I just saw a natural fit between that project on the CN, CF and There was an assumption from a lot of people across the community that it would eventually become part of the CNC f. That was it's natural home. And one of the things that we saw in recent weeks was a very clear statement from IBM, who were one off the Uh huh, yeah, big contributing companies towards that project that that was also their expectation. They were very much under the impression that Stu would be donated to the CN CF at an appropriate point of maturity, and unfortunately, that didn't happen. From my point of view, I think that has sown a lot of confusion amongst the community because we've seen so much. It's very much a project of fits. Service mesh designed to work with kubernetes is it really does. You're fit naturally in with the other CN CF projects. So it's created confusion for end users who, many of whom assume that it was called the CN CF, and that it has the neutral governance that the other projects. It's part of the requirements that we have on those projects. They have to have an open governance that they're not controlled by a single vendor, Uh, and we've seen that you know that confusion, Andi. Frustration around that confusion being expressed by more and more end users as well as other people across the community. And yeah, the door is still open, you know, we would still love to see SDO join the community. Clearly there are different opinions within the SD wan maintainers. I will have to see what happens. >>Yeah, lets you bring up some really good points. You know, absolutely some of some of that confusion out there. Absolutely. I've heard from customers that if they're making a decision point, they might say, Hey, maybe I'm not going to go down that maybe choose something else because I'm concerned about that. Um, you know, I sdo front and center k native, another project currently under Google that has, you know, a number of other big vendors in the community that aiding in that So hopefully we will see some progress on that, you know, going forward. But, you know, back to you talked about, You know, the TOC doesn't make judgements as to you know which project and how they are. One of the really nice things out there in the CN CF, it's like the landscape just for you to help, understand? Okay, here's all of these projects. Here's the different categories they fit in. Here is where they are along that maturity. There's another tool that I read. Cheryl Hung blogged about the technology radar. I believe for continuous delivery is the first technology radar. Help us understand how that is, you know, not telling customers what to do but giving them a little guidance that you know where some of these projects projects fit. In a certain segment, >>Yeah, the technology radar is a really great initiative. I'm really excited about it because we have increasing numbers or end users who are using these different projects it both inside the CN CF and projects that are outside of the CNC F family. Your end users are building stacks. They're solving real problems in the real world and with the technology radar. What Cheryl's been able to facilitate is having the end you to the end user community share with us. What tools? They're actually using what they actually believe are the right hammers for specific nails. And, you know, it's it's one thing for us as it's more on the developer or vendor side Teoh look at different projects and say what we think are the better solutions for solving different problems. Actually hearing from the horse's mouth from the end users who are doing it in the real world is super valuable. And I think that is a really useful input to help us understand. What are the problems that the end user is still a challenge by what are the gaps that we still need to fail more input we can get from the end user community, the more will be solving real problems and no necessarily academic problems that we haven't sorry discovered in >>the real world. Alright, well is, you know, teeing up a discussion about challenges that users still have in the world. If we go to your primary jobs, Main hat is you live in the security world and you know, we know security is still something, you know, front and center. It is something that has never done lots of discussion about the shared responsibility model and how cloud native in security fit together and all that. So maybe I know there's some new projects there, but love to just give me a snap shot as where we are in the security space. As I said, Overall, it's been, you know, super important topic for years. This year, with a global pandemic going on, security seems to be raised even more. We've seen a couple of acquisitions in the space, of course. Aqua Security helping customers along their security journey. So what do you seeing out there in the marketplace today and hear from your custom? >>Yeah, I Every business this year has, you know, look at what's going on and you know, it's been crazy time for everyone, but we've been pleasantly surprised at how, you know, in relative terms, our business has been able to. It's been strong, you know. And I think you know what you're touching on the fact that people are working remotely. People are doing so many things online. Security is evermore online. Cloud security's evermore part off what people need to pay attention to. We're doing more and more business online. So, actually, for those of us in the security business, it has bean, you know that there have been some silver linings to this this pandemic cloud? Um, yes. So many times in technology. The open source projects and in particularly defaults in kubernetes. Things are improving its long Bina thing that I've you know, I wished for and talked about that. You know, some of the default settings has always been the most secure they could be. We've seen a lot of improvements over the last 23 years we're seeing continuing to see innovation in the open source world as well as you know, on the commercial side and products that vendors like Akwa, you know, we continue to innovate, continue to write you ways for customers to validate that the application workloads that they're going to run are going to run securely in the cloud. >>Alright and lives. There's a new project that I know. Ah, you know, you Aqua are participating in Tell us a little bit about Starbird. You know what's what's the problem? It's helping solve and you know where that budget >>Yes, So stockholders, one of our open source initiatives coming out of my team are equal on, and the idea is to take security reporting information and turn it into a kubernetes native, uh, resources custom resources. And then that means the security information, your current security status could be queried over the kubernetes AP I, as you're querying the status or the deployment, say you can also be clearing to see whether it's passing configuration audits or it's passing vulnerability scans for the application containers inside that deployment. So that information is available through the same AP eyes through the queue control interface through dashboards like Octane, which is a nice dashboard viewer for kubernetes. And starboard brings security information not just from acquittals but from other vendor tools as well front and center into that kubernetes experience. So I'm really excited about Star Border. It's gonna be a great way of getting security visibility, Teoh more kubernetes use it >>all right. And we were talking earlier about just the maturity of projects and how they get into the sandbox. Is is this still pretty sandbox for >>this? OK, we're still very much in the early phases and you know it. I think in the open source world, we have the ability to share what we're doing early so that we can get feedback. We can see how it resonates with with real users. We've had some great feedback from partners that we've worked with and some actual customers who actually collaborated with When we're going through the initial design, some great feedback. There's still lots of work to do. But, yeah, the initial feedback has been really positive. >>Yeah, is usually the event is one of those places where you can help try toe, recruit some other people that might have tools as well as educate customers about what's going on. So is that part of the call to action on this is, you know, what are you looking for for kind of the rest of 2020 when it when it comes to this project? >>Yeah, absolutely. So internally, we're working on an operator which will automate some of the work that's double does in the background in terms off getting more collaboration. We would love to see integrations from or security tooling. We're talking with some people across the community about the resource definition, so we've come up with some custom resource definitions, but we'd love them to be applicable it to a variety of different tools. So we want to get feedback on on those definitions of people are interested in collaborating on that absolutely do come and talk to me and my team are reluctant. >>Great. Listen, and I'll give you the final word. Obviously, we're getting the community together while we're part So you know any other you know, engagement opportunities, you get togethers. Things that you want people to know about the European show this year. >>Well, it's gonna be really you know, I'm on tenterhooks to see whether or not we can recreate the same atmosphere as we would have in Q con. I mean, it won't be exactly the same, but I really hope that people will engage online. Do come and, you know, ask questions of the speakers. Come and talk to the vendors, get into slack channels with the community. You know, this is an opportunity to pretend we're in the same room. Let's let's let's do what we can Teoh recreate as close as we can. That community experience that you keep corn is famous for >>Yeah, absolutely. That whole way track is something that is super challenging to recreate. And there's no way that I am getting the Indonesian food that I was so looking forward to in Amsterdam just such a great culinary and cultural city. So hopefully sometime in the future will be able to be back there. Liz Rice. Always pleasure catching up with you. Thanks so much for all the work you're doing on the TOC. And always a pleasure talking to you. >>Thanks for having me. >>All right, Lots more coverage from Cube Con Cloud, Native con the European 2020 show, Of course. Virtual I'm stew minimum. And thank you for watching the Cube. Yeah, yeah, yeah, yeah.

>>live from San Diego, California It's the Q covering Koopa and Cloud Native Cot brought to you by Red Cloud. Native Computing Pounding and its ecosystem >>Welcome back. This is the cubes. Fourth year of coverage at Q. Khan Cloud, Native Con. We're here in San Diego. It's 2019. I'm stewed. Minutemen, my host for this afternoon is Justin Warren and happy to welcome to guests from the newly minted platinum member of the CNC F Net Up. Sitting to my right is that Baldwin, who is the director of Cloud Native and Communities Engineering and sitting to his right is Rob Bhaskar, who's the product product strategy for Kubernetes. And it's also a board member on the CME CF, thank you both for joining us. Thank you. All right, s O, you know, maybe start with you. You know, uh, you know, companies that No, I've got plenty of history with net up there. What I've been hearing from that up last few years is you know, the Corvette has always been software, and it is a multi cloud world. I've been hearing this message before. Kind of the cloud native Trinity's piece was going, Of course, there's been some acquisitions and met up continuing to go through its transformations if you will s o help us understand kind of net ops positioning in this ecosystem >>in communities. Yes. Okay, so what we're doing is we're building a product that large manage cloud native workloads on top of community. So we've solved the infrastructure problem. And that's kind of the old problem. We're bored to death. Talking about that problem, but we try to do is try to provide a single painting class to manage on premise. Workloads and off permits were close. So that's what we're trying to do. We're trying to say it's now more about the AP taxonomy in communities. And then what type of tooling do you build to manage that that application and communities and says what we're building right now? That's where we're headed with hybrid. >>There's a piece of it, though, that does draw from the historical strength of map, Of course. So we're building way have, essentially already in marketing capability that allows you to deploy communities an agnostic way, using pure, open unmodified kubernetes on all of the major public clouds, but also on trump. But over time and some of this is already evident. You'll see it married to the storage and data management capabilities that we draw from the historical NetApp and that we're starting to deploy into those public clouds >>with the idea that you should be able to take a project. So project being the name space, new space, having a certain application in it. So you have multiple deployments. I should be able to protect that name space or that project. I feel to move that and the data goes with it. So they were very data where that's what we're trying to do with our. Our software is, you know, make it very data. Where have that aligned with APS inside of communities, >>So maybe step back for a second. What? One of the one of things we've heard a few times at this show before and was talking about the keynote this morning is it is project over company when it comes to the C N C F Project Project over company. So it's about the ecosystem. The C in C F tries not to be opinionated, so it's okay for multiple projects to fitness face not moving up to a platinum a sponsor level. You know, participant here, Ned. It's got lots of history's in participating and driving standards, helping move where the industry's going. Where doesn't it up? See its position in, you know, the participating in the foundation and participating in this ecosystem? >>Yeah, So great question, actually. Love it. It's for my favorite topic. So I think the way we look at it is oftentimes, project to the extent they become ubiquitous, define a standard a de facto standard, so not necessarily ratified by some standards body. And so we're very interested in making sure that in a scenario where you would employ the standard from a technology integration perspective, our capabilities can can operate as an implementation behind the standard. So you get the distinguishing qualities of our capabilities. Our products in our service is Visa VI or in the context of the standard. We're not trying to take you down a walled garden path in a proprietary, uh, journey, if you will weigh, would rather actually compel you to work with us on the basis of the value, not necessarily operating off a proprietary set of interface. Kubernetes broadly perceive it as a defacto standard at this point, there's still some work to be done on running out the edges a lot of underway this week. It's definitely the case that there's a new appeal to making this more off herbal by pardon the expression mere mortals way. Think we can offer Cem, Cem, Cem help in that respect as well? >>Yeah, for us, its usability, right? I mean, that's the reason I started stacking. Cloud was that there was usability problem with kubernetes. I had a usability problem. That's what we're trying. That's how I'm looking at the landscape. And I look at kind of all the projects inside the C N c f. And I look at my role is our role is to How do we tie these together? How do we make these? So they're very, very usable to the users. How were engaging with the community is to try to like a line like this, basically pure upstream projects, and create a usability layer on top of that. But we're not gonna we don't want ever say we're gonna fork into these projects what we're gonna contribute back into these. >>That's one concern that I have heard from. Customers were speaking with some of them yesterday. One of the concerns I had was that when you add that manageability onto the base kubernetes layer, that often very spenders become rather opinionated about which way we think this is a good way to do that. And when you're trying to maintain that compatibility across the ecosystem. So some customers saying, Well, I actually don't want to have to be too closely welded to anyone. Vendor was part of the benefit of Kubernetes. I can move my workloads around. So how do you navigate What? What is the right level of opinion? Tohave and which part should actually just be part of a common sense >>should be along the lines of best practices is how we do it. So like, Let's take a number policy, for example, like applying a sane default network policy to every name space defying a saying default pod security policy. You know, building a cluster in the best practices fashion with security turned on hardening done where you would have done this already as a user. So we're not looking you in any way there, so that's we're not trying. I'm not trying to carry any type of opinion in the product we're trying to do is urbanize your experience across all of this ecosystem so that you don't ever have to think about time now building a cluster on top of Amazon. So I gotta worry about how do I manage this on Amazon? I don't want you to think about those providers anymore, right? And then on top of those on top of that infrastructure, I wanna have a way that you're thinking about managing the applications on those environments in the exact same way. So I'm scaling protecting an application on premise in the identical way I'm doing it in the cloud. >>So if it's the same everywhere, what's the value that you're providing? That means that I should choose your option than something else. >>So wait, do have This is where we have controllers and live inside of the clusters that manage this stuff for the user's so you could rebuild what we're doing, But you would have to roll it all by hands, but you could, you know, we don't stand in the way of your operations either. So, like if we go down, you don't go down that idea, but we do have controllers we have. We're using charities. And so, like our management technology, our controllers are just watching for workload to come into the environment. And then we show that in the interface. But you could just walk away as well if you wanted to. >>There's also a constellation of other service is that we're building around this experience, you know, they do draw again from some of the storage and management capabilities. So staple sets your traditional workloads that want to interact with or transact data against a block or a shared file system. We're providing capabilities for sophisticated qualities of persistence that can be can exist in all of those same public clouds. But moreover, over time, we're gonna be in on premises. Well, we're gonna be able to actually move migrate, place, cash her policy. Your put your persistent data with your workload as you move migrate scale burst would repatriate whatever the model is as you move across in between clouds. >>Okay, How how far down that pathway do you think we are? Because 11 criticism of proven it is is that a lot of the tooling that were used to from more traditional ways of operating this kind of infrastructure isn't really there yet. Hence into the question about we actually need to make this easy to use. How far down that pathway away? >>Why would argue that tooling that I've built has already solved some of those problems. So I think we're pretty far down. The people ride down the path. Now what we haven't done is open sourced. You know all my tools, right? To make it easier on everybody else. >>Get up, Scott. Strong partnerships across the cloud platforms. I had a chance to interview George at the Google Cloud event. New partner of the year. I believe some of the stuff help us understand how you know something about the team building. Interact with the public cloud. You look at anthems and azure Arkin. Of course, Amazon has many different ways. You can do your container and management piece there, you know, to talk a little bit of that relationship and how both with those partners and then across those partners, you know, work. >>Yeah, it's a wow. So how much time we have? So so there's certainly a lot of facets to to that, But drawing from the Google experience. We just announced the general availability of cloud volumes on top. So the ability to stand up and manage your own on top instance and Google's cloud. Likewise, we've announced the general availability of the cloud volume service, which gives you manage put fun as a service experience of shared file system on demand. Google, I believe, is either today or yesterday in London. I guess maybe I'll blame that on the time zone covers, not knowing what what day it was. But the point is that's now generally available. Some of those capabilities are going to be able to be connected to our ability from an ks to deploy, uh on demand kubernetes cluster and deploy applications from a market marketplace experience in a common way, not just with Google, but has your with Amazon. And so, you know, frankly, the story doesn't differ a little bit from one cloud to the next, but the the Endeavour is to provide common capabilities across all of them. It's also the case that we do have people that are very opinionated about I want to live only in the Google or that Microsoft of the Amazon, because we're trying to deliver a rich experience for those folks as well, even if you don't value the agnostic multi cloud expert. >>Yeah and Matt, You know, I'm sure you have a viewpoint on this, but you know, it's that skill set that that's really challenging. And I was at the Microsoft show and you've got people you know. It's not just about dot net, there's all that. They're they're embracing and opened all of these environment. But people tend to have the environment that you used to and for multi cloud to be a reality, it needs to be a little bit easier for me to go between them, but it's still we're still we're making progress. But there's work to do. Yeah, s so I just, you know, you know, I know you're building tools and everything, but what what more do we didn't need to do? What were some of the areas that you know you're hopeful for about a >>year before I need to go for the supreme? It's down. It's coming down to the data side like I need to be able to say that on when I turn on data service is inside of kubernetes. I need be able to have that work would go anywhere, right? And because it is a developer. So I have I'm running a production. I'm running an Amazon. But maybe I'm doing test locally on my bare metal environments. Right? I need I want to be able to maybe sink down some of my data. I'm working with a production down to my test environment. That stuff's missing. There's no one doing that right now, and that's where we're headed. That's the path that's where we're headed. >>Yeah. I'm glad you brought that up, actually, because one of the things that I feel like I heard a little bit last year, but it is violated more this year is we're talking a little bit more to the application to the application developer because, you know, communities is a piece of the infrastructure, But it's about the Colonel. Yeah, yeah, yeah. It's the colonel there. So, you know, how do we make sure you know, we're standing between what the APP developer needs and still making sure that, you know, infrastructure is taken care of because storage and networking they're still hard. >>It is. Yeah. Yeah. I mean, I'm I'm approaching. I'm thinking more along the lines of I'm trying to work about app developers personally than infrastructure This point on for me, you know, like so I have I give you a cluster in three minutes, right? So I don't really have to worry about that problem, you know, way also put Theo on top of the clusters. So it's like we're trying to create this whole narrative that you can manage that environment on day one day, two versions. But and that's for like, an I T manager, right? And society instead of our product. How I'm addressing this is you have personas and so you have this concept. You have an I T manager. They do these things that could set limits for the developer who's building the applications or the service's and pushing those up into the environment. They need to have a sense of freedom, right? And said on that side of the house, you know, I'm trying not to break them out of their tooling. So, like wait part of our product ties in to get s o. We have CD, you know? So you just get push, get commit to a branch and weaken target multiple clusters, Right? But no point to the developer, actually, drafty animal or anything. We make way basically create the container for you. Read the deployment, bring it online. And I feel like there's these lines and that I t guys need to be able to say I need to create the guard rails for the Debs. I don't want to make it seem like I'm creating guardrails for the deaths caused the deaths. Don't like that. That's how I'm balancing it. >>Okay, Because that has always been the tension and that there's a lot of talk about Dev ops, but you don't talkto application developers, and they don't wanna have anything to do with infrastructure. They just want a program to an A p I and get things done. They would like this infrastructure to be seamless. Yeah, >>and what we did, like also what I'm giving them is like service dashboards. Because as a developer, you know, because now you're in charge of your cue, eh? You're writing your tests you're pushing. If your c I is going to ct you on your service in production, right? And so we're delivering dashboards as well for service Is that the developers are running, so they dig in and say, Oh, here's an issue or here's where the issue is probably gonna be at I'm gonna go fix this. Yeah, and we're trying to create that type of like scenario for developer and for an I T manager, >>slightly different angle on it, by understanding that question correctly is part of the complexity of infrastructure is something we're also turned Friday deterministic sort of easy button capability, for perhaps you're familiar with them. That's nice. And a C I product, which we we kind of expand that as hybrid cloud infrastructure. If the intention is to make it a simple private cloud capability and indeed are not, a community service operates directly off of it. It's a big part of actually how we deliver Cloud Service is from it. The point is, is that if you're that application developer, if you want the effective and CASS on prom thing, Endeavor with are not a PhD. I product is to give you that sort of easy button extremes because you didn't really want to be a storage admin network at you didn't want to get into the be mired in the details of infra. So So you know, that's obviously work in progress. But we think we're definitely headed down the right direction >>for him. >>Yeah, it just seemed that a lot of enterprises wanna have the cloud like experience, but they want to be able to bring it home that we're seeing a lot more. Yeah. >>So this is like, this turn cheon from this turnkey cloud on premise and played with think has weaken like the same auto scaling. So take so take the dynamic nature of opportunities. Right. So I have a base cluster size of four worker notes, right? But my work, let's gonna maybe maybe need to have more notes. So my out of scale is gonna increase the size my cluster and decrease the size right Pretty much everybody only do that in the public cloud. I could do that in public and on premise now and so that's That's what we're trying to deliver. And that's nickel stuff. I think >>that there's a lot of advantages thio enterprises operating in that way because I have I people that here I can I can go and buy them, hire them and say way, need you to operate this gear and you, you've already done elsewhere. You can do it in cloud. You can do it on side. I could know run my operations the same across no matter where my applications leave, Which saves me a lot of money on training costs on development costs on generally makes for a much more smooth and seamless experience. So, Rob, if you could just love >>your takeaway on, you know, kind of net up participation here at the event and what you want people to take away off from the show this year. >>So it's certainly the case that we're doing a lot of great work. We, like people toe become aware of it. Not up, of course, is not. I think we talked about this and perhaps other context, not strictly a storage and data management company. Only way do draw from the strength of that as we're providing full stack capabilities in a way that are interconnected with public cloud things like are not a Cuban. Any service is really the foundational glue in many ways how we deliver the application run time, but over time will build a consolation of data centric capabilities around that as well. >>I would just love to get your viewpoint Is someone that you know built a company in this ecosystem. There's so many start ups here. Give us kind of that founder viewpoint of being in. They're so sort of ecosystem of the >>ecosystem. So this is how I came into the ecosystem at the beginning. I would have to say that it does feel different. Att This point, I'm gonna speak as Matt, not as now. And so my my thinking has always been It feels a lot like kind of your really your big fan of that rock bands, right? And you go to a local club way all get to know each other at that local club. There's, like maybe 500 of us or 1000 of us. And then that band gets signed a Warner Brothers and goes to the top it. Now there's 20,000 people or 12,000 people. That's how it feels to me right now, I think. But what I like about it is that just shows the power of the community is now at a point where is drawing in like cities now, not just a small collection of a tribe of people, right? And I think that's a very powerful thing with this community. And like all the where they called the kubernetes summits that they're doing way, didn't have any of those back when we first got going. I mean, it was tough to fill the room, you know, Now, now we can fill the room and it's amazing. And what I like seeing is is people moving past the problem with kubernetes itself and moving into, like, what other problems can I solve on top of kubernetes, you know? So you're starting to see that all these really exciting startups doing really need things, you know, and I really likes it like this vendor hall I really like, you know, because you get to see all the new guys. But there's a lot of stuff going on, and I'm excited to see where the community goes in the next five years. But it's we've gone from 0 to 60 insanely because you guys were at the original coupon. I think, Well, >>it's our fourth year doing the Cube at this show, but absolutely we've watched the early days, You know, I'm not supposed to mention open stack of this show, but we remember talking T o J j. And some of the early people there and wait interviewed Chris McCloskey back into Google days, right? So, yeah, we've been fortunate to be on here, really? Day zero here and definitely great energy. So much. Congrats. So much on the progress. Really appreciate the updates, Everything going. As you said, right, we've reached a certain estate and just adding more value on top of this whole >>environment. We're now like we're in, like, Junior high now. Right on were in grade school for a few years. >>All right, Matt. Rob, Thank you so much for the update. Hopefully not an awkward dance tonight for the junior people. For Justin Warren. I'm stupid and back with more coverage here from Q Khan Cloud native 2019. Diego, Thank you for watching Cute

(upbeat music) >> Narrator: Live from the Seattle, Washington, it's the Cube on the ground, covering KubeCon 2016. Brought to you by the Linux Foundation and Red Hat. Here's your host, John furrier. >> Hello, everyone. Welcome to the Cube special on the ground coverage of KubeCon or CloudNativeCon, this is an event. Seattle booming with attendance, great growth from last year, and we are here in Seattle covering it all. And my next guest is Dan Kohn, who's the executive director of the CNCF, which stands for the Cloud Native Computing Foundation. It's a mouthful, but it's super important part of the Linux foundation. Welcome. >> Thanks so much, really glad to be here. >> Yeah, so big fan of what's happening here. One, the event's awesome. Great uptake from last attendance from last year. >> Yeah, unfortunately, maybe a little too much. We're a little crowded in the foyer and a little bumping on the way into getting in the restroom and everything, but it's one of the challenges of fast growing technology space is trying to figure out a year ahead of time, what size space to get? >> And how many people to squeeze in without getting the fire marshal on your back. >> Exactly. >> Certainly this is going to be a great one because the hallway conversation has been spectacular, and normally the excitement's pretty strong at tech events like this because they're developers, so there's a lot of collaboration going on. But you have a kind of an air of really forward-thinking entrepreneurial kind of thinking going on here. And I haven't seen that in a while and I think that's one of the main things that we're seeing that came out of the containers, Kubernetes. I would say the unveiling and the clarity of at least a path. >> Yes, absolutely. >> And the importance of that. So that's been super important to (indistinct) community. Now making that a part of a foundation, an open source, has challenges. So that's what you're doing. So give us the plan, what's the strategy? >> Sure, so I'm actually relatively new to the space. I just became an executive director five months ago, and this is somewhat of a coming out party. This is the first big event that we've run as the first CloudNativeCon. And it's really just been extraordinary. I'm thrilled to see the range where we're getting some of the biggest companies in the world of the Cisco's, and Wallway's, and IBM's, Red Hat's and such. And then tons of startups, and a lot of real diversity in the end-users as well. Of startups looking at Kubernetes, massive companies, just saw a great presentation from Ticketmaster, about them having 50 year old technology that they're moving forward and putting into containers. >> So in the growth of the market, one of the challenges is to kind of, you know, not so much be a chess player, but be a gardener if you will, kind of like let the flowers bloom, if you will. And that's a challenge cause opensource is very opinionated, but there's also a lot of passion involved. So how do you look at, what's your philosophy on establishing kind of a rules of engagement? How do you foster the innovation? Certainly the market drivers are for more growth, but people have inhibitors on the enterprise that we hear about, support and these things of that nature. So how do you enable that? What's your strategy and what's your view? >> Sure, so CNCF is a very new organization. And my goal on it is to look at a lot of the giants that have come before us of like the Internet Engineering Task Force and the Apache Software Foundation and OpenStack. And my goal is to try and learn from them and ideally to try and make entirely new and different mistakes as opposed to the ones that they may have made in the past. So one of the things that's a little unusual in our setup is that we very much separate all of the technology decisions from the business decisions. We have a governing board of a bunch of the biggest technology companies in the world, the ones I mentioned, plus Google and Samsung just joined, which we're very excited about, a number of others. But they can't actually adopt projects in. So we have a separate group called the technical oversight committee, which is some of the top architects in the cloud space. So we have folks like Ben Hindman of Mesosphere, and Solomon Hykes of Docker, Brian Gantt of Google, and six others, and that's the group that looks at new projects and evaluates them and talks to them and decides whether to adopt them into CNCF or not. And we feel that that separation is really critical so that the technology decisions are not being biased by the business one. >> Yeah, it's always hard to foster growth in the innovation around business models, conflicting with the technology enablement, that's really key. Great to see that decoupling. So on the business model side, thoughts on things that you've learned and observed, learnings that you've had in your past career and applying that now, I mean, the Bait, the rage is on, Open Core to Apache, GPL, you saw some things going on there. So there's like all kinds of different approaches. Are there any thoughts of the winds blowing any which way or the other? >> Sure, I was previously the chief operating officer at the Linux Foundation between '06 and '10, and I definitely think you can, CNCF as part of the Linux Foundation, we took that model of saying, "the technology decisions "need to be separate from business ones." One thing that's interesting to me is that when I was last in this space 10 years ago, people were perfectly fine. Linux Journals, GPL, people were fine with free licenses like MIT and BSD. Since then, and for this group, there is an enormous focus on the Apache license. And the reason why, is the fear of submarine patents. And so the whole goal of CNCF is for us to be an intellectual property no fly zone. That you can have all of these companies that compete very hard in the marketplace, but they can come together and collaborate and share their ideas and their technology without the belief that a couple years later, someone's going to be able to trick someone else in with a lawsuit, and win that. And the Apache license is really the industry consensus right now for best practices. >> It's interesting cause that no fly zone gives the freedom for the creation and the invention side of it. The patent thing is always worrisome, but in general, there's also the business model down the road kind of approach. Which is, "let's go innovate." Apache has done great on packaging. Have someone get some traction. It fosters the community aspect as well as a startup. Maybe not thinking about packaging. >> No, we have an advantage that we're not, unlike OpenStack as an example, we're not trying to come up with the projects ourself. What we're actually doing is scouring the Cloud Native landscape, talking to different groups and saying, "Oh, what do we think is "the best in class project out there?" And in some cases it's more than one, but today we just announced the fourth project that's added to the CNCF. So we have Kubernetes, we have Prometheus, which is a monitoring application. OpenTracing is a tracing, and then today we just added Fluentd, which is a logging solution. And this is the idea that if you have dozens or hundreds of different applications and projects that are each producing a log stream, and then you have a perhaps dozens of other applications that are consuming it, you don't want to have an M times N problem of creating adapters for all of them. Instead, you can plug them all into Fluentd, it has over 300 adapters for different solutions out there. And that provides one comprehensive approach. But what's interesting is that we don't need to win over the community and say, "Oh, here's this project you may not have heard of." There's actually over 2000 users of that today. But by having them here at CNCF, showing how it plugs into other technologies of ours, we think we can hope-- >> You're cross-pollinating? >> Dan: Exactly. >> You're letting it bubble up and you're not being a-- >> Dan: That's exactly the metaphor. >> (laughs) A dictator. Okay, and back to the project side, this is awesome. So you have some gravity around these projects. Is there any cadence or expectation, or is it free for all in terms of the velocity of adoption of projects that the technical committee will oversight? >> We would love to be at the pace of one a month. And I don't know that we'll quite get that fast. One big change that we're hoping to make in the next month or two. When our first two projects were Kubernetes and Prometheus, those are two of the fastest growing best respected projects on GitHub right now. We didn't want to have such a high milestone for every other project we considered. So we're adopting what we think we're going to call an inception stage of earlier projects that we're going to sort of try out, but they have to essentially prove themselves within 12 months. And hopefully that'll allow us to keep a pretty good velocity where we think there's a fantastic number of projects, we think as a community, we can-- >> Yeah, let people fight it out, surface stuff and let people kick the tires, right? That's the incubation period basically. What about the forking and all the battle cage matches that go on, how do you want to handle that or you just let nature take its course? Is that philosophy there? >> Thankfully, when we look at the space and this is really coming out of the Linux Space as well, anyone can fork, and of course it has a slightly different connotation now with GitHub, where when you make a change, you fork it, but there's also just a massive centripetal force pushing people together. And when you have a really high velocity of changes, the idea of forking and you would lose out on that, becomes a lot less appealing. And so, so far thankfully, all of our members and everyone in the community has really been on board on having a single head on working together to have that consultation. >> We just had Richard Kaufman on from, I think Robert Kaufman, I mean, from Samsung, he was talking about that the number two contributor is other. >> Dan: Yes. >> Which is a nice balance to the whole critical mass. >> It's an incredible accomplishment cause for Google to pull in enough people that they're no longer the majority contributor, is something that we're thrilled with. >> Yeah, it's great to see you have Richard Kaufman. Google is the number one contributor, are you worried about that? Maybe, they've been certainly good actors in the community. I mean, they had MapReduce and let Cloudera run with it, look at what happened with that? So, we kind of all know this backstory of Kubernetes, they're kind of letting it bloom on its own. That's consistent with their current posturing? >> Well, I don't think they want to have another Cloudera. >> Which is why they embraced Kubernetes. >> But I definitely don't think it's fair to say that they're doing it on their own. They're still the largest contributor of any one company and they have a massive amount of resources, and I think they see it as a really key technology, it's something they mentioned-- >> What I was referring to is that Cloudera kind of took MapReduce under their wing and made a commercial venture out. >> Dan: Oh yeah, absolutely. >> I think Google didn't want that. >> No, and they, I mean, the way I think about it is, they had this technology a few years ago. This is definitely oversimplified. They could have kept it as a proprietary in the house thing, like Amazon Elastic Container Service. They could have made it an internal open source project, like Go, or they could have just created a Kubernetes foundation that allowed other people in, but they still controlled it. But instead they were really interested in working with the Linux Foundation and creating this Cloud Native Computing Foundation that was always designed to be much more than just Kubernetes. And that really was about trying to push the project out of the nest. But I will say that my understanding is they're still see that as an absolutely core for their business. >> Yeah, I got to give Google props out there for that because they did do the right thing there. they put it out in the open, they did a line, and they could have land grabbed that, in a different way, I mean, certainly not the way that one was above. Final question on this event, KubeCon or KubernetesCon, KubeCon, it's KubeCon, however people call it. Not to confuse with the Cube, this Cube product which is seven years and might be trademark infringement but yeah, we'll get that later. >> Dan: With a K. (both laughing) >> It's still causing a lot of confusion. But that aside, CloudNativeCon also is in conjunction, this is part of the expansion you were mentioning. Talk about the vision for the events, you got one in Berlin coming up, and certainly you could have had probably at least a few more thousand people here for sure. >> Oh well, certainly a few more hundred. And we do feel a little bad that we didn't quite aim high enough. So our vision going forward is that we have CloudNativeCon that represents all of our projects, and that KubeCon represents the biggest part of CloudNativeCon. So it's multiple tracks. It's what a ton of folks go for but we think that it also gives us a chance to expose those people to our other projects, and by the time we get to Berlin, we're certainly hoping that we have another two or three or more projects-- >> And the date on Berlin? >> It's March 29th and 30th. And then we also announced that we're going to be in Austin, in early December. And I'll say that for both of those events, we're tripling the capacity from what we had last year. So we're hoping not to be so crowded. >> I was talking to Andy Jassy last night, we had a one-on-one with him and he's talking about the first Reinvent, he didn't think he can get 4,000 people there as packed. I think you might be, having to look at more capacity potentially. I mean, at this pace. >> It's the hard question is we'd actually like to be signing contracts for 2018, and it's just really hard to predict what the right size is to get for that, because I feel terrible about the fact that we did turn people away, especially end-users that we'd like to be introducing to this space. >> Yeah, well, I can attest people watching this, definitely a fire marshal issue, because it's really packed. That's why we're in a separate room here. There was sunlight in the background earlier. Normally, we're on the show floor with the Cube, but yeah, every space is taken, hallways are jamming. >> The other thing I'll mention though, is that we are also interested in going out and reaching customers and vendors where they are. So we're going to have a booth at AWS Reinvent, and we're looking at other conferences that we can be at to help spread the Cloud Native word. >> We're certainly going to be able to have a hundred events this year, so let us know where you're at, we'll certainly bring you guys on. Let me give you the final word. Tell the folks why Kubernetes is so important. Why is this movement, why are people so excited here? For the folks that couldn't make it, what's the vibe, why is it important, and what's the impact to customers in the industry? >> So the belief is that if you're deploying a new modern software application that, putting into containers, using an orchestration platform like Kubernetes, dividing your app up into microservices is a really such a benefit in terms of optimizing your resources, and tying into a whole rapid development process, continuous integration, continuous deployment, that not doing it almost makes it impossible to compete. And so we think there's just a ton of momentum around containerization and orchestration. >> And the speed of the innovation is one of those things if you're not on it, you fall further behind and it takes more energy to catch up if you try to do it by yourself. That's the benefit of the collective communities and it highlights open source. >> Right. >> Big time in terms of successes. Dan, thanks so much for coming on, sharing the perspective, congratulations and sorry for the folks who couldn't make it, hopefully this video will help. This is the Cube here in Seattle for special coverage of CloudNativeCon and KubeCon, here in Seattle. Thanks for watching, I'm John furrier. >> Dan: Thanks. (upbeat music)