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

(bright symphony music) >> Hello, I'm John Furrier, the founder of SiliconANGLE Media and co-host of theCUBE. We're here in Paulo Alto at our studio here. I'm joining with Joseph Jacks, the founder and general partner of OSS Capital. Open Source Software Capital, is what OSS stands for. He's also the founder of KubeCon which now is part of the CNCF. It's a huge conference around Kubernetes. He's a cloud guy. He knows open source. Very well respected in the industry and also a great guest and friend of theCUBE, CUBE alumni. Joseph, great to see you. Also known as JJ. JJ, good to see you. >> Thank you for having me on again, John. >> Hey, great to have you come on. I know we've talked many times on theCUBE, but you've got some exciting news. You got a new firm, OSS Capital. Open Source Software, not operational support like a telco, but this is an investment opportunity where you're making investments. Congratulations. >> Thank you. >> So I know you can't talk about some of the specifics on the funds size, but you are actually going to go out, talk to entrepreneurs, make some equity investments. Around open source software. What's the thesis? How did you get here, why did you do it? What's motivating you, and what's the thesis? >> A lot of questions in there. Yeah, I mean this is a really profoundly huge year for open source software. On a bunch of different levels. I think the biggest kind of thing everyone anchors towards is GitHub being acquired by Microsoft. Just a couple of weeks ago, we had the two huge hadoop vendors join forces. That, I think, surprised a lot of people. MuleSoft, which is a big opensource middleware company, getting acquired by Salesforce just a year after going public. Just a huge outcome. I think one observation, just to sort of like summarize the year 2018, is actually, starting in January, almost on sort of like a monthly basis, we've observed a major sort of opensource software company outcome. And sort of kicking off the year, we had CoreOS getting acquired by Red Hat. Brandon and Alex, the founders over there, built a really interesting company in the Kubernetes ecosystem. And I think in February, Al Fresco, which is an open source content portal taking privatization outcome from a private equity firm, I believe in March we had Magento getting acquired by Adobe, which an open source based CMS. PHP CMS. So just a lot of activity for significant outcomes. Multibillion dollar outcomes of commercial open source companies. And open source software is something like 20 years old. 20 years in the making. And this year in particular, I've just seen just a huge amount of large scale outcomes that have been many years in the making from companies that have taken lots of venture funding. And in a lot of cases, sort of partially focused funding from different investors that have an affinity for open source software and sort of understand the uniqueness of the open source model when it's applied to business, when it's applied to company building. But more sort of opportunistic and sort of affinity oriented, as opposed to a pure focus. So that's kind of been part of the motivation. I'd say the more authentically compelling motivation for doing this is that it just needs to exist. This is sort of a model that is happening by necessity. We're seeing more and more software companies be open source software companies. So open source first. They're built in a distributed way. They're leveraging engineers and talent around the world. They're just part of this open source kind of philosophy. And they are fundamentally kind of commercial open source software companies. We felt that if you had a firm basically designed in a way to exclusively focus on those kind of companies, and where the firmware actually backed and supported by the founders of the largest commercial open source companies in the world before sort of the last decade. That could actually deliver a lot of value. So we've been sort of blogging a little bit about this. >> And you wrote a great post on it. I read about open source monetization. But I think one of the things I'm seeing as well that supports your thesis, and I like to get your reaction to it because I think this is something that's not really talked about, but open source is still young. I mean, you go back. I remember the days when we used to have to hide in the shadows to get licenses and pirate stuff and do all those crazy stuff. But now, it's only a couple decades away. The leaders that were investing were usually entrepreneurs that've been successful. The Rob Bearns, the Amar Wadhwa, the guy that did Spring. All these different open source. Linux, obviously, great success story. But there hasn't any been any institutional. Yeah, you got benchmark, other things, done some investments. A discipline around open source. Where open source is now table stakes in all software development. Cloud is scaling, scaling out globally. There's no real foc- There's never been a firm that's been focused on- Just open source from a commercial, while maintaining the purity and ethos of open source. I mean, is that. >> You agree? >> That's true. >> 100%, yeah. That's been the big part of creating the firm is aligning and solving for a pure focused structure. And I think what I'll say abstractly is this sort of venture capital, venture style approach to funding enterprise technology companies, software companies in general, has been to kind of find great entrepreneurs and in an abstract way that can build great technology companies. Can bring them to market, can sell them, and can scale them, and so on. And either create categories, or dominate existing categories, and disrupt incumbents, and so on. And I think while that has worked for quite a while, in the venture industry overall, in the 50, 60 years of the venture industry, lots of successful firms, I think what we're starting to see is a necessary shift toward accounting for the fundamental differences of opensource software as it relates to new technology getting created and going, and new software companies kind of coming into market. So we actually fundamentally believe that commercial open source software companies are fundamentally different. Functionally in almost every way, as compared to proprietary closed source software companies of the last 30 years. And the way we've sort of designed our firm and we'll about ten people pretty soon. We're just about a month in. We're growing the team quickly, but we're sort of a small, focused team. >> A ten's not focused small, I mean, I know venture firms that have two billion in management that don't have more than 20 people. >> Well, we have portfolio partners that are focused in different functional areas where commercial open source software companies have really fundamental differences. If you were to sort of stack rank, by function, where commercial open source software companies are really fundamentally different, sort of top to bottom. Legal would be, probably, the very top of the list. Right, in terms of license compliance management, structuring all the sort of protections and provisions around how intellectual property is actually shipped to and sold to customers. The legal licensing aspects. The commercial software licensing. This is quite a polarizing hot topic these days. The second big functional area where we have a portfolio partner focused on this is finance. Finance is another area where commercial open source software companies have to sort of behaviorally orient and apply that function very, very differently as compared to proprietary software companies. So we're crazy honored and excited to have world experts and very respected leaders in those different areas sort of helping to provide sort of different pillars of wisdom to our portfolio companies, our portfolio founders, in those different functional areas. And we provide a really focused kind of structure for them. >> Well I want to ask you the kind of question that kind of bridges the old way and new way, 'cause I definitely see you guys definitely being new and different, which is good. Or as Andy Jassy would say, you can be misunderstood for a while, but as you become successful, people will start understanding what you do. And that's a great example of Amazon. The pattern with success is traditionally the same. If we kind of encapsulate the difference between open source old and new, and that is you have something of value, and you're disrupting the market and collecting rents from it. Or revenue, or profit. So that's commercial, that's how businesses run. How are you guys going to disrupt with open source software the next generation value creation? We know how value's created, certainly in software that opensource has shown a path on how to create value in writing software if code is value and functionality's value. But to commercialize and create revenue, which is people paying something for something. That's a little bit different kind of value extraction from the value creation. So open source software can create value in functionality and value product. Now you bring it to the market, you get paid for it, you have to disrupt somebody, you have to create something. How are you looking at that? What's the vision of the creation, the extraction of value, who's disrupted, is it greenfield new opportunities? What's your vision? >> A lot of nuance and complexity in that question. What I would say is- >> Well, open source is creating products. >> Well, open source is the basis for creating products in a different kind of way. I'll go back to your question around let's just sort of maybe simplify it as the value creation and the value capture dynamics, right? We've sort of written a few posts about this, and it's subtle, but it's easy to understand if you look at it from a fundamental kind of perspective. We actually believe, and we'll be publishing research on this, and maybe even sort of more principled scientific, perhaps, even ways of looking at it. And then blog posts and research. We believe that open source software will always generate or create orders of magnitude more value than any constituent can capture. Right, and that's a fundamental way of looking at it. So if you see how cloud providers are capturing value that open source creates, whether it's Elasticsearch, or Postgres, or MySQL or Hadoop. And then commercial open source software companies that capture value that open source software creates, whether it's companies like Confluent around Kafka, or Cloudera around Hadoop, or Databricks around Apache Spark. Or whether it's the creators of those projects. The creators of Spark and Hadoop and Elasticsearch, sometimes many of them are the founders of those companies I mentioned, and sometimes they're not. We just believe regardless of how that sort of value is captured by the cloud providers, the commercial vendors, or the creators, the value created relative to the value captured will always be orders and orders of magnitude greater. And this is expressed in another way, which this may be easier to understand, it's a sort of reinforcing this kind of assertion that there's orders of magnitude value created far greater than what can be captured. If you were to do a survey, which we're currently in the process of doing, and I'm happy to sort of say that publicly for the first time here, of all the commercial open source software companies that have projects with large significant adoption, whether, say for example, it's Docker, with millions of users, or Apache Hadoop. How many Hadoop deployments there are. How many customers' companies are there running Hadoop deployments. Or it may be even MySQL. How many MySQL installations are there. And then you were to sort of survey those companies and see how many end users are there relative to how many customers are paying for the usage of the project. It would probably be something like if there were a million users of a given project, the company behind that project or the cloud provider, or say the end user, the developer behind the project, is unlikely to capture more than, say, 1% or a couple percent of those end users to companies, to paying companies, to paying customers. And many times, that's high. Many times, 1% to 2% is very high. Often, what we've seen actually anecdotally, and we're doing principled research around this, and we'll have data here across a large number of companies, many times it's a fraction of 1%. Which is just sort of maybe sometimes 10% of 1%, or even smaller. >> So the practitioners will be making more money than the actual vendors? >> Absolutely right. End users and practitioners always stand to benefit far greater because of the fundamental nature of open source. It's permissionless, it's disaggregated, the value creation dynamics are untethered, and it is fundamentally freely available to use, freely available to contribute to, with different constraints based on the license. However, all those things are sort of like disaggregating the creating of technology into sort of an unbounded network. And that's really, really incredible. >> Okay, so first of all, I agree with your premise 100%. We've seen it with CUBE, where videos are free. >> And that's a good thing. All those things are good. >> And Dave Vellante says this all the time on theCUBE. And we actually pointed this out and called this in the Hadoop ecosystem in 2012. In fact, we actually said that on theCUBE, and it turned out to be true, 'cause look at Hortonworks and Cloudera had to merge because, again, the market changed very quickly >> Value Creation. >> Because value >> Was created around them in the immediate cloud, etc. So the question is, that changes the valuation mechanisms. So if this true, which we believe it is. Just say it is. Then the traditional net present value cash flow metric of the value of the firm, not your firm, but, like, if I'm an open source firm, I'm only one portion of the extraction. I'm a supplier, and I'm an enabler, the valuation on cash flow might not be as great as the real impact. So the question I have for you, have you thought about the valuation? 'Cause now you're thinking about bigger construct community network effects. These are new dynamics. I don't think anyone's actually crunched a valuation model around this. So if someone knew that, say for example, an open source project created all this value, and they weren't necessarily harvesting it from a cash flow perspective, there might be other ways to monetize it. Have you though about that, and what's your reaction to that concept? 'Cause capitalism would kind of shake down the system. 'Cause why would someone be motivated to participate if they're not capturing any value? So if the value shifts, are they still going to be able to participate? You follow the logic I'm trying to- >> I definitely do. I think what I would say to that is we expect and we encourage and we will absolutely heavily invest in more business model innovation in the area of open source. So what I mean by that is, and it's important to sort of qualify a few things there. There's a huge amount of polarization and lack of consensus, lack of industry consensus on what it actually means to have or implement an open source based business model. In fact there's a lot of people who just sort of point blankedly assert that an opensource business model does not exist. We believe that many business models for monetizing and commercializing open source exist. We've blogged and written about a few of them. Their services and training and support. There's open core, which is very effective in sort of a spectrum of ways to implement open core. Around the core, you can have a thin crust or a thick crust. There's SAS. There are hardware based distribution models, things like Sourcefire, and Cumulus Networks. And there are also network based approaches. For example, project called Storj or Stor-J. Being developed and run now by Ben Golub, who's the former CEO of Docker. >> CUBE alumni. >> Ben's really great open source veteran. This is a network, kind of decentralized network based approach of sort of right sizing the production and consumption of the resource of a storage based open source project in a decentralized network. So those are sort of four or five ways to commercializing value, however, four or five ways of commercializing value, however what we believe is that there will be more business model innovation. There will be more developments around how you can better capture more, or in different ways, the value that open source creates. However, what I will say though, is it is unrealistic to expect two things. It is unrealistic and, in fact, unfair to expect that any of those constituents will contribute back to open source proportional to the value that they received from it, or the benefit, and I'm actually paraphrasing Doug Cutting there, who tweeted this a couple of years ago. Very profoundly deep, wise tweet, which I very strongly agree with. And it is also unrealistic to expect a second thing, which is that any of those constituents can capture a material portion of the value that open source creates, which I would assert is many trillions of dollars, perhaps tens of trillions of dollars. It's really hard to quantify that. And it's not just dollars in economic sense, it's dollars in productivity time saved, new markets, new areas, and so on. >> Yeah, I think this is interesting, and I think that we'll be an open book at that. But I will say that what I've observed in looking through all these CUBE interviews, I think that business model innovation absolutely is something that is an IP. >> We need it. Well, it's now intellectual property, the business model isn't, hey I went to business school, learned this at Babson or Harvard, I learned this business model. We're going to do SAS premium. Okay, I get that. There's going to be very interesting new innovations coming, and I think that's the new IP. 'Cause open source, if it's community based, there's going to be formulas. So that's going to be really inter- Okay, so now let's get back to actual funding itself. You guys are doing early stage. Can you take us through the approach? >> We're very focused on early stage, investing, and backing teams that are, just sort of welcoming the idea of a commercial entity around their open source project. Or building a business fundamentally dependent on an open source project or maybe even more than one. The reason for that is this is really where there's a lot of structural inefficiency in supporting and backing those types of founders. >> I think one of the things with ... is with that acquisition. They were pure on the open source side, doing a great job, didn't want to push the business model too hard because the open source, let's face it, you got people like, eh, I don't want to get caught on the business side, and get revenue, perverse incentives might come up, or fear of incentives that might be different or not aligned. Was a great a value. >> I think so. >> So Red Hat got a steal on that one. But as you go forward, there's going to be certainly a lot more stuff. We're seeing a lot of it now in CNCF, for instance. I want to get your thoughts on this because, being the co founder of KubeCon, and donating it to the CNCF, Kubernetes is the hottest thing on the planet, as we talked about many years ago. What's your take on that, now? I see exciting things happening. What is the impact of Kubernetes, in your opinion, to the world, and where do you see that evolving rapidly, and where is the focus here as the people should be paying attention to? >> I think that Kubernetes replaces EC2. Kubernetes is a disaggregated API for distributed computing anywhere. And it happens to be portable and able to run on any kind of computer infrastructure, which sort of makes it like a liquid disaggregated EC2-like API. Which a lot of people have been sort of chasing and trying to implement for many years with things like OpenStack or Eucalyptus. But interestingly, Kubernetes is sort of the right abstraction for distributed computing, because it meets people where they are architecturally. It's sort of aligned with this current movement around distributed systems first designs. Microservices, packaging things in small compartmentalized units. >> Good for integrating of existing stuff. >> Absolutely, and it's very composable, un-opinionated architecturally. So you can sort of take an application and structure it in any given way, and as long as it has this sort of isolation boundary of a container, you can run it on Kubernetes without needing to sort of retrofit the architecture, which is really awesome. I think Kubernetes is a foundational part of the next kind of computing paradigm in the same way that Linux was foundational to the computing paradigm that gave rise to the internet. We had commodity hardware meeting open source based sort of cost reduction and efficiency, which really Linux enabled, and the movement toward scale out data center infrastructure that supported the Internet's sort of maturity and infrastructure. I think we're starting to see the same type of repeat effect thanks to Kubernetes basically being really well received by engineers, by the cloud providers. It's now the universal sort of standard for running container based applications on the different cloud providers. >> And think having the non-technical opinion posture, as you said, architectural posture, allows it to be compatible with a new kind of heterogeneous. >> Heterogeneity is critical. >> Heterogeneity is key, 'cause it's not just within the environment, it's also within each vendor, or customer has more heterogeneity. So, okay, now that's key. So multi cloud, I want to get your thoughts on multi cloud, because now this goes into some of things that might build on top of if Kubernetes continues to go down the road that you say it does. Then the next question is, stateful applications, service meshes. >> A lot of buzz words. A lot of buzz words in there. Stateful application's real because at a certain point in time, you have a maturity curve with critical infrastructure that starts to become appealing for stateful mission critical storage systems, which is typically where you have all the crown jewels of a given company's infrastructure, whether it's a transactional system, or reading and writing core customer, or financial service information, or whatever it is. So Kubernetes' starting to hit this maturity curve where people are migrating really serious mission critical storage workloads onto that platform. And obviously we're going to start to see even more critical work loads. We're starting to see Edge workloads because Kubernetes is a pretty low footprint system, so you can run it on Edge devices, you can even run it on microcontrollers. We're sort of past the experimental, you know, fun and games was Raspberry Pi, sort of towers, and people actually legitimately doing real world Edge kind of deployments with Kubernetes. We're absolutely starting to see multi-geo, multi-replication, multi-cloud sort of style architectures becoming real, as well. Because Kubernetes is this API that the industry's agreeing upon sufficiently. We actually have agreement around this sort of surface area for distributed system style computing that if cloud providers can actually standardize on in a way that lets application specific vendors or new types of application deployment models innovate further, then we can really unlock this sort of tight coupling of proprietary services inside cloud providers and disaggregate it. Which is really exciting, and I forget the Netscape, Jim Barksdale. Bundling, un-bundling. We're starting to see the un-bundling of proprietary cloud computing service API's. Things like Kinesis, and ALB and ELB and proprietary storage services, and these other sticky services get un-bundled because of two big things. Open source, obviously, we have open source alternative data paths. And then we have Kubernetes which allows us to sort of disaggregate things out pretty easily. >> I want to hear your thoughts, one final concept, before we break, 'cause I was having a private conversation with three people besides myself. A big time CIO of a company that if I said the name everyone would go, oh my god, that guy is huge, he's seen it all going back many, many ways. Currently done a lot of innovation. A hardcore network chip guy who knows networking, old school infrastructure. And then a cloud native application founder who knows a lot about software development and is state-of-the-art cloud native. So cloud native, all experienced, old-school, kind of about my age, a cloud native app developer, a big time CIO, and a chip networking kind of infrastructure guy. And we're talking, and one thing that came out, I want to get you thoughts on this, he says, so what's going on with DevOps, how do you see this service mesh, is a stay for (mumbles) on top of the stack, no stacks, horizontally scalable. And the comment that came out was storage and networking have had this relationship with everything since day one. Network moves a packet from point A to point B, and nothing happens in between, maybe some inspection. And storage goes from here now to the then, because you store it. He goes, that premise moves up the stacks, so then the cloud native guy goes, well that's what's happening up at the top, there's a lot of moving things around, workloads and or services, provisioning services, and then from now to then state. In real time. And what dawned on the next conversation the CIO goes, well this is exactly our challenge. We have under the hood infrastructure being programmable, >> We're having some trouble with the connection. Please try again. >> My phone's calling me. >> Programmable connections. >> So you got the programmable on the top of the stack too, so the CIO said, that's exactly the problem we're trying to solve. We're trying to solve some of these network storage concepts now at an application level. Your thoughts to that. >> Well, I think if I could tease apart everything you just said, which is profound synthesis of a lot of different things, I think we've started to see application logic leak out of application code itself into dedicated layers that are really good at doing one specific thing. So traditionally we had some crud style kind of behavioral semantics implemented around business logic. And then, inside of that, you also had libraries for doing connectivity and lookups and service discovery and locking and key management and encryption and coordination with other types of applications. And all that stuff was sort of shoved into the single big application binary. And now, we're starting to see all those language runtime specific parts of application code sort of crack or leak out into these dedicated, highly scalable, Unix philosophy oriented sort of like layers. So things like Envoy are really just built for the sort of nervous system layer of application communication fabric up and down the layer two through layer seven sort of protocol transport stack, which is really profound. We're seeing things like Vault from Hashicorp handle secure key storage persistence of application dedication, authorization, metadata and information to sort of access different systems and end points. And that's a dedicated sort of stateful layer that you can sort of fragment out and delegate sort of application specific functionality to, which is really great for scalability reasons. And on, and on, and on. So we've started to see that, and I think one way of looking at that is it's a cycle. It's the sort of bundling and un-bundling aspect. >> One of the granny level services are getting a really low level- >> Yeah, it's a sort of like bundling and un-bundling and so we've got all this un-bundling happening out of application code to these dedicated layers. The bundling back may happen. I've actually seen a few Bay Area companies go like, we're going back to the monolith 'cause it actually gives us lots of efficiencies in things that we though were trade offs before. We're actually comfortable with a big monorepo, and one or two core languages, and we're going to build everything into these big binaries, and everyone's going to sort of live in the same source code repository and break things out through folders or whatever. There's a lot of really interesting things. I don't want to say we're sort of clear on where this bundling, un-bundling is happening, but I do think that there's a lot of un-bundling happening right now. And there's a lot of opportunity there. >> And the open source, obviously, driving it. So final question for you, how many deals have you done? Can you talk a little bit about the firm? And exciting things and plans that you have going forward. >> Yeah, we're going to be making a lot of announcements over the next few months, and we're, I guess, extremely thrilled. I don't want to say overwhelmed, 'cause we're able to handle all of the volume and inquiries and inbound interest. We're really honored and thrilled by the reception over the last couple weeks from announcing the firm on the first of October, sort of before the Hortonworks Cloudera merger. The JFrog funding announcement that week. The Elastic IPO. Just a lot of really awesome things happened that week. This is obviously before Microsoft open sourced all their patents. We'll be announcing more investments that we've made. We announced our first one on the first of October as well with the announcement of the firm. We've made a good number of investments. We're not able to talk to much about our first initiative, but you'll hear more about that in the near future. >> Well, we're excited. I think it's the timing's perfect. I know you've been working on this kind of vision for a while, and I think it's really great timing. Congratulations, JJ >> Thank you so much. Thanks for having me on. >> Joesph Jacks, also known as JJ, founder and general partner of OSS Capital, Open Source Software Capital, co founder of KubeCon, which is now part of the CNCF. A real great player in the community and the ecosystem, great to have him on theCUBE, thanks for coming in. I'm John Furrier, thanks for watching. >> Thanks, John. (bright symphony music)

>> Live from New York, it's theCUBE covering theCUBE New York City 2018. Brought to you by SiliconANGLE Media and its ecosystem partners. (techy music) >> Hello, everyone, welcome to this CUBE special presentation here in New York City for CUBENYC. I'm John Furrier with Dave Vellante. This is our ninth year covering the big data industry, starting with Hadoop World and evolved over the years. This is our ninth year, Dave. We've been covering Hadoop World, Hadoop Summit, Strata Conference, Strata Hadoop. Now it's called Strata Data, I don't know what Strata O'Reilly's going to call it next. As you all know, theCUBE has been present for the creation at the Hadoop big data ecosystem. We're here for our ninth year, certainly a lot's changed. AI's the center of the conversation, and certainly we've seen some horses come in, some haven't come in, and trends have emerged, some gone away, your thoughts. Nine years covering big data. >> Well, John, I remember fondly, vividly, the call that I got. I was in Dallas at a storage networking world show and you called and said, "Hey, we're doing "Hadoop World, get over there," and of course, Hadoop, big data, was the new, hot thing. I told everybody, "I'm leaving." Most of the people said, "What's Hadoop?" Right, so we came, we started covering, it was people like Jeff Hammerbacher, Amr Awadallah, Doug Cutting, who invented Hadoop, Mike Olson, you know, head of Cloudera at the time, and people like Abi Mehda, who at the time was at B of A, and some of the things we learned then that were profound-- >> Yeah. >> As much as Hadoop is sort of on the back burner now and people really aren't talking about it, some of the things that are profound about Hadoop, really, were the idea, the notion of bringing five megabytes of code to a petabyte of data, for example, or the notion of no schema on write. You know, put it into the database and then figure it out. >> Unstructured data. >> Right. >> Object storage. >> And so, that created a state of innovation, of funding. We were talking last night about, you know, many, many years ago at this event this time of the year, concurrent with Strata you would have VCs all over the place. There really aren't a lot of VCs here this year, not a lot of VC parties-- >> Mm-hm. >> As there used to be, so that somewhat waned, but some of the things that we talked about back then, we said that big money and big data is going to be made by the practitioners, not by the vendors, and that's proved true. I mean... >> Yeah. >> The big three Hadoop distro vendors, Cloudera, Hortonworks, and MapR, you know, Cloudera's $2.5 billion valuation, you know, not bad, but it's not a $30, $40 billion value company. The other thing we said is there will be no Red Hat of big data. You said, "Well, the only Red Hat of big data might be "Red Hat," and so, (chuckles) that's basically proved true. >> Yeah. >> And so, I think if we look back we always talked about Hadoop and big data being a reduction, the ROI was a reduction on investment. >> Yeah. >> It was a way to have a cheaper data warehouse, and that's essentially-- Well, what did we get right and wrong? I mean, let's look at some of the trends. I mean, first of all, I think we got pretty much everything right, as you know. We tend to make the calls pretty accurately with theCUBE. Got a lot of data, we look, we have the analytics in our own system, plus we have the research team digging in, so you know, we pretty much get, do a good job. I think one thing that we predicted was that Hadoop certainly would change the game, and that did. We also predicted that there wouldn't be a Red Hat for Hadoop, that was a production. The other prediction was is that we said Hadoop won't kill data warehouses, it didn't, and then data lakes came along. You know my position on data lakes. >> Yeah. >> I've always hated the term. I always liked data ocean because I think it was much more fluidity of the data, so I think we got that one right and data lakes still doesn't look like it's going to be panning out well. I mean, most people that deploy data lakes, it's really either not a core thing or as part of something else and it's turning into a data swamp, so I think the data lake piece is not panning out the way it, people thought it would be. I think one thing we did get right, also, is that data would be the center of the value proposition, and it continues and remains to be, and I think we're seeing that now, and we said data's the development kit back in 2010 when we said data's going to be part of programming. >> Some of the other things, our early data, and we went out and we talked to a lot of practitioners who are the, it was hard to find in the early days. They were just a select few, I mean, other than inside of Google and Yahoo! But what they told us is that things like SQL and the enterprise data warehouse were key components on their big data strategy, so to your point, you know, it wasn't going to kill the EDW, but it was going to surround it. The other thing we called was cloud. Four years ago our data showed clearly that much of this work, the modeling, the big data wrangling, et cetera, was being done in the cloud, and Cloudera, Hortonworks, and MapR, none of them at the time really had a cloud strategy. Today that's all they're talking about is cloud and hybrid cloud. >> Well, it's interesting, I think it was like four years ago, I think, Dave, when we actually were riffing on the notion of, you know, Cloudera's name. It's called Cloudera, you know. If you spell it out, in Cloudera we're in a cloud era, and I think we were very aggressive at that point. I think Amr Awadallah even made a comment on Twitter. He was like, "I don't understand "where you guys are coming from." We were actually saying at the time that Cloudera should actually leverage more cloud at that time, and they didn't. They stayed on their IPO track and they had to because they had everything betted on Impala and this data model that they had and being the business model, and then they went public, but I think clearly cloud is now part of Cloudera's story, and I think that's a good call, and it's not too late for them. It never was too late, but you know, Cloudera has executed. I mean, if you look at what's happened with Cloudera, they were the only game in town. When we started theCUBE we were in their office, as most people know in this industry, that we were there with Cloudera when they had like 17 employees. I thought Cloudera was going to run the table, but then what happened was Hortonworks came out of the Yahoo! That, I think, changed the game and I think in that competitive battle between Hortonworks and Cloudera, in my opinion, changed the industry, because if Hortonworks did not come out of Yahoo! Cloudera would've had an uncontested run. I think the landscape of the ecosystem would look completely different had Hortonworks not competed, because you think about, Dave, they had that competitive battle for years. The Hortonworks-Cloudera battle, and I think it changed the industry. I think it couldn't been a different outcome. If Hortonworks wasn't there, I think Cloudera probably would've taken Hadoop and making it so much more, and I think they wouldn't gotten more done. >> Yeah, and I think the other point we have to make here is complexity really hurt the Hadoop ecosystem, and it was just bespoke, new projects coming out all the time, and you had Cloudera, Hortonworks, and maybe to a lesser extent MapR, doing a lot of the heavy lifting, particularly, you know, Hortonworks and Cloudera. They had to invest a lot of their R&D in making these systems work and integrating them, and you know, complexity just really broke the back of the Hadoop ecosystem, and so then Spark came in, everybody said, "Oh, Spark's going to basically replace Hadoop." You know, yes and no, the people who got Hadoop right, you know, embraced it and they still use it. Spark definitely simplified things, but now the conversation has turned to AI, John. So, I got to ask you, I'm going to use your line on you in kind of the ask-me-anything segment here. AI, is it same wine, new bottle, or is it really substantively different in your opinion? >> I think it's substantively different. I don't think it's the same wine in a new bottle. I'll tell you... Well, it's kind of, it's like the bad wine... (laughs) Is going to be kind of blended in with the good wine, which is now AI. If you look at this industry, the big data industry, if you look at what O'Reilly did with this conference. I think O'Reilly really has not done a good job with the conference of big data. I think they blew it, I think that they made it a, you know, monetization, closed system when the big data business could've been all about AI in a much deeper way. I think AI is subordinate to cloud, and you mentioned cloud earlier. If you look at all the action within the AI segment, Diane Greene talking about it at Google Next, Amazon, AI is a software layer substrate that will be underpinned by the cloud. Cloud will drive more action, you need more compute, that drives more data, more data drives the machine learning, machine learning drives the AI, so I think AI is always going to be dependent upon cloud ends or some sort of high compute resource base, and all the cloud analytics are feeding into these AI models, so I think cloud takes over AI, no doubt, and I think this whole ecosystem of big data gets subsumed under either an AWS, VMworld, Google, and Microsoft Cloud show, and then also I think specialization around data science is going to go off on its own. So, I think you're going to see the breakup of the big data industry as we know it today. Strata Hadoop, Strata Data Conference, that thing's going to crumble into multiple, fractured ecosystems. >> It's already starting to be forked. I think the other thing I want to say about Hadoop is that it actually brought such great awareness to the notion of data, putting data at the core of your company, data and data value, the ability to understand how data at least contributes to the monetization of your company. AI would not be possible without the data. Right, and we've talked about this before. You call it the innovation sandwich. The innovation sandwich, last decade, last three decades, has been Moore's law. The innovation sandwich going forward is data, machine intelligence applied to that data, and cloud for scale, and that's the sandwich of innovation over the next 10 to 20 years. >> Yeah, and I think data is everywhere, so this idea of being a categorical industry segment is a little bit off, I mean, although I know data warehouse is kind of its own category and you're seeing that, but I don't think it's like a Magic Quadrant anymore. Every quadrant has data. >> Mm-hm. >> So, I think data's fundamental, and I think that's why it's going to become a layer within a control plane of either cloud or some other system, I think. I think that's pretty clear, there's no, like, one. You can't buy big data, you can't buy AI. I think you can have AI, you know, things like TensorFlow, but it's going to be a completely... Every layer of the stack is going to be impacted by AI and data. >> And I think the big players are going to infuse their applications and their databases with machine intelligence. You're going to see this, you're certainly, you know, seeing it with IBM, the sort of Watson heavy lift. Clearly Google, Amazon, you know, Facebook, Alibaba, and Microsoft, they're infusing AI throughout their entire set of cloud services and applications and infrastructure, and I think that's good news for the practitioners. People aren't... Most companies aren't going to build their own AI, they're going to buy AI, and that's how they close the gap between the sort of data haves and the data have-nots, and again, I want to emphasize that the fundamental difference, to me anyway, is having data at the core. If you look at the top five companies in terms of market value, US companies, Facebook maybe not so much anymore because of the fake news, though Facebook will be back with it's two billion users, but Apple, Google, Facebook, Amazon, who am I... And Microsoft, those five have put data at the core and they're the most valuable companies in the stock market from a market cap standpoint, why? Because it's a recognition that that intangible value of the data is actually quite valuable, and even though banks and financial institutions are data companies, their data lives in silos. So, these five have put data at the center, surrounded it with human expertise, as opposed to having humans at the center and having data all over the place. So, how do they, how do these companies close the gap? How do the companies in the flyover states close the gap? The way they close the gap, in my view, is they buy technologies that have AI infused in it, and I think the last thing I'll say is I see cloud as the substrate, and AI, and blockchain and other services, as the automation layer on top of it. I think that's going to be the big tailwind for innovation over the next decade. >> Yeah, and obviously the theme of machine learning drives a lot of the conversations here, and that's essentially never going to go away. Machine learning is the core of AI, and I would argue that AI truly doesn't even exist yet. It's machine learning really driving the value, but to put a validation on the fact that cloud is going to be driving AI business is some of the terms in popular conversations we're hearing here in New York around this event and topic, CUBENYC and Strata Conference, is you're hearing Kubernetes and blockchain, and you know, these automation, AI operation kind of conversations. That's an IT conversation, (chuckles) so you know, that's interesting. You've got IT, really, with storage. You've got to store the data, so you can't not talk about workloads and how the data moves with workloads, so you're starting to see data and workloads kind of be tossed in the same conversation, that's a cloud conversation. That is all about multi-cloud. That's why you're seeing Kubernetes, a term I never thought I would be saying at a big data show, but Kubernetes is going to be key for moving workloads around, of which there's data involved. (chuckles) Instrumenting the workloads, data inside the workloads, data driving data. This is where AI and machine learning's going to play, so again, cloud subsumes AI, that's the story, and I think that's going to be the big trend. >> Well, and I think you're right, now. I mean, that's why you're hearing the messaging of hybrid cloud and from the big distro vendors, and the other thing is you're hearing from a lot of the no-SQL database guys, they're bringing ACID compliance, they're bringing enterprise-grade capability, so you're seeing the world is hybrid. You're seeing those two worlds come together, so... >> Their worlds, it's getting leveled in the playing field out there. It's all about enterprise, B2B, AI, cloud, and data. That's theCUBE bringing you the data here. New York City, CUBENYC, that's the hashtag. Stay with us for more coverage live in New York after this short break. (techy music)