(bright upbeat music) >> Hey, guys. Welcome back to Detroit, Michigan. Lisa Martin and John Furrier here live with "theCUBE" at KubeCon CloudNativeCon, North America. John, it's been a great day. This is day one of our coverage of three days of coverage. Kubernetes is growing up. It's maturing. >> Yeah, we got three days of wall-to-wall coverage, all about Kubernetes. We heard about Security, Large scale, Cloud native at scale. That's the big focus. This next segment's going to be really awesome. You have a fast growing private company and a practitioner, big name, blue chip practitioner, building out next-gen cloud. First transforming, then building out the next level. This is classic, what we call Super Cloud-Like interview. It's going to be great. I'm looking forward to this. >> Anytime we can talk about Super Cloud, right? Please welcome back, one of our alumni, Haseeb Budhani is here, the CEO of Rafay. Great to see you. Santhosh Pasula, also joins us, the global head of Cloud SRE at Mass Mutual. Guys, great to have you on the program. >> Thanks for having us. >> Thank you for having me. >> So, Haseeb, you've been on "theCUBE" many times. You were on just recently, with the momentum that's around us today with the maturation of Kubernetes, the collaboration of the community, the recognition of the community. What are some of the things that you're excited about with on day one of the show? >> Wow, so many new companies. I mean, there are companies that I don't know who are here. And I live in this industry, and I'm seeing companies that I don't know, which is a good thing. It means that the community's growing. But at the same time, I'm also seeing another thing, which is, I have met more enterprise representatives at this show than other KubeCons. Like when we hung out at in Valencia, for example, or even other places, it hasn't been this many people. Which means, and this is a good thing that enterprises are now taking Kubernetes seriously. It's not a toy. It's not just for developers. It's enterprises who are now investing in Kubernetes as a foundational component for their applications going forward. And that to me is very, very good. >> Definitely, becoming foundational. >> Haseeb: Yeah. >> Well, you guys got a great traction. We had many interviews at "theCUBE," and you got a practitioner here with you guys, are both pioneering, kind of what I call the next-gen cloud. First you got to get through Gen-One, which you guys done at Mass Mutual extremely well. Take us through the story of your transformation? 'Cause you're on at the front end now of that next inflection point. But take us through how you got here? You had a lot of transformation success at Mass Mutual? >> So, I was actually talking about this topic few minutes back. And the whole cloud journey in big companies, large financial institutions, healthcare industry or insurance sector, it takes generations of leadership to get to that perfection level. And ideally, the cloud for strategy starts in, and then how do you standardize and optimize cloud, right? That's the second-gen altogether, and then operationalization of the cloud. And especially if you're talking about Kubernetes, in the traditional world, almost every company is running middleware and their applications in middleware. And their containerization is a topic that came in. And Docker is basically the runtime containerization. So, that came in first, and from Docker, eventually when companies started adopting Docker, Docker Swarm is one of the technologies that they adopted. And eventually, when we were taking it to a more complicated application implementations or modernization efforts, that's when Kubernetes played a key role. And as Haseeb was pointing out, you never saw so many companies working on Kubernetes. So, that should tell you one story, right? How fast Kubernetes is growing, and how important it is for your cloud strategy. >> And your success now, and what are you thinking about now? What's on your agenda now? As you look forward, what's on your plate? What are you guys doing right now? >> So we are past the stage of proof of concepts, proof of technologies, pilot implementations. We are actually playing it, the real game now. In the past, I used the quote, like "Hello world to real world." So, we are actually playing in the real world, not in the hello world anymore. Now, this is where the real time challenges will pop up. So, if you're talking about standardizing it, and then optimizing the cloud, and how do you put your governance structure in place? How do you make sure your regulations are met? The demands that come out of regulations are met? And how are you going to scale it? And while scaling, how are you going to keep up with all the governance and regulations that come with it? So we are in that stage today. >> Haseeb talked about, you talked about the great evolution of what's going on at Mass Mutual. Haseeb talk a little bit about who? You mentioned one of the things that's surprising you about this KubeCon in Detroit, is that you're seeing a lot more enterprise folks here? Who's deciding in the organization and your customer conversations? Who are the decision makers in terms of adoption of Kubernetes these days? Is that elevating? >> Hmm. Well, this guy. (Lisa laughing) One of the things I'm seeing here, and John and I have talked about this in the past, this idea of a platform organization and enterprises. So, consistently what I'm seeing, is somebody, a CTO, CIO level, an individual is making a decision. I have multiple internal Bus who are now modernizing applications. They're individually investing in DevOps, and this is not a good investment for my business. I'm going to centralize some of this capability so that we can all benefit together. And that team is essentially a platform organization. And they're making Kubernetes a shared services platform so that everybody else can come and sort of consume it. So, what that means to us, is our customer is a platform organization, and their customer is a developer. So we have to make two constituencies successful. Our customer who's providing a multi-tenant platform, and then their customer, who's your developer, both have to be happy. If you don't solve for both, you know, constituencies, you're not going to be successful. >> So, you're targeting the builder of the infrastructure and the consumer of that infrastructure? >> Yes, sir. It has to be both. >> On the other side? >> Exactly, right. So that look, honestly, it takes iteration to figure these things out. But this is a consistent theme that I am seeing. In fact, what I would argue now, is that every enterprise should be really stepping back and thinking about what is my platform strategy? Because if you don't have a platform strategy, you're going to have a bunch of different teams who are doing different things, and some will be successful, and look, some will not be. And that is not good for business. >> Yeah, and Santhosh, I want to get to you. You mentioned your transformations, what you look forward, and your title, Global Head of Cloud, SRE. Okay, so SRE, we all know came from Google, right? Everyone wants to be like Google, but no one wants to be like Google, right? And no one is Google. Google's a unique thing. >> Haseeb: Only one Google. >> But they had the dynamic and the power dynamic of one person to large scale set of servers or infrastructure. But concept can be portable, but the situation isn't. So, Borg became Kubernetes, that's inside baseball. So, you're doing essentially what Google did at their scale, you're doing for Mass Mutual. That's kind of what's happening, is that kind of how I see it? And you guys are playing in there partnering? >> So, I totally agree. Google introduce SRE, Site Reliability Engineering. And if you take the traditional transformation of the roles, in the past, it was called operations, and then DevOps ops came in, and then SRE is the new buzzword. And the future could be something like Product Engineering. And in this journey, here is what I tell folks on my side, like what worked for Google might not work for a financial company. It might not work for an insurance company. It's okay to use the word, SRE, but end of the day, that SRE has to be tailored down to your requirements. And the customers that you serve, and the technology that you serve. >> This is why I'm coming back, this platform engineering. At the end of the day, I think SRE just translates to, you're going to have a platform engineering team? 'Cause you got to enable developers to be producing more code faster, better, cheaper, guardrails, policies. It's kind of becoming the, these serve the business, which is now the developers. IT used to serve the business back in the old days, "Hey, the IT serves the business." >> Yup. >> Which is a term now. >> Which is actually true now. >> The new IT serves the developers, which is the business. >> Which is the business. >> Because if digital transformation goes to completion, the company is the app. >> The hard line between development and operations, so that's thinning down. Over the time, that line might disappear. And that's where SRE is fitting in. >> Yeah, and then building platform to scale the enablement up. So, what is the key challenges? You guys are both building out together this new transformational direction. What's new and what's the same? The same is probably the business results, but what's the new dynamic involved in rolling it out and making people successful? You got the two constituents, the builders of the infrastructures and the consumers of the services on the other side. What's the new thing? >> So, the new thing, if I may go first. The faster market to value that we are bringing to the table, that's very important. Business has an idea. How do you get that idea implemented in terms of technology and take it into real time? So, that journey we have cut down. Technology is like Kubernetes. It makes an IT person's life so easy that they can speed up the process. In a traditional way, what used to take like an year, or six months, can be done in a month today, or less than that. So, there's definitely speed velocity, agility in general, and then flexibility. And then the automation that we put in, especially if you have to maintain like thousands of clusters. These are today, it is possible to make that happen with a click off a button. In the past, it used to take, probably, 100-person team, and operational team to do it, and a lot of time. But that automation is happening. And we can get into the technology as much as possible, but blueprinting and all that stuff made it possible. >> We'll save that for another interview. We'll do it deep time. (panel laughing) >> But the end user on the other end, the consumer doesn't have the patience that they once had, right? It's, "I want this in my lab now." How does the culture of Mass Mutual? How is it evolve to be able to deliver the velocity that your customers are demanding? >> Once in a while, it's important to step yourself into the customer's shoes and think it from their perspective. Business does not care how you're running your IT shop. What they care about is your stability of the product and the efficiencies of the product, and how easy it is to reach out to the customers. And how well we are serving the customers, right? So, whether I'm implementing Docker in the background, Docker Swam or Kubernetes, business doesn't even care about it. What they really care about, it is, if your environment goes down, it's a problem. And if your environment or if your solution is not as efficient as the business needs, that's the problem, right? So, at that point, the business will step in. So, our job is to make sure, from a technology perspective, how fast you can make implement it? And how efficiently you can implement it? And at the same time, how do you play within the guardrails of security and compliance? >> So, I was going to ask you, if you have VMware in your environment? 'Cause a lot of clients compare what vCenter does for Kubernetes is really needed. And I think that's what you guys got going on. I can say that, you're the vCenter of Kubernetes. I mean, as as metaphor, a place to manage it all, is all one paint of glass, so to speak. Is that how you see success in your environment? >> So, virtualization has gone a long way. Where we started, what we call bare metal servers, and then we virtualized operating systems. Now, we are virtualizing applications, and we are virtualizing platforms as well, right? So that's where Kubernetes plays a role. >> So, you see the need for a vCenter like thing for Kubernetes? >> There's definitely a need in the market. The way you need to think is like, let's say there is an insurance company who actually implement it today, and they gain the market advantage. Now, the the competition wants to do it as well, right? So, there's definitely a virtualization of application layer that's very critical, and it's a critical component of cloud strategy as a whole. >> See, you're too humble to say it. I'll say, you're like the vCenter of Kubernetes. Explain what that means in your term? If I said that to you, what would you react? How would you react to that? Would you say, BS, or would you say on point? >> Maybe we should think about what does vCenter do today? So, in my opinion, by the way, vCenter in my opinion, is one of the best platforms ever built. Like it's the best platform in my opinion ever built. VMware did an amazing job, because they took an IT engineer, and they made him now be able to do storage management, networking management, VM's multitenancy, access management, audit. Everything that you need to run a data center, you can do from essentially single platform. >> John: From a utility standpoint, home-run? >> It's amazing. >> Yeah. >> Because you are now able to empower people to do way more. Well, why are we not doing that for Kubernetes? So, the premise man Rafay was, well, I should have IT engineers, same engineers. Now, they should be able to run fleets of clusters. That's what people that Mass Mutual are able to do now. So, to that end, now you need cluster management, you need access management, you need blueprinting, you need policy management. All of these things that have happened before, chargebacks, they used to have it in vCenter, now they need to happen in other platforms but for Kubernetes. So, should we do many of the things that vCenter does? Yes. >> John: Kind of, yeah. >> Are we a vCenter for Kubernetes? >> No. >> That is a John Furrier question. >> All right, well, the speculation really goes back down to the earlier speed question. If you can take away the complexity and not make it more steps, or change a tool chain, or do something, then the Devs move faster. And the service layer that serves the business, the new organization, has to enable speed. This is becoming a real discussion point in the industry, is that, "Yeah, we got new tool. Look at the shiny new toy." But if it move the needle, does it help productivity for developers? And does it actually scale up the enablement? That's the question. So, I'm sure you guys are thinking about this a lot. What's your reaction? >> Yeah, absolutely. And one thing that just hit my mind, is think about the hoteling industry before Airbnb and after Airbnb. Or the taxi industry before Uber and after Uber. So, if I'm providing a platform, a Kubernetes platform for my application folks, or for my application partners, they have everything ready. All they need to do is build their application and deploy it, and run it. They don't have to worry about provisioning of the servers, and then building the Middleware on top of it, and then, do a bunch of testing to make sure they iron out all the compatible issues and whatnot. Now, today, all I say is like, "Hey, we have a platform built for you. You just build your application, and then deploy it in a development environment, that's where you put all the pieces of puzzle together. Make sure you see your application working, and then the next thing that you do is like, do the correction. >> John: Shipping. >> Shipping. You build the production. >> John: Press. Go. Release it. (laughs) That when you move on, but they were there. I mean, we're there now. We're there. So, we need to see the future, because that's the case, then the developers are the business. They have to be coding more features, they have to react to customers. They might see new business opportunities from a revenue standpoint that could be creatively built, got low code, no code, headless systems. These things are happening where there's, I call the Architectural List Environment where it's like, you don't need architecture, it's already happening. >> Yeah, and on top of it, if someone has an idea, they want to implement an idea real quick. So, how do you do it? And you don't have to struggle building an environment to implement your idea and test it in real time. So, from an innovation perspective, agility plays a key role. And that's where the Kubernetes platforms, or platforms like Kubernetes plays. >> You know, Lisa, when we talked to Andy Jassy, when he was the CEO of AWS, either one-on-one or on "theCUBE," he always said, and this is kind of happening, "Companies are going to be builders, where it's not just utility, you need that table stakes to enable that new business idea." And so, in this last keynote, he did this big thing like, "Think like your developers are the next entrepreneurial revenue generators." I think I'm starting to see that. What do you think about that? You see that coming sooner than later? Or is that an insight, or is that still ways away? >> I think it's already happening at a level, at a certain level. Now ,the question comes back to, you know, taking it to the reality. I mean, you can do your proof of concept, proof of technologies, and then prove it out like, "Hey, I got a new idea. This idea is great." And it's to the business advantage. But we really want to see it in production live where your customers are actually using it. >> In the board meetings, "Hey, we got a new idea that came in, generating more revenue, where'd that come from?" Agile Developer. Again, this is real. >> Yeah. >> Yeah. Absolutely agree. Yeah, I think both of you gentlemen said a word as you were talking, you used the word, Guardrails. We're talking about agility, but the really important thing is, look, these are enterprises, right? They have certain expectations. Guardrails is key, right? So, it's automation with the guardrails. Guardrails are like children, you know, shouldn't be heard. They're seen but not heard. Developers don't care about guardrails, they just want to go fast. >> They also bounce around a little bit, (laughs) off the guardrails. >> Haseeb: Yeah. >> One thing we know that's not going to slow down, is the expectations, right? Of all the consumers of this, the Devs, the business, the business top line, and, of course, the customers. So, the ability to really, as your website says, let's say, "Make Life Easy for Platform Teams" is not trivial. And clearly what you guys are talking about here, is you're really an enabler of those platform teams, it sounds like to me. >> Yup. >> So, great work, guys. Thank you so much for both coming on the program, talking about what you're doing together, how you're seeing the evolution of Kubernetes, why? And really, what the focus should be on those platform teams. We appreciate all your time and your insights. >> Thank you so much for having us. >> Thanks for having us. >> Our pleasure. For our guests and for John Furrier, I'm Lisa Martin. You're watching "theCUBE" Live, KubeCon CloudNativeCon from Detroit. We'll be back with our next guest in just a minute, so stick around. (bright upbeat music)

(calm music) >> Hi everybody. We're here at VeeamON 2022. This is day two of the CUBE's continuous coverage. I'm Dave Vellante. My co-host is Dave Nicholson. A ton of energy. The keynotes, day two keynotes are all about products at Veeam. Veeam, the color of green, same color as money. And so, and it flows in this ecosystem. I'll tell you right now, Michael Cade is here. He's the senior technologist for product strategy at Veeam. Michael, fresh off the keynotes. >> Yeah, yeah. >> Welcome. Danny Allen's keynote was fantastic. I mean, that story he told blew me away. I can't wait to have him back. Stay tuned for that one. But we're going to talk about protecting containers, Kasten. You guys got announcements of Kasten by Veeam, you call it K10 version five, I think? >> Yeah. So just rolled into 5.0 release this week. Now, it's a bit different to what we see from a VBR release cycle kind of thing, cause we're constantly working on a two week sprint cycle. So as much as 5.0's been launched and announced, we're going to see that trickling out over the next couple of months until we get round to Cube (indistinct) and we do all of this again, right? >> So let's back up. I first bumped into Kasten, gosh, it was several years ago at VeeamON. Like, wow this is a really interesting company. I had deep conversations with them. They had a sheer, sheer cat grin, like something was going on and okay finally you acquire them, but go back a little bit of history. Like why the need for this? Containers used to be ephemeral. You know, you didn't have to persist them. That changed, but you guys are way ahead of that trend. Talk a little bit more about the history there and then we'll get into current day. >> Yeah, I think the need for stateful workloads within Kubernetes is absolutely grown. I think we just saw 1.24 of Kubernetes get released last week or a couple of weeks ago now. And really the focus there, you can see, at least three of the big ticket items in that release are focused around storage and data. So it just encourages that the community is wanting to put these data services within that. But it's also common, right? It's great to think about a stateless... If you've got stateless application but even a web server's got some state, right? There's always going to be some data associated to an application. And if there isn't then like, great but that doesn't really work- >> You're right. Where'd they click, where'd they go? I mean little things like that, right? >> Yeah. Yeah, exactly. So one of the things that we are seeing from that is like obviously the requirement to back up and put in a lot of data services in there, and taking full like exposure of the Kubernetes ecosystem, HA, and very tiny containers versus these large like virtual machines that we've always had the story at Veeam around the portability and being able to move them left, right, here, there, and everywhere. But from a K10 point of view, the ability to not only protect them, but also move those applications or move that data wherever they need to be. >> Okay. So, and Kubernetes of course has evolved. I mean the early days of Kubernetes, they kept it simple, kind of like Veeam actually. Right? >> Yeah. >> And then, you know, even though Mesosphere and even Docker Swarm, they were trying to do more sophisticated cluster management. Kubernetes has now got projects getting much more complicated. So more complicated workloads mean more data, more critical data means more protection. Okay, so you acquire Kasten, we know that's a small part of your business today but it's going to be growing. We know this cause everybody's developing applications. So what's different about protecting containers? Danny talks about modern data protection. Okay, when I first heard that, I'm like, eh, nice tagline, but then he peel the onion. He explains how in virtualization, you went from agents to backing up of VMware instance, a virtual instance. What's different about containers? What constitutes modern data protection for containers? >> Yeah, so I think the story that Danny tells as well, is so when we had our physical agents and virtualization came along and a lot of... And this is really where Veeam was born, right, we went into the virtualization API, the VMware API, and we started leveraging that to be more storage efficient. The admin overhead around those agents weren't there then, we could just back up using the API. Whereas obviously a lot of our competition would use agents still and put that resource overhead on top of that. So that's where Veeam initially got the kickstart in that world. I think it's very similar to when it comes to Kubernetes because K10 is deployed within the Kubernetes cluster and it leverages the Kubernetes API to pull out that data in a more efficient way. You could use image based backups or traditional NAS based backups to protect some of the data, and backup's kind of the... It's only one of the ticks in the boxes, right? You have to be able to restore and know what that data is. >> But wait, your competitors aren't as fat, dumb and happy today as they were back then, right? So it can't... They use the same APIs and- >> Yeah. >> So what makes you guys different? >> So I think that's testament to the Kubernetes and the community behind that and things like the CSI driver, which enables the storage vendors to take that CSI abstraction layer and then integrate their storage components, their snapshot technologies, and other efficiency models in there, and be able to leverage that as part of a universal data protection API. So really that's one tick in the box and you're absolutely right, there's open source tools that can do exactly what we're doing to a degree on that backup and recovery. Where it gets really interesting is the mobility of data and how we're protecting that. Because as much as stateful workloads are seen within the Kubernetes environments now, they're also seen outside. So things like Amazon RDS, but the front end lives in Kubernetes going to that stateless point. But being able to protect the whole application and being very application aware means that we can capture everything and restore wherever we want that to go as well. Like, so the demo that I just did was actually a Postgres database in AWS, and us being able to clone or migrate that out into an EKS cluster as a staple set. So again, we're not leveraging RDS at that point, but it gives us the freedom of movement of that data. >> Yeah, I want to talk about that, what you actually demoed. One of the interesting things, we were talking earlier, I didn't see any CLI when you were going through the integration of K10 V5 and V12. >> Yeah. >> That was very interesting, but I'm more skeptical of this concept, of the single pane of glass and how useful that is. Who is this integration targeting? Are you targeting the sort of traditional Veeam user who is now adding as a responsibility, the management of protecting these Kubernetes environments? Or are you at the same time targeting the current owners of those environments? Cause I know you talk about shift left and- >> Yeah. >> You know, nobody needs Kubernetes if you only have one container and one thing you're doing. So at some point it's all about automation, it's about blueprints, it's about getting those things in early. So you get up, you talk about this integration, who cares about that kind of integration? >> Yeah, so I think it's a bit of both, right? So we're definitely focused around the DevOps focused engineer. Let's just call it that. And under an umbrella, the cloud engineer that's looking after Kubernetes, from an application delivery perspective. But I think more and more as we get further up the mountain, CIS admin, obviously who we speak to the tech decision makers, the solutions architects systems engineers, they're going to inherit and be that platform operator around the Kubernetes clusters. And they're probably going to land with the requirement around data management as well. So the specific VBR centralized management is very much for the backup admin, the infrastructure admin or the cloud based engineer that's looking after the Kubernetes cluster and the data within that. Still we speak to app developers who are conscious of what their database looks like, because that's an external data service. And the biggest question that we have or the biggest conversation we have with them is that the source code, the GitHub or the source repository, that's fine, that will get your... That'll get some of the way back up and running, but when it comes to a Postgres database or some sort of data service, oh, that's out of the CI/CD pipeline. So it's whether they're interested in that or whether that gets farmed out into another pre-operations, the traditional operations team. >> So I want to unpack your press release a little bit. It's full of all the acronyms, so maybe you can help us- >> Sure. >> Cipher. You got security everywhere enhance platform hardening, including KMS. That's key- >> Yeah, key management service, yeah. >> System, okay. With AWS, KMS and HashiCorp vault. Awesome, love to see HashiCorp company. >> Yeah. >> RBAC objects in UI dashboards, ransomware attacks, AWS S3. So anyway, security everywhere. What do you mean by that? >> So I think traditionally at Veeam, and continue that, right? From a security perspective, if you think about the failure scenario and ransomware's, the hot topic, right, when it comes to security, but we can think about security as, if we think about that as the bang, right, the bang is something bad's happen, fire, flood, blood, type stuff. And we tend to be that right hand side of that, we tend to be the remediation. We're definitely the one, the last line of defense to get stuff back when something really bad happens. And I think what we've done from a K10 point of view, is not only enhance that, so with the likes of being able to... We're not going to reinvent the wheel, let's use the services that HashiCorp have done from a HashiCorp vault point of view and integrate from a key management system. But then also things like S3 or ransomware prevention. So I want to know if something bad's happened and Kasten actually did something more generic from a Veeam ONE perspective, but one of the pieces that we've seen since we've then started to send our backups to an immutable object storage, is let's be more of that left as well and start looking at the preventative tasks that we can help with. Now, we're not going to be a security company, but you heard all the way through Danny's like keynote, and probably when he is been on here, is that it's always, we're always mindful of that security focus. >> On that point, what was being looked for? A spike in CPU utilization that would be associated with encryption? >> Yeah, exactly that. >> Is that what was being looked- >> That could be... Yeah, exactly that. So that could be from a virtual machine point of view but from a K10, and it specifically is that we're going to look at the S3 bucket or the object storage, we're going to see if there's a rate of change that's out of the normal. It's an abnormal rate. And then with that, we can say, okay, that doesn't look right, alert us through observability tools, again, around the cloud native ecosystem, Prometheus Grafana. And then we're going to get insight into that before the bang happens, hopefully before the bang. >> So that's an interesting when we talk about adjacencies and moving into this area of security- >> We're talking to Zeus about that too. >> Exactly. That's that sort of creep where you can actually add value. It's interesting. >> So, okay. So we talked about shift left, get that, and then expanded ecosystem, industry leading technologies. By the way, one of them is the Red Hat Marketplace. And I think, I heard Anton's... Anton was amazing. He is the head of product management at Veeam. Is been to every VeeamON. He's got family in Ukraine. He's based in Switzerland. >> Yeah. >> But he chose not to come here because he's obviously supporting, you know, the carnage that's going on in Ukraine. But anyway, I think he said the Red Hat team is actually in Ukraine developing, you know, while the bombs are dropping. That's amazing. But anyway, back to our interview here, expanded ecosystem, Red Hat, SUSE with Rancher, they've got some momentum. vSphere with Tanzu, they're in the game. Talk about that ecosystem and its importance. >> Yeah, and I think, and it goes back to your point around the CLI, right? Is that it feels like the next stage of Kubernetes is going to be very much focused towards the operator or the operations team. The CIS admin of today is going to have to look after that. And at the moment it's all very command line, it's all CLI driven. And I think the marketplace is OpenShift, being our biggest foothold around our customer base, is definitely around OpenShift. But things like, obviously we are a longstanding alliance partner with VMware as well. So their Tanzu operations actually there's support for TKGS, so vSphere Tanzu grid services is another part of the big release of 5.0. But all three of those and the common marketplace gives us a UI, gives us a way of being able to see and visualize that rather than having to go and hunt down the commands and get our information through some- >> Oh, some people are going to be unhappy about that. >> Yeah. >> But I contend the human eye has evolved to see in color for a very good reason. So I want to see things in red, yellow, and green at times. >> There you go, yeah. >> So when we hear a company like Veeam talk about, look we have no platform agenda, we don't care which cloud it's in. We don't care if it's on-prem or Google Azure, AWS. We had Wasabi on, we have... Great, they got an S3 compatible, you know, target, and others as well. When we hear them, companies like you, talk about that consistent experience, single pane of glass that you're skeptical of, maybe cause it's technically challenging, one of the things, we call it super cloud, right, that's come up. Danny and I were riffing on that the other day and we'll do that more this afternoon. But it brings up something that we were talking about with Zeus, Dave, which is the edge, right? And it seems like Kubernetes, and we think about OpenShift. >> Yeah. >> We were there last week at Red Hat Summit. It's like 50% of the conversation, if not more, was the edge. Right, and really true edge, worst cases, use cases. Two weeks ago we were at Dell Tech, there was a lot of edge talk, but it was retail stores, like Lowe's. Okay, that's kind of near edge, but the far edge, we're talking space, right? So seems like Kubernetes fits there and OpenShift, you know, particularly, as well as some of the others that we mentioned. What about edge? How much of what you're doing with container data protection do you see as informing you about the edge opportunity? Are you seeing any patterns there? Nobody's really talking about it in data protection yet. >> So yeah, large scale numbers of these very small clusters that are out there on farms or in wind turbines, and that is definitely something that is being spoken about. There's not much mention actually in this 5.0 release because we actually support things like K3s,(indistinct), that all came in 4.5, but I think, to your first point as well, David, is that, look, we don't really care what that Kubernetes distribution is. So you've got K3s lightweight Kubernetes distribution, we support it, because it uses the same native Kubernetes APIs, and we get deployed inside of that. I think where we've got these large scale and large numbers of edge deployments of Kubernetes and that you require potentially some data management down there, and they might want to send everything into a centralized location or a more centralized location than a farm shed out in the country. I think we're going to see a big number of that. But then we also have our multi cluster dashboard that gives us the ability to centralize all of the control plane. So we don't have to go into each individual K10 deployment to manage those policies. We can have one big centralized management multi cluster dashboard, and we can set global policies there. So if you're running a database and maybe it's the same one across all of your different edge locations, where you could just set one policy to say I want to protect that data on an hourly basis, a daily basis, whatever that needs to be, rather than having to go into each individual one. >> And then send it back to that central repository. So that's the model that you see, you don't see the opportunity, at least at this point in time, of actually persisting it at the edge? >> So I think it depends. I think we see both, but again, that's the footprint. And maybe like you mentioned about up in space having a Kubernetes cluster up there. You don't really want to be sending up a NAS device or a storage device, right, to have to sit alongside it. So it's probably, but then equally, what's the art of the possible to get that back down to our planet, like as part of a consistent copy of data? >> Or even a farm or other remote locations. The question is, I mean, EVs, you know, we believe there's going to be tons of data, we just don't.. You think about Tesla as a use case, they don't persist a ton of their data. Maybe if a deer runs across, you know, the front of the car, oh, persist that, send that back to the cloud. >> I don't want anyone knowing my Tesla data. I'll tell you that right now. (all laughing) >> Well, there you go, that one too. All right, well, that's future discussion, we're still trying to squint through those patterns. I got so many questions for you, Michael, but we got to go. Thanks so much for coming to theCUBE. >> Always. >> Great job on the keynote today and good luck. >> Thank you. Thanks for having me. >> All right, keep it right there. We got a ton of product talk today. As I said, Danny Allan's coming back, we got the ecosystem coming, a bunch of the cloud providers. We have, well, iland was up on stage. They were just recently acquired by 11:11 Systems. They were an example today of a cloud service provider. We're going to unpack it all here on theCUBE at VeeamON 2022 from Las Vegas at the Aria. Keep it right there. (calm music)

>>Hi everybody. This is Dave Volante. Welcome to this cube conversation where we're going to go back in time a little bit and explore the early days of Kubernetes. Talk about how it formed the improbable events, perhaps that led to it. And maybe how customers are taking advantage of containers and container orchestration today, and maybe where the industry is going. Matt Provo is here. He's the founder and CEO of storm forge and Chandler Huntington hoes. Hoisington is the general manager of EKS edge and hybrid AWS guys. Thanks for coming on. Good to see you. Thanks for having me. Thanks. So, Jenny, you were the vice president of engineering at miso sphere. Is that, is that correct? >>Well, uh, vice-president engineering basis, fear and then I ran product and engineering for DTQ masons. >>Yeah. Okay. Okay. So you were there in the early days of, of container orchestration and Matt, you, you were working at a S a S a Docker swarm shop, right? Yep. Okay. So I mean, a lot of people were, you know, using your platform was pretty novel at the time. Uh, it was, it was more sophisticated than what was happening with, with Kubernetes. Take us back. What was it like then? Did you guys, I mean, everybody was coming out. I remember there was, I think there was one Docker con and everybody was coming, the Kubernetes was announced, and then you guys were there, doc Docker swarm was, was announced and there were probably three or four other startups doing kind of container orchestration. And what, what were those days like? Yeah. >>Yeah. I wasn't actually atmosphere for those days, but I know them well, I know the story as well. Um, uh, I came right as we started to pivot towards Kubernetes there, but, um, it's a really interesting story. I mean, obviously they did a documentary on it and, uh, you know, people can watch that. It's pretty good. But, um, I think that, from my perspective, it was, it was really interesting how this happened. You had basically, uh, con you had this advent of containers coming out, right? So, so there's new novel technology and Solomon, and these folks started saying, Hey, you know, wait a second, wait if I put a UX around these couple of Linux features that got launched a couple of years ago, what does that look like? Oh, this is pretty cool. Um, so you have containers starting to crop up. And at the same time you had folks like ThoughtWorks and other kind of thought leaders in the space, uh, starting to talk about microservices and saying, Hey, monoliths are bad and you should break up these monoliths into smaller pieces. >>And any Greenfield application should be broken up into individuals, scalable units that a team can can own by themselves, and they can scale independent of each other. And you can write tests against them independently of other components. And you should break up these big, big mandalas. And now we are kind of going back to model this, but that's for another day. Um, so, so you had microservices coming out and then you also had containers coming out, same time. So there was like, oh, we need to put these microservices in something perfect. We'll put them in containers. And so at that point, you don't really, before that moment, you didn't really need container orchestration. You could just run a workload in a container and be done with it, right? You didn't need, you don't need Kubernetes to run Docker. Um, but all of a sudden you had tons and tons of containers and you had to manage these in some way. >>And so that's where container orchestration came, came from. And, and Ben Heineman, the founder of Mesa was actually helping schedule spark at the time at Berkeley. Um, and that was one of the first workloads with spark for Macy's. And then his friends at Twitter said, Hey, come over, can you help us do this with containers at Twitter? He said, okay. So when it helped them do it with containers at Twitter, and that's kinda how that branch of the container wars was started. And, um, you know, it was really, really great technology and it actually is still in production in a lot of shops today. Um, uh, more and more people are moving towards Kubernetes and Mesa sphere saw that trend. And at the end of the day, Mesa sphere was less concerned about, even though they named the company Mesa sphere, they were less concerned about helping customers with Mesa specifically. They really want to help customers with these distributed problems. And so it didn't make sense to, to just do Mesa. So they would took on Kubernetes as well. And I hope >>I don't do that. I remember, uh, my, my co-founder John furrier introduced me to Jerry Chen way back when Jerry is his first, uh, uh, VC investment with Greylock was Docker. And we were talking in these very, obviously very excited about it. And, and his Chandler was just saying, it said Solomon and the team simplified, you know, containers, you know, simple and brilliant. All right. So you guys saw the opportunity where you were Docker swarm shop. Why? Because you needed, you know, more sophisticated capabilities. Yeah. But then you, you switched why the switch, what was happening? What was the mindset back then? We ran >>And into some scale challenges in kind of operationalize or, or productizing our kind of our core machine learning. And, you know, we, we, we saw kind of the, the challenges, luckily a bit ahead of our time. And, um, we happen to have someone on the team that was also kind of moonlighting, uh, as one of the, the original core contributors to Kubernetes. And so as this sort of shift was taking place, um, we, we S we saw the flexibility, uh, of what was becoming Kubernetes. Um, and, uh, I'll never forget. I left on a Friday and came back on a Monday and we had lifted and shifted, uh, to Kubernetes. Uh, the challenge was, um, you know, you, at that time, you, you didn't have what you have today through EKS. And, uh, those kinds of services were, um, just getting that first cluster up and running was, was super, super difficult, even in a small environment. >>And so I remember we, you know, we, we finally got it up and running and it was like, nobody touch it, don't do anything. Uh, but obviously that doesn't, that doesn't scale either. And so that's really, you know, being kind of a data science focused shop at storm forge from the very beginning. And that's where our core IP is. Uh, our, our team looked at that problem. And then we looked at, okay, there are a bunch of parameters and ways that I can tune this application. And, uh, why are the configurations set the way that they are? And, you know, uh, is there room to explore? And that's really where, unfortunately, >>Because Mesa said much greater enterprise capabilities as the Docker swarm, at least they were heading in that direction, but you still saw that Kubernetes was, was attractive because even though it didn't have all the security features and enterprise features, because it was just so simple. I remember Jen Goldberg who was at Google at the time saying, no, we were focused on keeping it simple and we're going from mass adoption, but does that kind of what you said? >>Yeah. And we made a bet, honestly. Uh, we saw that the, uh, you know, the growing community was really starting to, you know, we had a little bit of an inside view because we had, we had someone that was very much in the, in the original part, but you also saw the, the tool chain itself start to, uh, start to come into place right. A little bit. And it's still hardening now, but, um, yeah, we, as any, uh, as any startup does, we, we made a pivot and we made a bet and, uh, this, this one paid off >>Well, it's interesting because, you know, we said at the time, I mean, you had, obviously Amazon invented the modern cloud. You know, Microsoft has the advantage of has got this huge software stays, Hey, just now run it into the cloud. Okay, great. So they had their entry point. Google didn't have an entry point. This is kind of a hail Mary against Amazon. And, and I, I wrote a piece, you know, the improbable, Verizon, who Kubernetes to become the O S you know, the cloud, but, but I asked, did it make sense for Google to do that? And it never made any money off of it, but I would argue they, they were kind of, they'd be irrelevant if they didn't have, they hadn't done that yet, but it didn't really hurt. It certainly didn't hurt Amazon EKS. And you do containers and your customers you've embraced it. Right. I mean, I, I don't know what it was like early days. I remember I've have talked to Amazon people about this. It's like, okay, we saw it and then talk to customers, what are they doing? Right. That's kind of what the mindset is, right? Yeah. >>That's, I, I, you know, I've, I've been at Amazon a couple of years now, and you hear the stories of all we're customer obsessed. We listened to our customers like, okay, okay. We have our company values, too. You get told them. And when you're, uh, when you get first hired in the first day, and you never really think about them again, but Amazon, that really is preached every day. It really is. Um, uh, and that we really do listen to our customers. So when customers start asking for communities, we said, okay, when we built it for them. So, I mean, it's, it's really that simple. Um, and, and we also, it's not as simple as just building them a Kubernetes service. Amazon has a big commitment now to start, you know, getting involved more in the community and working with folks like storm forage and, and really listening to customers and what they want. And they want us working with folks like storm florigen and that, and that's why we're doing things like this. So, well, >>It's interesting, because of course, everybody looks at the ecosystem, says, oh, Amazon's going to kill the ecosystem. And then we saw an article the other day in, um, I think it was CRN, did an article, great job by Amazon PR, but talk about snowflake and Amazon's relationship. And I've said many times snowflake probably drives more than any other ISV out there. And so, yeah, maybe the Redshift guys might not love snowflake, but Amazon in general, you know, they're doing great three things. And I remember Andy Jassy said to me, one time, look, we love the ecosystem. We need the ecosystem. They have to innovate too. If they don't, you know, keep pace, you know, they're going to be in trouble. So that's actually a healthy kind of a dynamic, I mean, as an ecosystem partner, how do you, >>Well, I'll go back to one thing without the work that Google did to open source Kubernetes, a storm forge wouldn't exist, but without the effort that AWS and, and EKS in particular, um, provides and opens up for, for developers to, to innovate and to continue, continue kind of operationalizing the shift to Kubernetes, um, you know, we wouldn't have nearly the opportunity that we do to actually listen to them as well, listen to the users and be able to say, w w w what do you want, right. Our entire reason for existence comes from asking users, like, how painful is this process? Uh, like how much confidence do you have in the, you know, out of the box, defaults that ship with your, you know, with your database or whatever it is. And, uh, and, and how much do you love, uh, manually tuning your application? >>And, and, uh, obviously nobody's said, I love that. And so I think as that ecosystem comes together and continues expanding, um, it's just, it opens up a huge opportunity, uh, not only for existing, you know, EKS and, uh, AWS users to continue innovating, but for companies like storm forge, to be able to provide that opportunity for them as well. And, and that's pretty powerful. So I think without a lot of the moves they've made, um, you know, th the door wouldn't be nearly as open for companies like, who are, you know, growing quickly, but are smaller to be able to, you know, to exist. >>Well, and I was saying earlier that, that you've, you're in, I wrote about this, you're going to get better capabilities. You're clearly seeing that cluster management we've talked about better, better automation, security, the whole shift left movement. Um, so obviously there's a lot of momentum right now for Kubernetes. When you think about bare metal servers and storage, and then you had VM virtualization, VMware really, and then containers, and then Kubernetes as another abstraction, I would expect we're not at the end of the road here. Uh, what's next? Is there another abstraction layer that you would think is coming? Yeah, >>I mean, w for awhile, it looked like, and I remember even with our like board members and some of our investors said, well, you know, well, what about serverless? And, you know, what's the next Kubernetes and nothing, we, as much as I love Kubernetes, um, which I do, and we do, um, nothing about what we particularly do. We are purpose built for Kubernetes, but from a core kind of machine learning and problem solving standpoint, um, we could apply this elsewhere, uh, if we went that direction and so time will tell what will be next, then there will be something, uh, you know, that will end up, you know, expanding beyond Kubernetes at some point. Um, but, you know, I think, um, without knowing what that is, you know, our job is to, to, to serve our, you know, to serve our customers and serve our users in the way that they are asking for that. >>Well, serverless obviously is exploding when you look again, and we tucked the ETR survey data, when you look at, at the services within Amazon and other cloud providers, you know, the functions off, off the charts. Uh, so that's kind of an interesting and notable now, of course, you've got Chandler, you've got edge in your title. You've got hybrid in, in your title. So, you know, this notion of the cloud expanding, it's not just a set of remote services, just only in the public cloud. Now it's, it's coming to on premises. You actually got Andy, Jesse, my head space. He said, one time we just look at it. The data centers is another edge location. Right. Okay. That's a way to look at it and then you've got edge. Um, so that cloud is expanding, isn't it? The definition of cloud is, is, is evolving. >>Yeah, that's right. I mean, customers one-on-one run workloads in lots of places. Um, and that's why we have things like, you know, local zones and wavelengths and outposts and EKS anywhere, um, EKS, distro, and obviously probably lots more things to come. And there's, I always think of like, Amazon's Kubernetes strategy on a manageability scale. We're on one far end of the spectrum, you have EKS distro, which is just a collection of the core Kubernetes packages. And you could, you could take those and stand them up yourself in a broom closet, in a, in a retail shop. And then on the other far in the spectrum, you have EKS far gate where you can just give us your container and we'll handle everything for you. Um, and then we kind of tried to solve everything in between for your data center and for the cloud. And so you can, you can really ask Amazon, I want you to manage my control plane. I want you to manage this much of my worker nodes, et cetera. And oh, I actually want help on prem. And so we're just trying to listen to customers and solve their problems where they're asking us to solve them. Cut, >>Go ahead. No, I would just add that in a more vertically focused, uh, kind of orientation for us. Like we, we believe that op you know, optimization capabilities should transcend the location itself. And, and, and so whether that's part public part, private cloud, you know, that's what I love part of what I love about EKS anywhere. Uh, it, you know, you shouldn't, you should still be able to achieve optimal results that connect to your business objectives, uh, wherever those workloads, uh, are, are living >>Well, don't wince. So John and I coined this term called Supercloud and people laugh about it, but it's different. It's, it's, you know, people talk about multi-cloud, but that was just really kind of vendor diversity. Right? I got to running here, I'm running their money anywhere. Uh, but, but individually, and so Supercloud is this concept of this abstraction layer that floats wherever you are, whether it's on prem, across clouds, and you're taking advantage of those native primitives, um, and then hiding that underlying complexity. And that's what, w re-invent the ecosystem was so excited and they didn't call it super cloud. We, we, we called it that, but they're clearly thinking differently about the value that they can add on top of Goldman Sachs. Right. That to me is an example of a Supercloud they're taking their on-prem data and their, their, their software tooling connecting it to AWS. They're running it on AWS, but they're, they're abstracting that complexity. And I think you're going to see a lot, a lot more of that. >>Yeah. So Kubernetes itself, in many cases is being abstracted away. Yeah. There's a disability of a disappearing act for Kubernetes. And I don't mean that in a, you know, in an, a, from an adoption standpoint, but, uh, you know, Kubernetes itself is increasingly being abstracted away, which I think is, is actually super interesting. Yeah. >>Um, communities doesn't really do anything for a company. Like we run Kubernetes, like, how does that help your bottom line? That at the end of the day, like companies don't care that they're running Kubernetes, they're trying to solve a problem, which is the, I need to be able to deploy my applications. I need to be able to scale them easily. I need to be able to update them easily. And those are the things they're trying to solve. So if you can give them some other way to do that, I'm sure you know, that that's what they want. It's not like, uh, you know, uh, a big bank is making more money because they're running Kubernetes. That's not, that's not the current, >>It gets subsumed. It's just become invisible. Right. Exactly. You guys back to the office yet. What's, uh, what's the situation, >>You know, I, I work for my house and I, you know, we go into the office a couple of times a week, so it's, it's, uh, yeah, it's, it's, it's a crazy time. It's a crazy time to be managing and hiring. And, um, you know, it's, it's, it's, it's definitely a challenge, but there's a lot of benefits of working home. I got two young kids, so I get to see them, uh, grow up a little bit more working, working out of my house. So it's >>Nice also. >>So we're in, even as a smaller startup, we're in 26, 27 states, uh, Canada, Germany, we've got a little bit of presence in Japan, so we're very much distributed. Um, we, uh, have not gone back and I'm not sure we will >>Permanently remote potentially. >>Yeah. I mean, w we made a, uh, pretty like for us, the timing of our series B funding, which was where we started hiring a lot, uh, was just before COVID started really picking up. So we, you know, thankfully made a, a pretty good strategic decision to say, we're going to go where the talent is. And yeah, it was harder to find for sure, especially in w we're competing, it's incredibly competitive. Uh, but yeah, we've, it was a good decision for us. Um, we are very about, you know, getting the teams together in person, you know, as often as possible and in the safest way possible, obviously. Um, but you know, it's been a, it's been a pretty interesting, uh, journey for us and something that I'm, I'm not sure I would, I would change to be honest with you. Yeah. >>Well, Frank Slootman, snowflakes HQ to Montana, and then can folks like Michael Dell saying, Hey, same thing as you, wherever they want to work, bring yourself and wherever you are as cool. And do you think that the hybrid mode for your team is kind of the, the, the operating mode for the, for the foreseeable future is a couple of, >>No, I think, I think there's a lot of benefits in both working from the office. I don't think you can deny like the face-to-face interactions. It feels good just doing this interview face to face. Right. And I can see your mouth move. So it's like, there's a lot of benefits to that, um, over a chime call or a zoom call or whatever, you know, that, that also has advantages, right. I mean, you can be more focused at home. And I think some version of hybrid is probably in the industry's future. I don't know what Amazon's exact plans are. That's above my pay grade, but, um, I know that like in general, the industry is definitely moving to some kind of hybrid model. And like Matt said, getting people I'm a big fan at Mesa sphere, we ran a very diverse, like remote workforce. We had a big office in Germany, but we'd get everybody together a couple of times a year for engineering week or, or something like this. And you'd get a hundred people, you know, just dedicated to spending time together at a hotel and, you know, Vegas or Hamburg or wherever. And it's a really good time. And I think that's a good model. >>Yeah. And I think just more ETR data, the current thinking now is that, uh, the hybrid is the number one sort of model, uh, 36% that the CIO is believe 36% of the workforce are going to be hybrid permanently is kind of their, their call a couple of days in a couple of days out. Um, and the, the percentage that is remote is significantly higher. It probably, you know, high twenties, whereas historically it's probably 15%. Yeah. So permanent changes. And that, that changes the infrastructure. You need to support it, the security models and everything, you know, how you communicate. So >>When COVID, you know, really started hitting and in 2020, um, the big banks for example, had to, I mean, you would want to talk about innovation and ability to, to shift quickly. Two of the bigger banks that have in, uh, in fact, adopted Kubernetes, uh, were able to shift pretty quickly, you know, systems and things that were, you know, historically, you know, it was in the office all the time. And some of that's obviously shifted back to a certain degree, but that ability, it was pretty remarkable actually to see that, uh, take place for some of the larger banks and others that are operating in super regulated environments. I mean, we saw that in government agencies and stuff as well. >>Well, without the cloud, no, this never would've happened. Yeah. >>And I think it's funny. I remember some of the more old school manager thing people are, aren't gonna work less when they're working from home, they're gonna be distracted. I think you're seeing the opposite where people are too much, they get burned out because you're just running your computer all day. And so I think that we're learning, I think everyone, the whole industry is learning. Like, what does it mean to work from home really? And, uh, it's, it's a fascinating thing is as a case study, we're all a part of right now. >>I was talking to my wife last night about this, and she's very thoughtful. And she w when she was in the workforce, she was at a PR firm and a guy came in a guest speaker and it might even be in the CEO of the company asking, you know, what, on average, what time who stays at the office until, you know, who leaves by five o'clock, you know, a few hands up, or who stays until like eight o'clock, you know, and enhancement. And then, so he, and he asked those people, like, why, why can't you get your work done in a, in an eight hour Workday? I go home. Why don't you go in? And I sit there. Well, that's interesting, you know, cause he's always looking at me like, why can't you do, you know, get it done? And I'm saying the world has changed. Yeah. It really has where people are just on all the time. I'm not sure it's sustainable, quite frankly. I mean, I think that we have to, you know, as organizations think about, and I see companies doing it, you guys probably do as well, you know, take a four day, you know, a week weekend, um, just for your head. Um, but it's, there's no playbook. >>Yeah. Like I said, we're a part of a case study. It's also hard because people are distributed now. So you have your meetings on the east coast, you can wake up at seven four, and then you have meetings on the west coast. You stay until seven o'clock therefore, so your day just stretches out. So you've got to manage this. And I think we're, I think we'll figure it out. I mean, we're good at figuring this stuff. >>There's a rise in asynchronous communication. So with things like slack and other tools, as, as helpful as they are in many cases, it's a, it, isn't always on mentality. And like, people look for that little green dot and you know, if you're on the you're online. So my kids, uh, you know, we have a term now for me, cause my office at home is upstairs and I'll come down. And if it's, if it's during the day, they'll say, oh dad, you're going for a walk and talk, you know, which is like, it was my way of getting away from the desk, getting away from zoom. And like, you know, even in Boston, uh, you know, getting outside, trying to at least, you know, get a little exercise or walk and get, you know, get my head away from the computer screen. Um, but even then it's often like, oh, I'll get a slack notification on my phone or someone will call me even if it's not a scheduled walk and talk. Um, uh, and so it is an interesting, >>A lot of ways to get in touch or productivity is presumably going to go through the roof. But now, all right, guys, I'll let you go. Thanks so much for coming to the cube. Really appreciate it. And thank you for watching this cube conversation. This is Dave Alante and we'll see you next time.

>> From theCUBE studios in Palo Alto, in Boston, bringing you data driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vollante. >> The rise of Kubernetes came about through a combination of forces that were, in hindsight, quite a long shot. Amazon's dominance created momentum for Cloud native application development, and the need for newer and simpler experiences, beyond just easily spinning up computer as a service. This wave crashed into innovations from a startup named Docker, and a reluctant competitor in Google, that needed a way to change the game on Amazon and the Cloud. Now, add in the effort of Red Hat, which needed a new path beyond Enterprise Linux, and oh, by the way, it was just about to commit to a path of a Kubernetes alternative for OpenShift and figure out a governance structure to hurt all the cats and the ecosystem and you get the remarkable ascendancy of Kubernetes. Hello and welcome to this week's Wikibon CUBE Insights powered by ETR. In this breaking analysis, we tapped the back stories of a new documentary that explains the improbable events that led to the creation of Kubernetes. We'll share some new survey data from ETR and commentary from the many early the innovators who came on theCUBE during the exciting period since the founding of Docker in 2013, which marked a new era in computing, because we're talking about Kubernetes and developers today, the hoodie is on. And there's a new two part documentary that I just referenced, it's out and it was produced by Honeypot on Kubernetes, part one and part two, tells a story of how Kubernetes came to prominence and many of the players that made it happen. Now, a lot of these players, including Tim Hawkin Kelsey Hightower, Craig McLuckie, Joe Beda, Brian Grant Solomon Hykes, Jerry Chen and others came on theCUBE during formative years of containers going mainstream and the rise of Kubernetes. John Furrier and Stu Miniman were at the many shows we covered back then and they unpacked what was happening at the time. We'll share the commentary from the guests that they interviewed and try to add some context. Now let's start with the concept of developer defined structure, DDI. Jerry Chen was at VMware and he could see the trends that were evolving. He left VMware to become a venture capitalist at Greylock. Docker was his first investment. And he saw the future this way. >> What happens is when you define infrastructure software you can program it. You make it portable. And that the beauty of this cloud wave what I call DDI's. Now, to your point is every piece of infrastructure from storage, networking, to compute has an API, right? And, and AWS there was an early trend where S3, EBS, EC2 had API. >> As building blocks too. >> As building blocks, exactly. >> Not monolithic. >> Monolithic building blocks every little building bone block has it own API and just like Docker really is the API for this unit of the cloud enables developers to define how they want to build their applications, how to network them know as Wills talked about, and how you want to secure them and how you want to store them. And so the beauty of this generation is now developers are determining how apps are built, not just at the, you know, end user, you know, iPhone app layer the data layer, the storage layer, the networking layer. So every single level is being disrupted by this concept of a DDI and where, how you build use and actually purchase IT has changed. And you're seeing the incumbent vendors like Oracle, VMware Microsoft try to react but you're seeing a whole new generation startup. >> Now what Jerry was explaining is that this new abstraction layer that was being built here's some ETR data that quantifies that and shows where we are today. The chart shows net score or spending momentum on the vertical axis and market share which represents the pervasiveness in the survey set. So as Jerry and the innovators who created Docker saw the cloud was becoming prominent and you can see it still has spending velocity that's elevated above that 40% red line which is kind of a magic mark of momentum. And of course, it's very prominent on the X axis as well. And you see the low level infrastructure virtualization and that even floats above servers and storage and networking right. Back in 2013 the conversation with VMware. And by the way, I remember having this conversation deeply at the time with Chad Sakac was we're going to make this low level infrastructure invisible, and we intend to make virtualization invisible, IE simplified. And so, you see above the two arrows there related to containers, container orchestration and container platforms, which are abstraction layers and services above the underlying VMs and hardware. And you can see the momentum that they have right there with the cloud and AI and RPA. So you had these forces that Jerry described that were taking shape, and this picture kind of summarizes how they came together to form Kubernetes. And the upper left, Of course you see AWS and we inserted a picture from a post we did, right after the first reinvent in 2012, it was obvious to us at the time that the cloud gorilla was AWS and had all this momentum. Now, Solomon Hykes, the founder of Docker, you see there in the upper right. He saw the need to simplify the packaging of applications for cloud developers. Here's how he described it. Back in 2014 in theCUBE with John Furrier >> Container is a unit of deployment, right? It's the format in which you package your application all the files, all the executables libraries all the dependencies in one thing that you can move to any server and deploy in a repeatable way. So it's similar to how you would run an iOS app on an iPhone, for example. >> A Docker at the time was a 30% company and it just changed its name from .cloud. And back to the diagram you have Google with a red question mark. So why would you need more than what Docker had created. Craig McLuckie, who was a product manager at Google back then explains the need for yet another abstraction. >> We created the strong separation between infrastructure operations and application operations. And so, Docker has created a portable framework to take it, basically a binary and run it anywhere which is an amazing capability, but that's not enough. You also need to be able to manage that with a framework that can run anywhere. And so, the union of Docker and Kubernetes provides this framework where you're completely abstracted from the underlying infrastructure. You could use VMware, you could use Red Hat open stack deployment. You could run on another major cloud provider like rec. >> Now Google had this huge cloud infrastructure but no commercial cloud business compete with AWS. At least not one that was taken seriously at the time. So it needed a way to change the game. And it had this thing called Google Borg, which is a container management system and scheduler and Google looked at what was happening with virtualization and said, you know, we obviously could do better Joe Beda, who was with Google at the time explains their mindset going back to the beginning. >> Craig and I started up Google compute engine VM as a service. And the odd thing to recognize is that, nobody who had been in Google for a long time thought that there was anything to this VM stuff, right? Cause Google had been on containers for so long. That was their mindset board was the way that stuff was actually deployed. So, you know, my boss at the time, who's now at Cloudera booted up a VM for the first time, and anybody in the outside world be like, Hey, that's really cool. And his response was like, well now what? Right. You're sitting at a prompt. Like that's not super interesting. How do I run my app? Right. Which is, that's what everybody's been struggling with, with cloud is not how do I get a VM up? How do I actually run my code? >> Okay. So Google never really did virtualization. They were looking at the market and said, okay what can we do to make Google relevant in cloud. Here's Eric Brewer from Google. Talking on theCUBE about Google's thought process at the time. >> One interest things about Google is it essentially makes no use of virtual machines internally. And that's because Google started in 1998 which is the same year that VMware started was kind of brought the modern virtual machine to bear. And so Google infrastructure tends to be built really on kind of classic Unix processes and communication. And so scaling that up, you get a system that works a lot with just processes and containers. So kind of when I saw containers come along with Docker, we said, well, that's a good model for us. And we can take what we know internally which was called Borg a big scheduler. And we can turn that into Kubernetes and we'll open source it. And suddenly we have kind of a cloud version of Google that works the way we would like it to work. >> Now, Eric Brewer gave us the bumper sticker version of the story there. What he reveals in the documentary that I referenced earlier is that initially Google was like, why would we open source our secret sauce to help competitors? So folks like Tim Hockin and Brian Grant who were on the original Kubernetes team, went to management and pressed hard to convince them to bless open sourcing Kubernetes. Here's Hockin's explanation. >> When Docker landed, we saw the community building and building and building. I mean, that was a snowball of its own, right? And as it caught on we realized we know what this is going to we know once you embrace the Docker mindset that you very quickly need something to manage all of your Docker nodes, once you get beyond two or three of them, and we know how to build that, right? We got a ton of experience here. Like we went to our leadership and said, you know, please this is going to happen with us or without us. And I think it, the world would be better if we helped. >> So the open source strategy became more compelling as they studied the problem because it gave Google a way to neutralize AWS's advantage because with containers you could develop on AWS for example, and then run the application anywhere like Google's cloud. So it not only gave developers a path off of AWS. If Google could develop a strong service on GCP they could monetize that play. Now, focus your attention back to the diagram which shows this smiling, Alex Polvi from Core OS which was acquired by Red Hat in 2018. And he saw the need to bring Linux into the cloud. I mean, after all Linux was powering the internet it was the OS for enterprise apps. And he saw the need to extend its path into the cloud. Now here's how he described it at an OpenStack event in 2015. >> Similar to what happened with Linux. Like yes, there is still need for Linux and Windows and other OSs out there. But by and large on production, web infrastructure it's all Linux now. And you were able to get onto one stack. And how were you able to do that? It was, it was by having a truly open consistent API and a commitment into not breaking APIs and, so on. That allowed Linux to really become ubiquitous in the data center. Yes, there are other OSs, but Linux buy in large for production infrastructure, what is being used. And I think you'll see a similar phenomenon happen for this next level up cause we're treating the whole data center as a computer instead of trading one in visual instance is just the computer. And that's the stuff that Kubernetes to me and someone is doing. And I think there will be one that shakes out over time and we believe that'll be Kubernetes. >> So Alex saw the need for a dominant container orchestration platform. And you heard him, they made the right bet. It would be Kubernetes. Now Red Hat, Red Hat is been around since 1993. So it has a lot of on-prem. So it needed a future path to the cloud. So they rang up Google and said, hey. What do you guys have going on in this space? So Google, was kind of non-committal, but it did expose that they were thinking about doing something that was you know, pre Kubernetes. It was before it was called Kubernetes. But hey, we have this thing and we're thinking about open sourcing it, but Google's internal debates, and you know, some of the arm twisting from the engine engineers, it was taking too long. So Red Hat said, well, screw it. We got to move forward with OpenShift. So we'll do what Apple and Airbnb and Heroku are doing and we'll build on an alternative. And so they were ready to go with Mesos which was very much more sophisticated than Kubernetes at the time and much more mature, but then Google the last minute said, hey, let's do this. So Clayton Coleman with Red Hat, he was an architect. And he leaned in right away. He was one of the first outside committers outside of Google. But you still led these competing forces in the market. And internally there were debates. Do we go with simplicity or do we go with system scale? And Hen Goldberg from Google explains why they focus first on simplicity in getting that right. >> We had to defend of why we are only supporting 100 nodes in the first release of Kubernetes. And they explained that they know how to build for scale. They've done that. They know how to do it, but realistically most of users don't need large clusters. So why create this complexity? >> So Goldberg explains that rather than competing right away with say Mesos or Docker swarm, which were far more baked they made the bet to keep it simple and go for adoption and ubiquity, which obviously turned out to be the right choice. But the last piece of the puzzle was governance. Now Google promised to open source Kubernetes but when it started to open up to contributors outside of Google, the code was still controlled by Google and developers had to sign Google paper that said Google could still do whatever it wanted. It could sub license, et cetera. So Google had to pass the Baton to an independent entity and that's how CNCF was started. Kubernetes was its first project. And let's listen to Chris Aniszczyk of the CNCF explain >> CNCF is all about providing a neutral home for cloud native technology. And, you know, it's been about almost two years since our first board meeting. And the idea was, you know there's a certain set of technology out there, you know that are essentially microservice based that like live in containers that are essentially orchestrated by some process, right? That's essentially what we mean when we say cloud native right. And CNCF was seated with Kubernetes as its first project. And you know, as, as we've seen over the last couple years Kubernetes has grown, you know, quite well they have a large community a diverse con you know, contributor base and have done, you know, kind of extremely well. They're one of actually the fastest, you know highest velocity, open source projects out there, maybe. >> Okay. So this is how we got to where we are today. This ETR data shows container orchestration offerings. It's the same X Y graph that we showed earlier. And you can see where Kubernetes lands not we're standing that Kubernetes not a company but respondents, you know, they doing Kubernetes. They maybe don't know, you know, whose platform and it's hard with the ETR taxon economy as a fuzzy and survey data because Kubernetes is increasingly becoming embedded into cloud platforms. And IT pros, they may not even know which one specifically. And so the reason we've linked these two platforms Kubernetes and Red Hat OpenShift is because OpenShift right now is a dominant revenue player in the space and is increasingly popular PaaS layer. Yeah. You could download Kubernetes and do what you want with it. But if you're really building enterprise apps you're going to need support. And that's where OpenShift comes in. And there's not much data on this but we did find this chart from AMDA which show was the container software market, whatever that really is. And Red Hat has got 50% of it. This is revenue. And, you know, we know the muscle of IBM is behind OpenShift. So there's really not hard to believe. Now we've got some other data points that show how Kubernetes is becoming less visible and more embedded under of the hood. If you will, as this chart shows this is data from CNCF's annual survey they had 1800 respondents here, and the data showed that 79% of respondents use certified Kubernetes hosted platforms. Amazon elastic container service for Kubernetes was the most prominent 39% followed by Azure Kubernetes service at 23% in Azure AKS engine at 17%. With Google's GKE, Google Kubernetes engine behind those three. Now. You have to ask, okay, Google. Google's management Initially they had concerns. You know, why are we open sourcing such a key technology? And the premise was, it would level the playing field. And for sure it has, but you have to ask has it driven the monetization Google was after? And I would've to say no, it probably didn't. But think about where Google would've been. If it hadn't open source Kubernetes how relevant would it be in the cloud discussion. Despite its distant third position behind AWS and Microsoft or even fourth, if you include Alibaba without Kubernetes Google probably would be much less prominent or possibly even irrelevant in cloud, enterprise cloud. Okay. Let's wrap up with some comments on the state of Kubernetes and maybe a thought or two about, you know, where we're headed. So look, no shocker Kubernetes for all its improbable beginning has gone mainstream in the past year or so. We're seeing much more maturity and support for state full workloads and big ecosystem support with respect to better security and continued simplification. But you know, it's still pretty complex. It's getting better, but it's not VMware level of maturity. For example, of course. Now adoption has always been strong for Kubernetes, for cloud native companies who start with containers on day one, but we're seeing many more. IT organizations adopting Kubernetes as it matures. It's interesting, you know, Docker set out to be the system of the cloud and Kubernetes has really kind of become that. Docker desktop is where Docker's action really is. That's where Docker is thriving. It sold off Docker swarm to Mirantis has made some tweaks. Docker has made some tweaks to its licensing model to be able to continue to evolve its its business. To hear more about that at DockerCon. And as we said, years ago we expected Kubernetes to become less visible Stu Miniman and I talked about this in one of our predictions post and really become more embedded into other platforms. And that's exactly what's happening here but it's still complicated. Remember, remember the... Go back to the early and mid cycle of VMware understanding things like application performance you needed folks in lab coats to really remediate problems and dig in and peel the onion and scale the system you know, and in some ways you're seeing that dynamic repeated with Kubernetes, security performance scale recovery, when something goes wrong all are made more difficult by the rapid pace at which the ecosystem is evolving Kubernetes. But it's definitely headed in the right direction. So what's next for Kubernetes we would expect further simplification and you're going to see more abstractions. We live in this world of almost perpetual abstractions. Now, as Kubernetes improves support from multi cluster it will be begin to treat those clusters as a unified group. So kind of abstracting multiple clusters and treating them as, as one to be managed together. And this is going to create a lot of ecosystem focus on scaling globally. Okay, once you do that, you're going to have to worry about latency and then you're going to have to keep pace with security as you expand the, the threat area. And then of course recovery what happens when something goes wrong, more complexity, the harder it is to recover and that's going to require new services to share resources across clusters. So look for that. You also should expect more automation. It's going to be driven by the host cloud providers as Kubernetes supports more state full applications and begins to extend its cluster management. Cloud providers will inject as much automation as possible into the system. Now and finally, as these capabilities mature we would expect to see better support for data intensive workloads like, AI and Machine learning and inference. Schedule with these workloads becomes harder because they're so resource intensive and performance management becomes more complex. So that's going to have to evolve. I mean, frankly, many of the things that Kubernetes team way back when, you know they back burn it early on, for example, you saw in Docker swarm or Mesos they're going to start to enter the scene now with Kubernetes as they start to sort of prioritize some of those more complex functions. Now, the last thing I'll ask you to think about is what's next beyond Kubernetes, you know this isn't it right with serverless and IOT in the edge and new data, heavy workloads there's something that's going to disrupt Kubernetes. So in that, by the way, in that CNCF survey nearly 40% of respondents were using serverless and that's going to keep growing. So how is that going to change the development model? You know, Andy Jassy once famously said that if they had to start over with Amazon retail, they'd start with serverless. So let's keep an eye on the horizon to see what's coming next. All right, that's it for now. I want to thank my colleagues, Stephanie Chan who helped research this week's topics and Alex Myerson on the production team, who also manages the breaking analysis podcast, Kristin Martin and Cheryl Knight help get the word out on socials, so thanks to all of you. Remember these episodes, they're all available as podcasts wherever you listen, just search breaking analysis podcast. Don't forget to check out ETR website @etr.ai. We'll also publish. We publish a full report every week on wikibon.com and Silicon angle.com. You can get in touch with me, email me directly david.villane@Siliconangle.com or DM me at D Vollante. You can comment on our LinkedIn post. This is Dave Vollante for theCUBE insights powered by ETR. Have a great week, everybody. Thanks for watching. Stay safe, be well. And we'll see you next time. (upbeat music)

>> Hello, everyone. I'm Khalil Ahmad, Senior Director, Architecture at S&P Global. I have been working with S&P Global for six years now. Previously, I worked for Citigroup and Prudential. Overall, I have been part of IT industry for 30 years, and most of my professional career has been within financial sector in New York City metro area. I live in New Jersey with my wife and son, Daniel Khalil. I have a Master degree in software engineering from the University of Scranton, and Master in mathematics University of Punjab, Lahore. And currently I am pursuing TRIUM global Executive MBA. A joint program from the NYU Stern, LSE and HEC Paris. So today, I'm going to talk about building multi-cluster scalable container platform, supporting on-prem hybrid and multicloud use cases, how we leverage that with an S&P Global and what was our best story. As far as the agenda is concerned, I will go over, quickly the problem statement. Then I will mention the work of our core requirements, how we get solutioning, how Docker Enterprise helped us. And at the end, I will go over the pilot deployment for a proof of concept which we leverage. So, as far as the problem statement is concerned. Containers, as you all know, in the enterprise are becoming mainstream but expertise remains limited and challenges are mounting as containers enter production. Some companies are building skills internally and someone looking for partners that can help catalyze success, and choosing more integrated solutions that accelerate deployments and simplify the container environment. To overcome the challenges, we at S&P Global started our journey a few years back, taking advantage of both options. So, first of all, we met with all the stakeholder, application team, Product Manager and we define our core requirements. What we want out of this container platform, which supports multicloud and hybrid supporting on-prem as well. So, as you see my core requirements, we decided that we need first of all a roadmap or container strategy, providing guidelines on standards and specification. Secondly, with an S&P Global, we decided to introduce Platform as a Service approach, where we bring the container platform and provide that as a service internally to our all application team and all the Product Managers. Hosting multiple application on-prem as well as in multicloud. Third requirement was that we need Linux and Windows container support. In addition to that, we would also require hosted secure image registry with role based access control and image security scanning. In addition to that, we also started DevOps journey, so we want to have a full support of CI/CD pipeline. Whatever the solution we recommend from the architecture group, it should be easily integrated to the developer workstation. And developer workstation could be Windows, Mac or Linux. Orchestration, performance and control were few other parameter which we'll want to keep in mind. And the most important, dynamic scaling of container clusters. That was something we were also want to achieve, when we introduce this Platform as a Service. So, as far as the standard specification are concerned, we turn to the Open Container Initiative, the OCI. OCI was established in June 2015 by Docker and other leaders in the technology industry. And OCI operates under Linux Foundation, and currently contains two specification, runtime specification and image specification. So, at that time, it was a no brainer, other than to just stick with OCI. So, we are following the industry standard and specifications. Now the next step was, okay, the container platform. But what would be our runtime engine? What would be orchestration? And how we support, in our on-prem as well as in the multicloud infrastructure? So, when it comes to runtime engine, we decided to go with the Docker. Which is by default, runtime engine and Kubernetes. And if I may mention, DataDog in one of their public report, they say Docker is probably the most talked about infrastructure technology for the past few years. So, sticking to Docker runtime engine was another win-win game and we saw in future not bringing any challenge or issues. When it comes to orchestration. We prefer Kubernetes but that time there was a challenge, Kubernetes did not support Windows container. So, we wanted something which worked with a Linux container, and also has the ability or to orchestrate Windows containers. So, even though long term we want to stick to Kubernetes, but we also wanted to have a Docker swarm. When it comes to on-prem and multicloud, technically you could only support as of now, technology may change in future, but as of now, you can only support if you bring your own orchestration too. So, in our case, if we have control over orchestration control and not locked in with one cloud provider, that was the ideal situation. So, with all that, research, R&D and finding, we found Docker Enterprise. Which is securely built, share and run modern applications anywhere. So, when we come across Docker Enterprise, we were pleased to see that it meets our most of the core requirements. Whether it is coming on the developer machine, to integrating their workstation, building the application. Whether it comes to sharing those application, in a secure way and collaborating with our pipeline. And the lastly, when it comes to the running. If we run in hybrid or multicloud or edge, in Kubernetes, Docker Enterprise have the support all the way. So, three area one I just call up all the Docker Enterprise, choice, flexibility and security. I'm sure there's a lot more features in Docker Enterprise as a suite. But, when we looked at these three words very quickly, simplified hybrid orchestration. Define application centric policies and boundaries. Once you define, you're all set. Then you just maintain those policies. Manage diverse application across mixed infrastructure, with secure segmentation. Then it comes to secure software supply chain. Provenance across the entire lifecycle of apps and infrastructure through enforceable policy. Consistently manage all apps and infrastructure. And lastly, when it comes to infrastructure independence. It was easily forever lift and shift, because same time, our cloud journey was in the flight. We were moving from on-prem to the cloud. So, support for lift and shift application was one of our wishlist. And Docker Enterprise did not disappoint us. It also supported both traditional and micro services apps on any infrastructure. So, here we are, Docker Enterprise. Why Docker Enterprise? Some of the items in previous slides I mentioned. But in addition to those industry-leading platform, simplifying the IT operations, for running modern application at scale, anywhere. Docker Enterprise also has developer tools. So, the integration, as I mentioned earlier was smooth. In addition to all these tools, the main two components, the Universal Control Plane and the Docker Trusted Registry, solve lot of our problems. When it comes to the orchestration, we have our own Universal Control Plane. Which under the hood, manages Kubernetes and Docker swarm both clusters. So, guess what? We have a Windows support, through Docker swarm and we have a Linux support through Kubernetes. Now that paradigm has changed, as of today, Kubernetes support Windows container. So, guess what? We are well after the UCP, because we have our own orchestration tool, and we start managing Kubernetes cluster in Linux and introduce now, Windows as well. Then comes to the Docker Trusted Registry. Integrated Security and role based access control, made a very smooth transition from our RT storage to DTR. In addition to that, binary level scanning was another good feature from the security point of view. So that, these all options and our R&D landed the Docker Enterprise is the way to go. And if we go over the Docker Enterprise, we can spin up multiple clusters on-prem and in the cloud. And we have a one centralized location to manage those clusters. >> Khalil: So, with all that, now let's talk about how what was our pilot deployment, for proof of concept. In this diagram, you can see we, on the left side is our on-prem Data Center, on the right side is AWS, US East Coast. We picked up one region three zones. And on-prem, we picked up our Data Center, one of the Data Center in the United States of America, and we started the POC. So, our Universal Control Plane had a five nodes cluster. Docker Trusted Registry, also has a five node cluster. And the both, but in our on-prem Data Center. When it comes to the worker nodes, we have started with 18 node cluster, on the Linux side and the four node cluster on the Windows side. Because the major footprint which we have was on the Linux side, and the Windows use cases were pretty small. Also, this is just a proof of concept. And in AWS, we mimic the same web worker nodes, virtual to what we have on-prem. We have a 13 nodes cluster on Linux. And we started with four node cluster of Windows container. And having the direct connect from our Data Center to AWS, which was previously existing, so we did not have any connectivity or latency issue. Now, if you see in this diagram, you have a centralized, Universal Control Plane and your trusted registry. And we were able to spin up a cluster, on-prem as well as in the cloud. And we made this happen, end to end in record time. So later, when we deploy this in production, we also added another cloud provider. So, what you see the box on the right side, we just duplicate test that box in another cloud platform. So, now other orchestration tool, managing on-prem and multicloud clusters. Now, in your use case, you may find this little, you know, more in favor of on-prem. But that fit in our use case. Later, we did have expanded the cluster of Universal Control Plane and DTR in the cloud as well. And the clusters have gone and hundreds and thousands of worker nodes span over two cloud providers, third being discussed. And this solution has been working so far, very good. We did not see any downtime, not a single instance. And we were able to provide multicloud platform, container Platform as a Service for our S&P Global. Thank you for your time. If any questions, I have put my LinkedIn and Twitter account holder, you're welcome to ask any question

>> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020, Virtual. Brought to you by Red Hat, The Cloud Native Computing Foundation and Ecosystem partners. >> Welcome back, I'm Stu Miniman and this is CUBEs coverage of KubeCon CloudNativeCon 2020 in Europe, the virtual edition and of course one of the things we love when we come to these conferences is to get to the actual practitioners, understanding how they're using the various technologies especially here at the CNCF show, so many projects, lots of things changing and really excited. We're going to talk about security in a slightly different way than we often do on theCUBE so happy to welcome to the program from Sera4 I have Jeff Klink who's the Vice President of Engineering and Cloud. Jeff, thanks so much for joining us. >> Thanks too, thanks for having me. >> All right so I teed you up there, give us if you could just a quick thumbnail on Sera4, what your company does and then your role there. >> Absolutely so we're a physical hardware product addressing the telco markets, utility space, all of those so we kind of differentiate herself as a Bluetooth lock for that higher end space, the highest security market where digital encryption is really an absolute must. So we have a few products including our physical lock here, this is a physical padlock, it is where door locks and controllers that all operate over the Bluetooth protocol and that people can just use simply through their mobile phones and operate at the enterprise level. >> Yeah, I'm guessing it's a little bit more expensive than the the padlock I have on my shed which is getting a little rusty and needs a little work but it probably not quite what I'm looking for but you have Cloud, you know, in your title so give us if you could a little bit you know, what the underlying technology that you're responsible for and you know, I understand you've rolled out Kubernetes over the last couple of years, kind of set us up with what were the challenges you were facing before you started using that? >> Absolutely so Stu We've grown over the last five years really as a company like in leaps and bounds and part of that has been the scalability concern and where we go with that, you know, originally starting in the virtual machine space and, you know, original some small customers in telco as we build up the locks and eventually we knew that scalability was really a concern for us, we needed to address that pretty quickly. So as we started to build out our data center space and in this market it's a bit different than your shed locks. Bluetooth locks are kind of everywhere now, they're in logistics, they're on your home and you actually see a lot of compromises these days actually happening on those kind of locks, the home security locks, they're not built for rattling and banging and all that kind of pieces that you would expect in a telco or utility market and in the nuclear space or so you really don't want to lock that, you know, when it's dropped or bang the boat immediately begins to kind of fall apart in your hands and two you're going to expect a different type of security much like you'd see in your SSH certificates, you know, a digital key certificate that arrives there. So in our as we grew up through that piece Kubernetes became a pretty big player for us to try to deal with some of the scale and also to try to deal with some of the sovereignty pieces you don't see in your shed locks. The data sovereignty meeting in your country or as close to you as possible to try to keep that data with the telco, with the utility and kind of in country or in continent with you as well. That was a big challenge for us right off the bat. >> Yeah, you know Jeff absolutely, I have some background from the telco space obviously, there's very rigorous certifications, there's lots of environments that I need to fit into. I want to poke at a word that you mentioned, scale. So scale means lots of things to lots of different people, this year at the KubeCon CloudNativeCon show, one of the scale pieces we're talking about is edge just getting to lots of different locations as opposed to when people first thought about, you know, scale of containers and the like, it was like, do I need to be like Google? Do I have to have that much a scale? Of course, there is only one Google and there's only a handful of companies that need that kind of scale, what was it from your standpoint, is it you know, the latency of all of these devices, is it you know, just the pure number of devices, the number of locations, what was what was the scale limiting factor that you were seeing? >> It's a bit of both in two things, one it was a scale as we brought new customers on, there were extra databases, there was extra identity services, you know, the more locks we sold and the more telcos we sold too suddenly what we started finding is that we needed all these virtual machines and sources in some way to tie them together and the natural piece to those is start to build shared services like SSO and single sign on was a huge driver for us of how do we unite these spaces where they may have maintenance technicians in that space that work for two different telcos. Hey, tower one is down could you please use this padlock on this gate and then this padlock on this cabinet in order to fix it. So that kind of scale immediately showed us, we started to see email addresses or other on two different places and say, well, it might need access into this carrier site because some other carrier has a equipment on that site as well. So the scale started to pick up pretty quickly as well as the space where they started to unite together in a way that we said, well, we kind of have to scale to parts, not only the individuals databases and servers and identity and the storage of their web service data but also we had to unite them in a way that was GDPR compliant and compliant with a bunch of other regulations to say, how do we get these pieces together. So that's where we kind of started to tick the boxes to say in North America, in Latin America, South America we need centralized services but we need some central tie back mechanism as well to start to deal with scale. And the scale came when it went from Let's sell 1000 locks to, by the way, the carrier wants 8000 locks in the next coming months. That's a real scalability concern right off the bat, especially when you start to think of all the people going along with those locks in space as well. So that's the that's the kind of first piece we had to address and single sign on was the head of that for us. >> Excellent, well you know, today when we talk about how do i do container orchestration Kubernetes of course, is the first word that comes to mind, can you bring us back though, how did you end up with Kubernetes, were there other solutions you you looked at when you made your decision? What were your kind of key criteria? How did you choose what partners and vendors you ended up working with? >> So the first piece was is that we all had a lot of VM backgrounds, we had some good DevOps backgrounds as well but nobody was yet into the the container space heavily and so what we looked at originally was Docker swarm, it became our desktop, our daily, our working environment so we knew we were working towards microservices but then immediately this problem emerged that reminded me of say 10, 15 years ago, HD DVD versus Blu-ray and I thought about it as simply as that, these two are fantastic technologies, they're kind of competing in this space, Docker Compose was huge, Docker Hub was growing and growing and we kind of said you got to kind of pick a bucket and go with it and figure out who has the best backing between them, you know from a security policy, from a usage and size and scalability perspective, we knew we would scale this pretty quickly so we started to look at the DevOps and the tooling set to say, scale up by one or scale up by 10, is it doable? Infrastructure as code as well, what could I codify against the best? And as we started looking at those Kubernetes took a pretty quick change for us and actually the first piece of tooling that we looked at was Rancher, we said well there's a lot to learn the Kubernetes space and the Rancher team, they were growing like crazy and they were actually really, really good inside some of their slack channels and some of their groups but they said, reach out, we'll help you even as a free tier, you know and kind of grow our trust in you and you know, vice versa and develop that relationship and so that was our first major relationship was with Rancher and that grew our love for Kubernetes because it took away that first edge of what am i staring at here, it looks like Docker swarm, they put a UI on it, they put some lipstick on it and really helped us get through that first hurdle a couple years ago. >> Well, it's a common pattern that we see in this ecosystem that you know, open source, you try it, you get comfortable with it, you get engaged and then when it makes sense to roll it into production and really start scaling out, that's when you can really formalize those relationships so bring us through the project if you will. You know, how many applications were you starting with? What was the timeline? How many people were involved? Were there, you know, the training or organizational changes, you know, bring us through under the first bits of the project. >> Sure, absolutely. So, like anything it was a series of VMs, we had some VM that were load balanced for databases in the back and protected, we had some manual firewalls through our cloud provider as well but that was kind of the edge of it. You had your web services, your database services and another tier segregated by firewalls, we were operating at a single DCs. As we started to expand into Europe from the North America, Latin America base and as well as Africa, we said this has got to kind of stop. We have a lot of Vms, a lot of machines and so a parallel effort went underway to actually develop some of the new microservices and at first glance was our proxies, our ingresses, our gateways and then our identity service and SSL would be that unifying factor. We honestly knew that moving to Kubernetes in small steps probably wasn't going to be an easy task for us but moving the majority of services over to Kubernetes and then leaving some legacy ones in VM was definitely the right approach for us because now we're dealing with ingressing around the world. Now we're dealing with security of the main core stacks, that was kind of our hardcore focus is to say, secure the stacks up front, ingress from everywhere in the world through like an Anycast Technology and then the gateways will handle that and proxy across the globe and we'll build up from there exactly as we did today. So that was kind of the key for us is that we did develop our micro services, our identity services for SSO, our gateways and then our web services were all developed in containers to start and then we started looking at complimentary pieces like email notification mechanisms, text notification, any of those that could be containerized later, which is dealt with a single one off restful services were moved at a later date. All right. >> So Jeff, yeah absolutely. What to understand, okay, we went through all this technology, we did all these various pieces, what does this mean to your your business projects? So you talked about I need to roll out 8000 devices, is that happening faster? Is it you know, what's the actual business impact of this technology that you've rolled out? >> So here's the key part and here's a differentiator for us is we have two major areas we differentiate in and the first one is asymmetric cryptography. We do own the patents for that one so we know our communication is secure, even when we're lying over Bluetooth. So that's kind of the biggest and foremost one is that how do we communicate with the locks on how do we ensure we can all the time. Two is offline access, some of the major players don't have offline access, which means you can download your keys and assign your keys, go off site do a site to a nuclear bunker wherever it may be and we communicate directly with the lock itself. Our core technology is in the embedded controllers in the lock so that's kind of our key piece and then the lock is a housing around it, it's the mechanical mechanism to it all. So knowing that we had offline technology really nailed down allowed us to do what many called the blue-green approach, which is we're going down for four hours, heads up everybody globally we really need to make this transition but the transition was easy to make with our players, you know, these enterprise spaces and we say we're moving to Kubernetes. It's something where it's kind of a badge of honor to them and they're saying these guys, you know, they really know what they're doing. They've got Kubernetes on the back end, some we needed to explain it to but as soon as they started to hear the words Docker and Kubernetes they just said, wow, this guys are serious about enterprise, we're serious about addressing it and not only that they're forefront of other technologies. I think that's part of our security plan, we use asymmetric encryption, we don't use the Bluetooth security protocol so every time that's compromised, we're not compromised and it's a badge of honor we were much alongside the Kubernetes. >> Alright, Jeff the thing that we're hearing from a lot of companies out there is that that transition that you're going through from VMs to containerization I heard you say that you've got a DevOps practice in there, there's some skill set challenges, there's some training pieces, there's often, you know, maybe a bump or two in the road, I'm sure your project went completely smoothly but what can you share about, you know, the personnel skill sets, any lessons learned along the way that might help others? >> There was a ton. Rancher took that first edge off of us, you know, cube-cuddle, get things up, get things going, RKE in the Rancher space so the Rancher Kubernetes engine, they were kind of that first piece to say how do I get this engine up and going and then I'll work back and take away some of the UI elements and do it myself, from scheduling and making sure that nodes came up to understanding a deployment versus a DaemonSet, that first UI as we moved from like a Docker swarm environment to the the Rancher environment was really kind of key for us to say, I know what these volumes are, I know the networking and I all know these pieces but I don't know how to put core DNS in and start to get them to connect and all of those aspects and so that's where the UI part really took over. We had guys that were good on DevOps, we had guys are like, hey how do I hook it up to a back end and when you have those UI, those clicks like your pod security policy on or off, it's incredible. You turn it on fine, turn on the pod security policy and then from there, we'll either use the UI or we'll go deeper as we get the skill sets to do that so it gave us some really good assurances right off the bat. There were some technologies we really had to learn fast, we had to learn the cube-cuddle command line, we had to learn Helm, new infrastructure pieces with Terraform as well, those are kind of like our back end now. Those are our repeatability aspects that we can kind of get going with. So those are kind of our cores now is it's a Rancher every day, it's cube-cuddle from our command lines to kind of do those, Terraform to make sure we're doing the same thing but those are all practices we, you know, we cut our teeth with Rancher, we looked at the configs that are generated and said, alright, that's actually pretty good configure, you know, maybe there's a team to tolerance or a tweak we could make there but we kind of work backwards that way to have them give us some best practices and then verify those. >> So the space you're in, you have companies that rely on what you do. Security is so important, if you talk about telecommunications, you know, many of the other environments they have, you know, rigid requirements. I want to get to your understanding from you, you're using some open source tools, you've been working with startups, one of your suppliers Rancher was just acquired by SUSE, how's that relationship between you know, this ecosystem? Is that something that is there any concerns from your end user clients and what are your own comfort level with the moves and changes that are happening? >> Having gone through acquisitions myself and knowing the SUSE team pretty well, I'd say actually it's a great thing to know that the startups are funded in a great source. It's great to hear internally, externally their marketing departments are growing but you never know if a startup is growing or not. Knowing this acquisitions taking place actually gives me a lot of security. The team there was healthy, they were growing all the time but sometimes that can just be a face on a company and just talking to the internals candidly as they've always done with us, it's been amazing. So I think that's a great part knowing that there's some great open source texts, Helm Kubernetes as well that have great backers towards them, it's nice to see part of the ecosystem getting back as well in a healthy way rather than a, you know, here's $10,000 Platinum sponsorship. To see them getting the backing from an open source company, I can't say enough for. >> All right, Jeff how about what's going forward from you, what projects you're looking at or what what additions to what you've already done are you looking at doing down the road? >> Absolutely. So the big thing for us is that we've expanded pretty dramatically across the world now. As we started to expand into South Africa, we've expanded into Asia as well so managing these things remotely has been great but we've also started to begin to see some latencies where we're, you know, heading back to our etcd clusters or we're starting to see little cracks and pieces here in some of our QA environment. So part of this is actually the introduction and we started looking into the fog and the edge compute. Security is one of these games where we try to hold the security as core and as tight as you can but trying to get them the best user experience especially in South Africa and serving them from either Europe or Asia, we're trying to move into those data centers and region as well, to provide the sovereignty, to provide the security but it's about latency as well. When I opened my phone to download my digital keys I want that to be quick, I want the administrators to assign quickly but also still giving them that aspect to say I could store this in the edge, I could keep it secure and I could make sure that you still have it, that's where it's a bit different than the standard web experience to say no problem let's put a PNG as close as possible to you to give you that experience, we're putting digital certificates and keys as close as possible to people as well so that's kind of our next generation of the devices as we upgrade these pieces. >> Yeah, there was a line that stuck with me a few years ago, if you look at edge computing, if you look at IoT, the security just surface area is just expanding by orders or magnitude so that just leaves, you know, big challenges that everyone needs to deal with. >> Exactly, yep. >> All right, give us the final word if you would, you know, final lessons learned, you know, you're talking to your peers here in the hallways, virtually of the show. Now that you've gone through all of this, is there anything that you say, boy I wish I had known this it would have been this good or I might have accelerated things or which things, hey I wish I pulled these people or done something a little bit differently. >> Yep, there's a couple actually a big parts right off the bat and one, we started with databases and containers, followed the advice of everyone out there either do managed services or on standalone boxes themselves. That was something we cut our teeth on over a period of time and we really struggled with it, those databases and containers they really perform as poorly as you think they might, you can't get the constraints on those guys, that's one of them. Two we are a global company so we operate in a lot of major geographies now and ETC has been a big deal for us. We tried to pull our ETC clusters farther apart for better resiliency, no matter how much we tweak and play with that thing, keep those things in a region, keep them in separate, I guess the right word would be availability zones, keep them make redundant as possible and protect those at all costs. As we expanded we thought our best strategy would do some geographical distribution, the layout that you have in your Kubernetes cluster as you go global for hub-and-spoke versus kind of centralized clusters and pods and pieces like that, look it over with a with an expert in Kubernetes, talk to them talk about latencies and measure that stuff regularly. That is stuff that kind of tore us apart early in proof of concept and something we had to learn from very quickly, whether it'll be hub-and-spoke and centralize ETC and control planes and then workers abroad or we could spread the ETC and control planes a little more, that's a strategy that needs to be played with if you're not just in North America, South America, Europe, Asia, those are my two biggest pieces because those are our big performance killers as well as discovering PSP, Pod Security Policies early. Get those in, lock it down, get your environments out of route out of, you know, Port 80 things like that on the security space, those are just your basic housecleaning items to make sure that your latency is low, your performances are high and your security's as tight as you can make it. >> Wonderful, well, Jeff thank you so much for sharing Sera4 for story, congratulations to you and your team and wish you the best luck going forward with your initiatives. >> Absolutely, thanks so much Stu. >> All right, thank you for watching. I'm Stu Miniman and thank you for watching theCUBE. (soft music)

>> Live from Seattle, Washington it's the CUBE covering KubeCon and CloudNativeCon North America 2018. Brought to you by Red Hat, the Cloud Native Computing Foundation, and its ecosystem partners. >> Hey, welcome back, everyone. We are here live with CUBE coverage at KubeCon, CloudNativeCon 2018 in Seattle. I'm John Furrier with Stu Miniman your hosts all week, three days of coverage. We're in day two. 8,000 attendees, up from 4,000, spanning to China, in Europe, everywhere, the CNCF is expanding. The Linux Foundation, and the ecosystems expanding, we're here with Dan Kohn who's the executive director of the CNCF. Dan, great to see you. I know you work hard. (laughs) I see you out in China. You've done the work. You guys and the team have taken this hockey stick as it's described on the Twittersphere, really up and to the right, you've doubled, it's almost like Moore's law for attendance. (laughs) Doubling every six months. It's really a testament of how it's structured, how you guys are managing it, the balances that you go through. So congratulations. >> So thank you very much, and I'm thrilled that you guys have been with us through that whole ride, that we met here in Seattle two years ago at the first KubeCon we ran with 1,000 attendees. And here we are eight times higher two years later. But I absolutely do need to say it is the community that's growing, and we try and organize them a little bit and harness some of that excitement and energy and then there is a ton of logistics and effort that it takes to go from 28 members to 349 and to put on an event like this, but we do have an amazing team at the Linux Foundation and this is absolutely an all hands on deck where the entire events team is out here and working really hard. >> You guys are smart, you know what you're doing, and you have the right tone and posture, but you set it up right, so it's end user driven, it's open-source community as the core of the event, and you're seeing end users that have contributed, they're now consuming, you have vendors coming in, but you set the nice playbook up, and the downstream benefits of that open-source core has impacted IT, developers, average developers, and this is the magic. And you guys don't take too many hard stands on things, you take a good enough stand on the enablement piece of it. This is a critical piece. Explain the rationale because I think this is a success formula. You don't go too far and say, here's the CNCF stack. >> Right. >> You pull back a little bit on that and let the ecosystem enable it. Talk about that rationale because I think this is an important point. >> Sure and I would say that one of the huge advantages that CNCF has had is that we came later after a lot of other projects. So our parent, the Linux Foundation, has been around for 15 years. We've been able to leverage all of their expertise. We've looked at some of the mistakes that OpenStack, and Apache, and IETF, and other giants who came before us did, and our aspiration has always been to make entirely new mistakes rather than to replicate the old ones. But as you mentioned end user is a key focus, so when you look at our community, how CNCF is set up, we have a governing board that's mainly vendors, it does have developer and other reps on it. We have our technical oversight committee of these nine experts, kind of like our supreme court, and then we have this end user community that is feeding requirements and feedback back to the other group. >> I want to ask you about the structure, and I think this is important because you guys have a great governance model, but you have this concept of graduation. You have Kubernetes, and it's really solid, people are very happy with it, and there's always debates in open-source as you know, but there's a concept of graduating. Anyone can have projects, and explain that dynamic. 'Cause that's, I've heard people say, oh that's part of the CNCF, and well it hasn't graduated, but it's a project. It's important as a laddering there, explain that concept. I think this is important for people to understand that you're open, but there's kind of a model of graduation. What does it mean? >> Sure and it, people have said, oh you mean they've graduated, so they've left now, right? Like the kids leaving the home. And it's definitely not that model. Kubernetes is still very much part of CNCF. We're happy to do it. But we think that one of CNCF's functions is as a signaling and a marketing to enterprise users. And we like the cliche of crossing the chasm where we talk about 2018 was really the year that Kubernetes crossed the chasm. Went from as early adopters who'd been using it for years and were thrilled with it but they actually jump over now to the early majority. I will say though that the late majority, the laggards, the skeptics, they're not using these technologies yet. We still have a ton of opportunity for years to come on that. So we say the graduated projects, which today is not just Kubernetes but also Prometheus and Envoy. Those are the ones that are suitable for really any enterprise company, and that they should feel confident these are very mature, serious technologies for companies of all size. The majority of our projects are incubating. Those are great projects, technically capable, companies should absolutely use them if the use case fits, but they're less mature. And then we have this other category of the Sandbox, 11 projects in there, and we say look, these are incredibly promising. If you are technical enough and you have the use cases, you absolutely should consider it, but they are less mature. And then our hope is to help the projects move along that graduation phase. >> And that's how companies start. Bloomberg's plan, I thinking jumping into Sandbox, they'll start getting some code in there that'll attract some people, they get their code, they don't have to come back after the fact and join in. So you have the Sandbox, you've got projects, you've got graduation, so. >> Now Bloomberg's a little bit unusual, and I like them as an example where they have, I don't know if they mentioned this, but almost a philosophy not to spend money on software. And of course that's great. All of our projects are free and open-source, and they're willing to spend money on people, and they hire a spectacular group of engineers, and then they support everything in-house. But in reality, the vast majority of end users are very happy to work with the vendor, including a lot of our members, and pay for some of that support. And so a Bloomberg can be a little bit more adventurous than many, I think. >> Dan, I wonder if you can provide a little bit of context. I hear some people look at really kind of the conformance and certification that the CNCF does. And I think in many ways learn from the mistakes of some of the things we've done in the past because they'll see there's so many companies, it's like, well there's too many distributions. Maybe you could help explain the difference between a distribution-- >> Sure. >> And what's supported and how that makes sense. >> And I think when you look back at, and we just had, CNCF just had our three-year birthday this week, we have a little birthday cake on Twitter and everything. But if you look at all the activities we've been involved in over those three years, KubeCon, CloudNativeCon, we have a service provider program, we've done a lot of marketing, helping projects, I think it's the certification and the software conformance is the single thing that we've had done that's had the biggest impact on the community. And the idea here is that we wanted a way for individual companies to be able to make changes to Kubernetes because they all want to, but to still have confidence that you could take the same workload and move it between the different public clouds, between the different enterprise distros or just vanilla Kubernetes that you download or different installers out there. And so the solution was an open-source software conformance project that anyone can download these tasks and run them, and then a process where people upload the test results and say, yes my implementation is still conformant. I've made these changes, but I haven't broken anything. And we really have some amazing cases of our members, some of our biggest members, who had turned off APIs, maybe in their public cloud for good reasons. They said, oh this doesn't apply or we don't, but that's exactly the kind of thing that can cause incompatibility. >> Yeah, I mean that's critically important, and the other thing that is, what I haven't heard, is there's so many projects here. And we go to the Amazon show and it's like, I'm overwhelmed and I don't know what to do, and I can't keep up with everything. I'm actually surprised I don't hear that here because there are pockets, and this is multiple communities, not like a single monolithic community, so you've got, you know Envoy has their own little separate show and Operators has a thing on Friday that they're doing, and there's the Helm community and sometimes I'm putting many of the pieces together, but oftentimes I'm taking just a couple of the pieces. How do you manage this loosely coupled, it's like distributed architecture. >> Loosely coupled is a key phrase. I think the big advantage we have is our anchor tenant of Kubernetes has its own gravitational field. And so from a compatibility standpoint, we have this, excuse me, certification program for Kubernetes and then all of the other projects essentially ensure they're orbiting around and they ensure that they're compatible with Kubernetes, that also ensures they're compatible with each other. Now it's definitely the case that our projects are used beyond just Kubernetes. We were thrilled with Amazon's announcement two weeks ago of commercial support for Envoy and talking about how one of the things they loved about Envoy is that is doesn't just work on Kubernetes, they can use it on their proprietary ECS platform on their regular EC2 environment as well. And that's true for almost all of our projects. Prometheus is used in Mesos, is used in Docker Swarm, is used in VMs, but I do think that having so much traction and momentum around Kubernetes just is a forcing function for the whole community to come together and stay compatible. >> Well you guys did a great job. That happened last year. It's really to me is an example of a historic moment in the computer industry because this is a modern version of enabling technology that's going to enable a lot of value creation, a lot of wealth creation, a lot of customer, and it's all in a new way, so I think you guys really cracked the code on that and continued success. You've obviously had China going gangbusters, you're expanding, China by the way is one of the largest areas we've reported on Siliconangle.com and the CUBE in the past. China has emerged as one of the largest contributors and consumers of open-source given the rise of all the action going on in China. >> And we've been thrilled to see that, and I mean there was just the example yesterday where etcd is now the newest project, the newest incubating project in CNCF, and the co-creator of that and really the lead maintainer for it left CoreOS when it was acquired by Red Hat and is now with Alibaba. And he's originally from China. He is helping Alibaba just who's a platinum member of CNCF, who's been offering a certified Kubernetes service, but they're now looking at how they can move much more of their internal workloads over to it. JD.com has 25,000 servers. That's the second biggest retailer in China. >> It's a constituent. >> I was there six times last year. >> I know you were. >> I ran into you once in a hotel lobby. (laughing) >> What are you doing in China? It's huge, we're here. This is a big dynamic. This is new. I mean this is a big force and function. >> And to have so much energy, and I do also want to really emphasize the two-way street, that it's not just Chinese companies adopting these technologies that started in the US. >> They're contributing. >> We were thrilled a month ago to have Harbor come in as an incubating project and that started in China and is now being used across the world. >> Dan, 2019, you've got three shows again, Barcelona, Shanghai, and San Diego. >> Exactly. >> Of course the numbers are going to be up and to the right, but what else should we be looking for? >> So I think the two, so definitely China, we're going to continue doing it there, we continue to be relations serverless, we're thrilled with the progress of our serverless working group. They have this new cloud event spec, we have all of the different major clouds participating in it. The third area that I think you're going to see us that is somewhat new is looking at telcos. And our vision is that you can take a lot, most networking code today is done in virtual machines called virtual network functions. We think those should evolve to become cloud native network functions. The same networking code running in containers on Kubernetes. And so this is actually going to be our first time with a booth at Mobile World Congress in Barcelona in February. And we're going to be talking about-- >> Makes a lot of sense. IOT, over the top, a lot of enablement there. Makes inefficiencies in that inefficient stacks. >> Yeah, and on the edge as well. >> Dan, thanks for coming out, I appreciate it. Again, you've done the work, hard work, and continue it, great success, congratulations. I know it's early days still but. >> I hope it is. At some date Kubernetes is going to plateau. But it really doesn't feel like it'll be 2019. >> Yeah, it definitely is not boring. (laughing) Even though we had much more, Dan. >> Dan Kohn, executive director of the CNCF. Here inside the CUBE, breaking it all down, again, another successful show. Just the growth, this is the tsunami, it's a rise of Kubernetes and the ecosystem around it, creating values, the CUBE coverage, live here in Seattle. I'll be back with more coverage after this short break. I'm John Furrier with Stu Miniman. Be right back. (upbeat music)

>> Announcer: Live from Las Vegas, it's The Cube covering Dell Technologies World 2018. Brought to you by Dell EMC and its ecosystem partners. >> We're back at Dell Technologies World. It's the inaugural Dell Technologies World. You're watchin' The Cube, the leader in live tech coverage. My name is Dave Vallante, and I'm really excited to have Sanjay Poonen on, COO of VMWare, long-time Cube alum. Great to see you, my friend. >> Always great, Dave. >> Thanks again so much for makin' time. I know you're in and out, but things are good. We had Pat on, on Monday. You guys made the call early on. You said to the industry, you know, I think the industry handed us and maybe the forecasts are a little bit conservative. We're seeing great demand. We love our business right now, and it's comin' true. Data centers booming, VMWare's kickin' butt. It's goin' great. >> You know it's been obviously a very good couple of years, since the Dell EMC merger. It's really helped us, and you know, when we think about our partnerships, we put this in a very special place. In the last two years, partnerships like Dell and AWS have been very instrumental, built on top of the partnerships we've had for many years. And our core principles at VMWare have not changed. We're really focused on software defining the data center. Why? Because it makes you more agile, removes costs, reduces complexity, makes the planet more green. We think we've got a long way to go in just building that private cloud, making the data center feel like a cloud. That's priority number one. Priority number two, extending tno the hybrid cloud. Last time we talked was at AWS Reinvent. That's very important. We're doing a bit of work there at AWS and many other clouds. And user computing, making sure that every one of these type of devices are secure and managed, whether it's Apple devices, Google, or Microsoft. Those three priorities have still stayed the same, and now Dell's comin' to give us a lot more of that sort of draft, to help us do that inside the Dell EMC customer base, too. >> Yeah, I mean you guys are doin' it again, the whole, NSX obviously is booming. >> Sanjay: Big launch this week. >> You know, it's funny, the whole software-defined networking thing. Everybody flocked to it. VCs flocked to it. You guys changed the game with that Nycera acquisition. I mean, could you imagine, I guess you did imagine what it was going to become, I mean it's really taken off in a big way. >> Bold move. I got to give credit to the, I mean I wasn't at the company at the time, but I got to tell you, when I saw that I was stunned. Paying 1.2 billion for a company that didn't have much revenue. But here we are. We talked about it in our earnings call being a 1.4 billion one rate business. 4,500 hundred customers. We were zero customers five years ago when we did the acquisition, and what we really defined is that the future of networking is going to be software-defined, clearly, and it's much the same way a Tesla is transforming the automotive industry, right? What's the value of a Tesla? It's not just the hardware, but the software that's changing the way in which you drive, park, all of the mapping, all of that stuff. We believe the same way the networking industry's going to go through mighty revolution. We think the data center gets more efficeint and driven through software. The path into the into the public cloud, and the path to the branch, and that's what we as we launched our virtual cloud networking. It's extremely differentiated in the industry. We're the only ones really pioneering that, and we think it's extremely visionary. And we're excited to take our customers on this journey. It was a big launch for us this week, and we think NSX is just getting started. 4500 customers is about 1% of our roughly 500,000 customers Every single one of them should be looking at NSX. Big opportunity ahead of us. >> Huge. And the cloud play, we talked about this at VM World last summer. The clarity now that your customers have. They can now make bets for a couple of cycles anyway, really having confidence in your cloud strategy. You've seen that, I'm sure, in your customer base. >> We have, and you know, it started off by telling the world that the 4,000 service providers that have built their stack on VMWare, VMWare Cloud Providers, VCPP, are all going to be very special to us as they build out their clouds, often in many specialized country that have country-specific cloud requirements. But the we're going to take the public clouds and systematically start working them. IBM cloud was the first, When they acquired software we had a strong relationship with them, announced two or three years ago. And then I think the world was shocked. It was almost, as I've described on the media, a Berlin Wall moment, when AWS and VMWare came together because it sort of felt like the United States and Soviet German in 1987, okay? And you know, here we have these two companies, really workin'. That's worked out very well for us, and then we've done systematic other things with Azure, Google, and so on and so forth, and we'll see how the public cloud plays out, but we think that that hybrid cloud bridge. We're going to be probably the only company who can really play a very pivotal role in the world moving from private cloud to public cloud and there's going to be balance on both sides of that divide. >> So you really essentially are trying to become the infrastructure for the digital world now, aren't you? Talk about that a little bit. You're seeing new workloads, obviously AI's all the buzz. You guys are doing some work in blockchains. It's going to take a while for all that to pick up, but really it's the ability and containers is the other thing. Everybody thought, oh containers, that's the end of VMs, and Pat at the time said, no no no, you guys don't understand. Let me explain it. He sort of laid it out. You seem to be embracing that, again embracing change. >> I got to tell you, that one for me because I'll tell you when I first joined the company four and a half years ago, I was at SAP. I asked Pat two questions. I said the public cloud's going to, I mean, probably take out VMWare, aren't you concerned with Amazon. Here we are taking that headwind and making a tailwind. The second was like, everyone's talking about Docker. Aren't containers going to just destroy VMs? And that one wasn't as clear to us at the time, but we were patient. And what happened we started to notice in the last few years. We began to notice on GitHub tremendous amount of activity around Kubernetes, and here comes Google almost taking the top off of a lot of you know parts of Docker Two, Docker Swarm, Enterprise, Docker still remains a very good container format, but the orchestration layers become a Google-based project called Kubernetes. And I think our waiting allowed us and pivotal to embrace Google in the partnership that we announced last year. And we plan to become the de facto enterprise container platform. If VMs became the VM in VMWare and we have 500,000 customers, tens of millions of VMs, you'd think we could multiply those VMs by some number to get number of containers. VMWare has its rightful place, a birthright, to become the de facto enterprise container platform. We're just getting started, both between us and Pivotal, the Kubernetes investment, Big deal. And we're going to do it in partnership with companies like Google. >> I want to ask you about Pivotal. When Joe Tucci was the swansong in the MC world, he came out with an analyst meeting and we asked them, if you had a mulligan, you know, what would you do over again. He said, you know, we're going to answer it this way. He said, I wished I had done more to bring together the family, you know, the federation. We laid that vision out, and I probably, he said, personally I probably could've done more. I feel like Michael has taken this on. I almost feel like Joe, when he laughs at Michael. My one piece of advice is do a better job than I did with that integration. And it seems like Michael's takin' that on as an outsider. What can you tell us about the relationship between all the companies, particularly Pivotal. >> Yeah, you know Joe's a very special man, as our chairman, and Joe and Pat are the reasons I joined VMWare, and so I have tremendous respect for them. And he stayed on as an advisor to Mike O'Dell. And I think Mike O'Dell just took a lot of those things and improved on it. I wouldn't say that anything was dramatically bad, but you know he tightened up much of the places where we could work together. One material change was having the Dell EMC reps carry quota, for example VMWare. They're incetivized. That has been a huge difference to allow us to have our sales forces completely align together. Big big huge difference. I mean, sales people care about our product when they're compensated, carry quota on it, and drive it. The second aspect was in many of these places where Dell and VMWare or VMWare and Pivotal were needed to just take obstacles out of the way, and I don't think Pivotal would've been really successful if it had stayed in VMWare four or five years ago. So Paul Mertz leaving, the genius of that whole move, which Joe orchesthrated, and allowing them to flourish. Okay, here they have four or five years, they've gone public. They have a tremendous amount of traction. Then last year, we began to see that Kubernetes Coming back allowed us to get closer to them, okay? We didn't need to do that necessarily by saying that Pivotal needs to be part of VMWare. We just needed to build a joint engineering effort around Kubernetes And make that enormously successful. So you get the best of both worlds. We're an investor, obviously, in Pivotal. We're proud of their success in the public markets. We benefit some from that sort of idea process, but at the same time we want to make sure this Kubernetes Effort and the broader app platform, our cloud foundry, is enormously successful, and every one of our customers who have VMs starts looking containers. >> Well, I always said Pivotal was formed with a bunch of misfit toys that just didn't seem to fit into VMWare. >> Sanjay: It's come a long way. >> And you took that, but it was smart because you took it and said, here it is. Let's start figuring that out. Who better to do that than Paul? And it's really come together and obviously a very successful. >> Yeah, Rob, Scott, Bill, Yara, many of that team there. They're passionate about developers, okay? We understand the infratstructure role very well, but when you can get dev and ops together, in a way they collaborate, so we're excited about it. And we have a key part for us, we have a very simple mission: to make the container platform just very secure. What's the differenetiation between us and other companies trying to build container platforms? NSX? So our contribution into that is to take Kubernetes Watch for some of the management capabilities, and then add NSX to it, highly differentiate it. And now all of a sudden customers say, this is the reason why I mean, 'cause every container brings a place where the port could be insecure. NSX makes that secture, and we think that that's another key part to what's made NSX the launch this week extremely sepcial is that its story relates to cloud and containers. Those two Cs, I would say, cloud and containers. We've taken what were headwinds to us, VMWare over the last four or five years, and made them tailwinds. And for us that's been a tremendous learnnig lesson, not just I would say in our own technology road map, but in leadership and management. That's important for us as business leaders, too. >> Dave: And I got to give some love to my friends in the Vsin world, Yen Bing and those guys. Obviously Vsin doin' very well. Give us the update there. I mean, you're doin', he's doin' exactly what you said: we're going to do to networking and storage what we did to compute. >> I mean, again you know, when we start things off. If you'll remember, three or four years ago, we were confusing EMC and VMWare, Evo, Rails, some of those things. We just had to clean that up. And as Dell EMC came together and VMWare, we said, listen. We're going to do software-defined storage really well because it has a very close synergy point to the Kubernetes I mean, we know a lot about storage because it's very closely connected to Compute. And if we could do that better than anybody else, and in the meantime all these startups were doing reasonably well, Simplicity, Nutanics, Pivotry, so on and so forth. I mean there's no reason if we don't have our act together we could build the best software-defined storage and then engineer a system together with Dell that has the software, and that's what VX rails has become. So a few false stubs of the toe when we started off, you know three or four years ago, but we've come a long way. Pat talked about over 10,000 customers at the revenue run rate that we announced last year, and a 600 million run rate at the end of Q4. We believe we are, for just the software piece, we are the de facto leader, and we have to continue to make customers happy and to drive, you know, this as the future of hyper converge infrastructure because converged had its place. And now the coming together of Compute Storage, over time networking with a layer of management, that's the future of the data center. >> Yeah, I was watching. THere's some good, interesting maneuvering goin' on in the marketplace. A lot of fun for a company like ours to watch. I want to talk about leadership. There's a great, you got to go to Sanjay's LinkedIn profile. There's an awesome video on there. It's like a mini TED talk that some of your folks mashed up and put out there. It's only about eight minutes. But I want to touch on some of the things that I learned from that video. Your background, I mean I knew you came from India. You came over at 18 years old, right? >> Sanjay: I was very fortunate. I grew up in a poor home in India, and I came here only because I got a scholarship to go to Dartmouth College. And I think I might have been one of the few brown-skinned guys in Hanover, New Hampshire. I mean, you've been there, you know there's not much Indian goin' on here. (laughter) But I'm very forutnate. And this country is a very special country to immigrants, if you work hard and if you're willing to apply yourself. I'm a product of that hard work. And now as an Indian American living in California. So I feel very fortunate for all that both the country and people who invested in me over the last many decades have helped me become who I am. >> So you were on a scholarship to Dartmouth. >> Yes, that's right. >> As a student in India. So obviously an accomplished student in India, and you said, you know, I got bullied a little bit. I had the glasses, right? Somebody once told me, Dave, don't peak in high school. It's good advice, right? So it was funny to hear you tell that story because I see you as such a charismatic, dynamic leader. I can't picture you as, you know, a little kid getting bullied. >> We were always geeks at one point in time, but one of the things my mother and dad always taught me, especially my mom, who had a tremendous influence on my life and is my hero, is, listen, don't worry what people say about you, okay? Your home is always going to feel a safety and a fortress to us, and I appreciate the fact that irrespective of what happened on the playground, if I was bullied, at home I knew it was secure. And I seek to have that same attitude twoards my children and everybody I consider my extended family, people at work, and so on and so forth. But once you've done that, you don't build your identity just to what people say about you. You're going to build your identity over what's done over a long period of time, okay? With, of course, if everybody in the world hates you, that's a tough place. That's happened to a few people in the world. I wasn't in that state at all. And as I came to this country, just got tougher because I was a minority in a place. But many of those lessons I learned as a young boy helped me as an 18 year old, as I came here, and I'm very thankful for that. >> And you came here with no money, alright? >> A scholarship. >> Right. >> Maybe 50 bucks in the pocket. >> You had 50 bucks and an opportunity, and made the most of it. And then obviously you did very well at Dartmouth. You graduated from Harvard, right? >> I did my MBA at Harvard. >> MBA at Harvard, probably met some interesting people there. >> Andy Jackson being one of them. >> I know he's a friend of yours. >> Sam Berg, who's the head of the client business, was also a classmate of mine at HBS. The '97 class of HBS had some accomplished people: Chris Kapensky is running McDonald's. She's President of US. So I'm very fortunate to have some good classmates there. >> So what did you do? Did you go right to Harvard from? >> No, I spent four years working at Apple. And then went back to do my business school. >> And then what'd you do after that? >> I came back to Silicon Valley at a startup. I was one of the founding product managers at AlphaBlocks. Then went to Informatica. And bulk of my time was at SAP, and most of my life was in the analytics, big data business. What we called big data at the time. >> And that's when we first met it. >> Analytics at BI, and then when Joe and Pat called me for this, the end-user computing role at VMWare four and a half years ago. That's when I came to VMWare. >> And that was a huge coup for VMWare. We knew you from SAP, and that business was struggling. You always give credit to your team, of course. Awesome. Which is what a good leader does. The other thing I wanted to touch on before we break is, you talked about leadership and how importatn it is to embrace cahnge. You said you have three choices when change hits you. What are those three choices? >> You either embrace it, okay? You either stand on the sidelines or you leave. And that's typically what happens in any kind of change, whether it's change in work, change in fafmilies, change in other kinds of religious settings, I mean it's a time-old prinicple. And you want to let the people who are not on board with it leave if they want to leave. The people who are staying in the middle and not yet convinced, you'll hope they'll do. But they cannot yet throw the grenades, 'cause then they're just going to be. And you want to take that nucleus of people who are with you in the change to help you get the people who sit on the sidelines in. And to me when I joined VMWare, the end-user computing team had the highest attrition, okay, and the lowest satisfaction. And I found the same thing. There were popel who were leaving in droves. Some people sittin' on the sidelines, but a core group of people I loved that were willing to really work with me, 'cause I didn't really know a lot about it. The smarter people were in the team and some people that we hired in. We had to take that group and become the chagne agents, and when that happens it's a beautiful thing because from within starts to form this thing that's the phoenix rising out of the ashes. And the company, and then these people who are sidelineers start to get involved. New people want to join. Now everybody wants to be part of the end-user computing team at VMWare because we're a winner, but it wasn't that way four and a half years ago. Same thing in cloud. How are we going to transform this cloud business to be one where, VCloudAir. We're being made fun of, like how are you ever going to compete with Amazon. We had to go through our own catharsis. We divested that business, but out of that pain point came a fundamental change. Some people left. Some people stayed, but I'm just grateful through all of this that we learned a tremendous amount. I think change is the most definitive thing that happens to every company, and you have to embrace it. If you embrace chance, it's going to make you a much stronger leader. I'll tell you, the Mandarin word, okay, for crisis is two symbols: one that shows disaster and one that shows opportunity. I choose the opportunity side. >> Dave: You choose? Right? Yeah! >> And eveyrone makes that choice, right? And if you make the right path, it could be a beautiful learning experience. >> Sanjay, words to live by. Definitely check out that video on Sanjay's profile. >> It's on LinkedIn. >> Really fabulous always to sit down and talk to you. >> Always a pleasure, Dave. Congratulations to all your success. >> Dave: Thank you! I really appreaciate your support. >> Thank you. >> Alright, everybody that's it from Dell Technologies World 2018. You can hear the music behind us. Next week, big week. We've got Red Hat Summit. I'll be at Service Now Knowledge. We got a couple of other shows and tons of shows coming up. I don't know, you were at Vmon last year. I don't know if you're going to be there this year, maybe maybe not, we'll see. >> Well we got a big one coming up at VM World. We'll see you there. >> We got big one coming up, VM World, at the end of August through early September, which is back at Mosconi this year? >> It's back at Las Vegas still. One more thing and then it's going back to Mosconi after the construction's over. >> So go to theCUBE.net, check out all the shows. Thanks for watching, everybody. We'll see you next time. (digital music)

>> Announcer: Live from the Computer History Museum in Mountain View, California. It's theCUBE covering DevNet Create, 2018, brought to you by Cisco. (techy music playing) >> Okay, welcome back, everyone. We're live here in Mountain View, California, in the heart of Silicon Valley for Cisco's DevNet Create. This is their new developer outreach kind of cloud, devops conference, different than DevNet their core, Cisco Networking Developer Conference is kind of an extension, kind of forging new ground. Of course theCUBE's covering, we love devops, we love cloud. I'm John Furrier with Lauren Cooney, my cohost today. Our next guest is Alex Ellis, project founder of OpenFaas, F-A-A-S, function as a service. That's serverless, that's Kubernetes, that's container madness. You name it, that's the cool, important trend, thanks for joining us. >> Yeah, thanks for having me, it's great to be here. >> So, talk about the founding of the project. So, you're the founder of the project-- >> Alex: Yeah. >> And you now work for VmWare, so let's just get this-- >> Yeah. >> On the record, so-- >> Alex: Yeah, I think this is-- >> Take a minute to explain. >> This is important just to set a bit of context now. I started this project from the lens of working with AWS Lambda as a Docker captain. I was writing these Alexa skills and I found that I had to hack in a web editor and click upload, or I had to write a zip file, put dependencies on my laptop, and upload that to the cloud every time I changed it. It just didn't feel right because I was so bought into containers. It's the same everywhere, there's no more, "It works on my machine." >> John: You're going backwards. >> Right? (laughing) So, I put a POC together for Docker Swarm and nobody had done it at that point, and it got really popular. I got to Docker Concourse Hacks Contest and presented to 4,000 people in the closing keynote, and I kind of thought it would just blossom overnight, it would explode, but it didn't happen, and actually, the months... We're going back 14 now, I grew a community and spent most of my time growing the community and extending the project. Now, that has been really fruitful. It's led to over 11,000 stars on GitHub, 91 individual contributors, and much, much more. It's been a really rich experience, but at the same time-- >> So, rather than going big rocket ship you kind of went, hunkered down and got a kernel of core people together. >> Alex: Yeah. >> Kind of set the DNA, what is the DNA of this project if you had to describe it? >> Yeah, so I think at the heart of it it's serverless functions made simple for Docker and Kubernetes. >> Great, and so how does Amazon play into this? You were using Amazon cloud? >> Yeah, I was using AWS and I was using Lambda, and that flow was not what I was used to in the enterprise. It wasn't what I was used to as a Docker captain. You know, I wanted a finite image that I could scan for vulnerabilities. >> John: Yeah. >> I could check off and promote through an environment. >> John: Yeah. >> Couldn't do it, so that was what OpenFaas aimed to do, was to make those serverless functions easy with Docker as a runtime. >> Well, congratulations, it's a lot of hard work. First, building a community's very difficult, and certainly one that's relevant. Cool and relevant, I would say, is serverless and functions. We'll certainly be seeing that now at the uptake. Still early on, but people are working on it. So, then now, let's forward to today. You work for VMWare, so-- >> Alex: Yeah. >> How did they get involved, are you shipping the project to VMWare, do they own it? Do you maintain the independence? What's the relationship between VMWare, yourself, and the project, if you can talk about that. >> Yeah, I think that's a great question. So, I got to the point where I had demands on my time around the clock. I couldn't rest, open source project, weekends, nights, the lot. >> John: You need the beer money, too, by the way. >> Right, yeah. >> You need some beer money. >> And I was working at ADP and just doing all of this in my own time, and then had a number of different options that came up and people saying, "Look, how are you going to sustain this, "how are you going to keep doing what you love?" You know, you should be working on it full time. One of the options that came up was from VMWare to work in the Open Source Technology Center. It's relatively new-- >> John: Mm-hmm. >> And the mission of the OSTC is to show VMWare as a good citizen in the community and to contribute back to meaningful projects, right, that relate to their products. >> Yeah, and they have good leadership, too, at VMWare. A lot of people don't know that. We did a couple CUBE interviews with them last year, and there is a group inside VMWare that just does that, not with the tentacles of VMWare and Dell Technologies in there. It's an independent group. >> Alex: Yeah. >> They probably go to some meetings and do some debrief, but for the most part it's kind of decoupled from VMWare, right. >> Yeah, right. So, the mission is not necessarily to make money and to produce products. It's to contribute to open source. Help with inbound so when we need to consume a project in a product, and outbound when we want to make the world a better place. >> So, I'm not going to put words in VMWare's mouth, but I will speculate covering VMWare since theCUBE started. We've been to every VMWorld and everyone knows we've got the good presence there, but if I'm VMWare I'm like, "Hey, you know what, we just "did a deal with Amazon, our enterprise "group is not so cloud savvy." I mean, the enterprise, there are operators, not true cloud native, but they're bridging that gap. The world of cloud native and enterprise is coming together. Does this project fit into that spot? Is that kind of where they saw it? Did I get that right or what was their interest other than doing-- >> Alex: Yeah. >> Helping the world out and solving world peace in the open source community. >> Yeah, so the mission of OSTC is slightly different. It's to contribute back to meaningful projects and to have this presence in the community. You know, I think OpenFaas is particularly attractive because it has such a broad community. There's people all around the world that are contributing to it, very active. For VMWare it makes a lot of sense because it runs natively on Kubernetes or Docker Swarm, and it's gained a lot of traction, people are using it. >> John: Mm-hmm. >> I had a call with BT Research before I came out and they said, "We've been using it for seven months. "We absolutely love it, it's transforming "how we're doing our microservices," and so I think that's part of it, as well as already have kind of a lead. Already have a lot of momentum with this project. >> So, are you looking to, you know, I know that the organization that you work for is really focused on driving this outbound, right? >> Alex: Yeah, yeah. >> Is VMWare using this internally as well? >> So, I think there's been a number of people who've shown an interest. You can think, "Right, there's a problem "we could solve with this," and I'm just getting my feet under the table, but really my mission is to make serverless functions simple to build this community-- >> Lauren: Mm-hmm. >> And to have something that people can turn to as an alternative. So, one of the things that I did in the talk yesterday was, "How do you explain OpenFaas to your boss," and one of the points there was to unlock your data. >> Lauren: Mm-hmm. >> And I think we talked about this briefly before, now with controversies recently about data and who owns it, what's happening with it, I think it's even more relevant that-- >> John: Yeah. >> You can have full control over the whole stack if you want-- >> John: Yeah. >> Or use a product like Microsoft AKS, their Kubernetes service-- >> Lauren: Mm-hmm. >> Or GKE and actually treat OpenFaas like a very thin layer of automation. >> Lauren: Really, okay. >> Or go full stack and have everything under your control. >> I mean, that's a great conversation to have, too, because obviously you're kind of referring to the Facebook situation. Zuckerberg's testifying it front of Senate yesterday, Congress today, and it's funny because watching him talk to senators in the US, they really don't know how stuff works, and so if you think about what Facebook does... I mean, granted they took some liberties. They're not the perfect citizen, they got slapped. They took it to the woodshed, if you will, but their mission is to use the data, and this is where cloud native's interesting and I think I want to get your reaction to this, you need to use the data, not treat it as a siloed, fenced in data warehouse. That model's old, right-- >> Alex: Yeah. >> It's now horizontal and scalable. Data's got to move and you've got to have data to make other things happen. That's the way these services are working. >> Yeah. >> So, it's really important to have addressability of the data and you know, GDPR takes an attempt at, you know, kind of hand waving that simple argument away. I'm not really a big fan of that, personally, but the role of data's super important. You've got to make it pervasive, so the challenge is how do you manage those controls. Is that an opportunity for functions? What's your reaction to that whole paradigm of data? >> Yeah, so we're talking about anonymous usage data, like Facebook situation or-- >> Just data in general... Oh, no, just data in general, if I'm an application and I have data-- >> Alex: Yeah. >> That I'm generating, same development of service-- >> Alex: Yeah. >> I need, you might want to leverage that data. So, I'm going to have to have a mechanism for you to share that data to make your service better-- >> Alex: Yeah. >> Because data makes data, you know-- >> Alex: Yeah. >> The alchemy side of it is interesting, but then there's all... You get trapped in regulation, licensing, it can be destructive. >> Yes, so as an engineer, and as an open source engineer, you find people that have no clue about what an MIT license is to a GPL or why you'd use one or the other. I think there's a lot we can do to educate the wider community and help them to learn the basics of these issues. When I was at university we had a course on ethics and legal issues and licensing, and I heard on the radio earlier on the Uber that they're starting to try and up the level of that again, and I think it really needs to start at a ground level. We need to educate people about these issues so that they're aware of how to handle the data. I mean, if you look at common tools like Docker and VS Code and Atom, popular editors, they collect anonymous usage statistics and you have to opt out. You know, should OpenFaas collect data as well, because it can be super helpful for us to know the right thing to do. >> Yeah. >> And when you come to open source you get no feedback until somebody wants support from you and it has to be done yesterday for free. >> Yeah, yeah, yeah. >> And so, yeah, getting data can be super powerful. >> Well, Alex, you bring up a great point. I think this is something that's worthy of an ongoing conversation. I think it will be, too, because GPL, Apache license, all these licenses were built when open source was a Tier 2 citizen, so the whole idea of these-- >> Alex: Yeah. >> Licenses was to create a robust sharing economy of code, and you know, with the certain nuances of those licenses. But just like stacks get updated and modernized with what we've seen the containers and now Kubernetes is serverless, the stack is changing and modernizing. The licenses have to, as well, so I think this is something that... I don't, I think it's kind of like we've got to get on it. (laughing) It's like I think we should just, this is a work area. It's not necessarily... It's game changing if you don't do it, right, because it could-- >> Yeah. >> It could flip it either way. So, to me that's my opinion. >> Well, I think you're under MIT, correct, is that-- >> So, it's under MIT right now. >> Lauren: Okay. >> One of the things that I didn't realize when I started the project is if you want to get into a big foundation like the Cloud Native Computing Foundation you need an Apache 2.0 license, and the main difference is that it offers some protections around patent claims, but it's basically-- >> Lauren: Okay. >> Compatible, so it is a minefield, and it's-- >> Lauren: So, that's just for the CNCF? >> Right, and the Apache Foundation, obviously as well. >> Lauren: Yes. >> And probably many others follow suit because I think it, we talk about the-- >> John: It's the dual source, it's the dual source. >> A refresh... >> John: Yeah, yeah. >> Right, it's a compatible license, it seems to help a lot of people. >> Lauren: Mm-hmm. >> That's a huge issue because you could be well down the road with committing code and then the lawyers will make you take it out. >> Right, so that's why organizations like the Open Source Program Office exist within VMWare, to help these issues and to monitor and do compliance. They may use software like Black Duck to check stuff-- >> Lauren: Yep, mm-hmm. >> Automatically because you don't want to be doing checks on your aircraft once it's in the air. >> Lauren: Mm-hmm. >> John: Yeah. >> You want to sort out everything out on the ground. >> You'll be grounding your fleet, that's for sure-- >> Right. >> When it comes to that, how do you handle that with licensing? How do you guys handle that when people contribute? >> Yeah. >> Are they aware of the license or they don't understand the implications? >> So, with OpenFaas we follow a model very similar to the Linux kernel, which is a sign off developer certificate of origin. What you're saying is I'm allowed to give you this code, I'm allowed for this to be a part of the project and I wrote it, I originated it. >> Lauren: Mm-hmm. >> And that's pretty much a good balance between a full contributor license agreement and nothing at all. >> John: Yeah. >> Lauren: Mm-hmm. >> But look, there's a lot of projects in this space right now. I don't know if you've noticed that, Kubernetes serverless projects. >> Yeah, I mean, it's a lot of really interesting, it's why I like this show here. I think what Cisco's smart to do here at DevNet Create is identify the network programmability, which really takes devops, expands the aperture of what devops is, so-- >> Alex: Yeah. >> You know, as you got new applications coming online some developers want nothing to do with the infrastructure. Kubernetes has got a much more active and more prominent role with layer seven primitives, for instance, or-- >> Alex: Yeah. >> Managing things down to the network layer. You're talking about policy services inside services on the fly, so this is really a big, a good thing, in my opinion. So, you know, I think, Kubernetes, most people look at as a kind of generic orchestration, but I think there's so much more there. >> Alex: Yeah. >> I think that to me is attracting some really rockstar developers. >> Yeah, well I think, you know, the fact that you are open, you're under the MIT license, which I am a fan of-- >> Alex: Yeah. >> And you know, it is, you're on a very successful trajectory in terms of, you know, what you're building and who's engaged and the fact that VMWare is behind you means that they're going to put some money into it, hopefully, and help you guys along as it works, but it is also a project that is not... You know, it doesn't have folks just from VMWare. >> Alex: Yeah. >> It's really, really diverse in terms of who's committing the code. So, I think there's a lot of things that are really going for you. Now, who do you see, you mentioned competitors... >> Alex: Yeah. >> So, can you talk a little bit about what the ecosystem there looks like? >> Yeah, so there's a number of projects that I think have made some really good decisions about their architecture and their implementation. They all vary quite subtly, and one of the questions I get asked a lot is, you know, how is this different from X, cubeless nucleo, and if you look at the CNCF landscape there used to be a very small section with OpenFaas, Lambda, and a couple of others. It's now so big it has its own PDF just about serverless, and I think that's super confusing for people. So, part of what we're trying to do is make that simple and say, "Look, there may be many options. "Here's OpenFaas, here's how it works. "You can get it deployed in 60 seconds. "You can have any binary or any programming language "you want and it will scale up over Kubernetes." We'll just make a really deep integration, give you everything you'd expect, really nice developer experience. >> Lauren: That's great. >> What are some of the use cases you see right now, low hanging fruit for developers that want to come in and get involved in the project? Have you guys identified any low hanging fruit use cases? >> So, what I've seen, and I talked about this a bit yesterday in the talk, is three big use cases, really. The first one was Anisha Keshavan at University of Washington. >> Lauren: Mm-hmm. >> Now, she's doing a lot of data science with neuroinformatics, medical images. She's able to take scans of brains and give them to people like you and me, who don't know anything about medical science. We just draw around the lesions and we train her model, and then she makes it competitive like a game, gamefies it, you get more points, but actually, what we're doing is making the world a better place by training her medical imaging database. >> Lauren: Mm-hmm. >> She'll then use that as an OpenFaas function to test real images as part of her postdoctorate. >> So, she's crowd sourcing, wisdom of crowds. >> Alex: Right. >> Collect some intelligence for her research. >> Now, one of the other things that I think's really cool is in the community we built out a project with two 17 year olds. Two 17 year olds built a really cool project, and when I think back to when I was 15, 16, I was playing with something like PHP on Windows Lamp Stack. You know, I had to do everything myself. >> John: Yeah. >> They got, like, this scaffolding built up and they could just go to the tenth story and just keep adding on. >> John: Yeah, yeah. >> And they didn't have to worry about managing this infrastructure at all. >> Or architecture, foundation architecture. >> Alex: Right, right. >> Yeah, and that's exactly the reason why you want to do that. >> So, they wrote some small blocks of Python that we found this machine learning code that could convert a black and white image to color, wrapped it in a box and said, "There's a function," then dropped it into OpenFaas and started feeding tweets in, and that was pretty much it. >> John: Yeah. >> Now we have @ColorizeBot, a bit of a strange spelling but you'll find it on Twitter, and it's been in Le Monde newspaper, all round the world. It was pronounced at CubeCon as well, and it's just a super interesting way of showing how you can take something very complex, right, and democratize it. >> Yeah, we'd love to get those people working for theCUBE and put the little cube box and throw all the tweets in there. >> Alex: Right, yeah. >> Alex, thanks for coming on, congratulations. What's next on your project, tell us what's going on, what's next for you, what are you guys conquering next? >> So, I'm really focused on growing the team and community. We've got an open recruitment position open right now and a small team that's building internally. I think the more people we can get contributing on a regular basis the more support there's going to be for the community, the more people are going to want to use this Actually had 26 people join a call last week. "How to contribute to OpenFaas," that was the name of it. >> Lauren: Mm-hmm. >> Around the world, and the best part for me was where we got to the testimonies and I had people just sharing their tips and experiences. How rewarding it is to contribute something bigger, something that you as a developer will actually want to use. >> Yeah, and the value opportunities, to extract value out of the group-- >> Yeah. >> It's phenomenal, functions as a service. Super relevant in cloud and devops as the middleware, if you want to call it that, expands more capabilities in devops are coming. It's theCUBE coverage here at DevNet Create. We'll be back with more live coverage here in Silicon Valley in Mountain View, California, after this short break. (techy music playing)

(Upbeat Music) >> Announcer: Live from Los Angeles, it's theCUBE, covering Open Source Summit, North America, 2017, brought to you by the Linux Foundation and The Red Hat. >> Hey, welcome back everyone, live here in Los Angeles, California for theCUBE's exclusive coverage of Open Source Summit in North America. I'm John Furrrier, with my co-star Stu Miniman, Our next guest is Patrick Chanezan, who is a member of the technical docker, also on the governing board of the Cloud Native Compute Foundation, also known as CNCF, which is the hottest part of the open-source community right now. It's very fast, we're very trendy, a lot of people are on the bandwagon, a lot of contribution going on. Welcome back to theCUBE. Great to see you. >> Hey, thanks, John and Stu, it's very good to be back on theCUBE. >> Docker's been just a great company to follow since the beginning, the birth of Docker to the transformation from Dark Cloud to Docker. It's just a great team. We have a lot of respect for you guys. Congratulations. But the CNCF right now is the hottest thing, there's more platinum sponsors than I think maybe members. It seems to be very hot. Industry loves it, developer is going crazy about it, why is CNCF so hot? What's your perspective on that? >> What we're seeing right now is really the realization of adoption of containers, we talked about it two years ago. It was very early, and people were starting to use Docker and just covering containers. Today they're really putting them into production, and what we see at Docker with our customer base is that they are using it more and more to modernize traditional applications. So we see tremendous use of containers everywhere in enterprises, and the rise of CNCF is tied to that, I think. We're seeing more and more developers joining the bandwagon, more and more systems being built based on containers. And at Docker, we're playing a big role into that. >> Patrick, for a couple years, the chant was Docker, Docker, Docker, and sometimes people say, "Cubernetti's is where the hotness is." Well underneath that, there's containers. And a lot of those containers, Docker's involved there. Maybe you can help us understand the nuance a little bit as the Cubernetti's wave has grown, sure there was the Mezos, Docker Swarm, Cubernetti's war, if you will there, but what does this mean for Docker? What are you seeing from your customers? Give us the update on Docker itself. We'll probably need to get into the Mobi stuff, too, as we get into the interview. >> Sure, definitely. That's a big question, so let's start with the beginning. When enterprises adopt containers, what happens is that usually it starts with the wrappers who are adopting containers with Docker. So they download Docker for their Windows machine, or for their Mac, or on Linux, they start modernizing their applications. What we see is more and more enterprising wrappers, modernizing existing applications by Dockerizing them, and then the next step is that they want to put that into production. For that, you need the whole system. So at Docker, we have two systems. We have Docker C and Docker E, our enterprise version that has role-based controlled sequencing and all that good stuff. There are lots of different components that you need in order to have a production container system, and so Cuberneris, the orchestration engine is one piece of that. At Docker, we have swarm kits. But there are lots of other different components and lots of different layers to that system. So you have the infrastructure layer that you are using to deploy that inside the firewall or in different cloud providers. Many different solutions there. At Docker, we have one that's called infrakit, that we're using in our additions, to deploy it everywhere. Then on top of that, you need some version of Linux. At Docker Con in April, we released a project called Linuxkit, which helps you do that. On top of that, you need a container run-time. Traditionally, it's been Docker. Right now, we re-factored the Docker codebase to extract a core run-time component that's called container G, which we donated to CNCF. Container G is nearing one or better, so it would be one of them pretty soon. Then, on top of that, you need an orchestration engine. Docker E comes with its own orchestration based on swarm, Cuberneris is another orchestration engine that people like. Cuberneris, behind the scenes, is using Docker, and right now we are working very closely with theCUBE rneris community to implement CRI container G. So CRI is the container run-time interface in Cuberneris that lets you plug in different engines to plug container G in the place of Docker in there. >> Stu: There's a lot of pieces in here. We had too many interviews yesterday talking about the Open Container Initiative, or OCI, which really made sure we've got the 1.0 version of that done. What container format, seems like we're in agreement. We're not fighting over that kind of piece anymore. From the Cubernetti's community, I heard loud and clear, they're like, we've got container D. We've kind of got what we want. We're happy it's open-sourced. We're going. We were at Docker Con when you annouced Mobi, which is kind of open-source, and it felt like we were still trying to figure out all those pieces. Give us the update as to Mobi, you're talking at the open source show, you talk a little bit about CE and EE being the productized versions, but part of it is what we used to think of as Docker is now Mobi, and the company Docker versus the project. You kind of teased those apart a little bit, right? >> Yes. Exactly. And actually, that's what I came here at the Open Summit to talk about, to give people an update on the Mobi project. So what we announced back in April was the launch of the Mobi project, which is the end of a two year re-factoring of the Docker codebase into different components. So all these components on the stack that I told you about, we just tease them out from the Docker codebase so that it's a modular set of components that you can assemble together. Mobi is three things. It's an open source project where people can collaborate in container-based systems. It's also a tool that we're using to assemble our components into Mobi Corp, which is the upstream of Docker products. Then it's also a set of lots of components, like container G, Linux, Infrakit, Notary, and all the projects I talked about. One other thing we've started doing since April as well is we started proposing to donate some of these container projects to CNCF. So container G is already part of CNCF now. Recently, this summer, we proposed Infrakit, and they think it's a little bit too early for donation, because they want to see other, different projects in there. Right now we're in the process of donating and proposing Notary, so there's an active discussion in there, and I hope that the vote will happen probably next week or something like that. So Notary is the component that we're using for Docker, and we think that this could be used in lots of different Cloud Native systems, so it really has its place in the CNCF. >> So identity component for the container management, or what specifically is that going to address? >> So Notary is the piece that we're using in Docker Con Contrast to make sure that you can trust the images that you've built. A signed signature should be able to revoke all the signatures, all the kind of features that our customers love in Docker E. >> John: It's kind of like Stu and me on Twitter, he's verified, I'm not. But this is important, because now, this is a stamp of approval, if you will, that the community can look to. >> Yeah, definitely. So it's something that we implement in Docker, and now people building other containment systems who will be able to use it. And so Mobi saw a lot of traction for its different projects, some of them are going to CNCF, some of them are growing by themselves. On the Docker side, we made some progress prioritizing all that with Docker C and Docker E. We had a 1706 launch of Docker E recently, with lots of new role-based axis control, controls for enterprises, who are adopting it essentially to modernize their traditional apps. >> Take us through a kind of personal question. You were just at a board meeting with the CNCF. Did everyone show up or are people calling in? >> I think Alexi Richardson was the only one, maybe two people on the phone. >> John: Was Sam Redjay there? >> Sam was not there either, but Epona was standing for him. So the room was full, and to me it's really an impressive achievement, two years after we helped start the CNCF. The first meetings were 10, 15 people at Google deciding to create this foundation, and today, maybe we're twenty or thirty people around the table. An\d everybody-- >> Even before that Google meeting, we were covering theCUBE Con Cubernettis' movement early on from your event. So I think, out of Docker Con and some of the Linux Foundation events, the early momentum, we were there, Stu. Then it became the CNCF, and they decided, hey, let's get the Cloud Native Foundation. So it's interesting to me, seeing the growth from the beginning. And it's unique to have that opportunity to be in the front lines of an organically developing group. It wasn't really build the table and come, this was a realization. >> It was a realization and also a concerted effort to build something together to show customers where the containment systems were going in terms of architecture-- >> What were the factors beside, I mean Docker was big driver. Notably, you should get the credit for pioneering the space. But what were the drivers for this coalescing, this call to arms, if you will, or this organic formation of CNCF. What were the key drivers in your mind. Obviously, containers is one. What are the other ones? >> Yeah, to me, containers is a big one, because when you are starting to design your system with containers in mind, you need to change lots of things, how you're building them and things like that. And how you are architecting things together. There were lots of questions about how you do the balancing in that kind of system, how do you do monitoring, how do you do tracing. The CNCF was assembled so that all these components have a place where we can show our inter-repairability between them. So Docker is part of that, Mezos is part of that, as well as Cuberneris. There's a big inter-repairability work that's happening in there. We had a report in the board meeting today about the new CI Initiative that tests different CNCF projects together. >> John: What CI? >> Sorry, continuous integration. >> John: Got it, yeah. >> So there's the continuous integration-- >> John: Not conversion infrastructure. >> Oh, you're right, yeah. >> We always get acronym-ed up. But Chris Anazik was talking yesterday about the graduation path, still waiting to see something graduate from the process. What's going to graduate first? Any bets, what's the betting, what betting is going on? Do you guys actually make bets? Is there a fantasy drafting going on? >> I don't think that really matters, what matters is really adoption of the components. >> Okay, so what's happening on the graduation scale? What's coming out of the woodworks? What's next? What's going to graduate first? >> So one thing I'm curious about is whether Container G will graduate, because it's kind of mature now, it's reaching 1-0 with the CRI and soon integration in Docker, it may be a good candidate for graduation. For the others, I don't know which ones would be first into the graduation process. >> Well, we know it's a high bar, for sure. >> Patrick, the stuff that's getting mature. What about some of the roadmap there? From Docker and CNCF, something like serverless containers, first generation, are going to be important. We had too many interviews this week talking about, today, many of the containers we'll see in the future where serverless and open Faz and things like that go. So how does that all fit in? Can you give us a Docker and a CNCF view on that? >> Let's talk about the CNCF view first. CNCF is working on lots of different areas where there needs to be more definition about what Cloud Native means for storage, for example, with the CSI Initiative, container storage interface, CNI, container networking interface, and then there's the working group for CI, which is about integrating all these projects together, but the working group I'm most interested in is the serverless one. So we have a Docker rep at the serverless working group, and there we're trying to define what a portable, serverless stack looks like. And at Docker, we're naturally interested in this -- >> Of course, Serverless is a beautiful thing. >> Most of these projects are running on top of Docker, so open Faz for people-- >> I got to ask you, Patrick, because we love serverless, I have a love/hate relationship with the word serverless because technically it's a beautiful thing, but there's servers involved. I'm an old-school, so I kind of look at it differently. The younger generation, they want infrastructure as code. This is a clear obvious thing. It was once a dream, but now it's become a reality. What's your position on that? Where is it on the progress bar? How close are we to serverless? >> I'd say there's an initial adoption of serverless on one of the few stacks that exist out there today. So you have the hosted services, the Faz services, from Amazon, Microsoft, and Google, where I'm more interested, and I think customers are kind of looking for that, is a portable way of doing that. For example, in studying that on top of Docker platforms, so that's what projects like Open Faz is doing. Right now, I think we're really in the stage of discussions with CNCF of what a portable service layer would look like so that you could focus on your code, but be able to deploy on Prim, on top of Docker, or in different cloud providers. So that portability aspect to me is very important there. And I think it's important for customers as well. To me, also, I'm an old timer as well, I used to pitch a platform as a service at the beginning of it, Google App Engine, many years ago. To me, it's kind of a feeling of deja vu. We're kind of re-inventing that, but with containers and in a much more portable way. >> The beautiful thing about being an old-timer is we get to look back and, not so much to the young kids, get off my lawn, we had to walk to school with bare feet in the snow, build our own libraries. I was just talking to Eilene, she's like, "Oh, my low-level class was C and my high-level class was Python." I'm like, "Our low-level class was machine code "and high-level wasn't even C yet." >> Yesterday, at the party, I was discussing with one of the IBM engineers, who's working on Linux and containers on mainframe, and we were talking about GCL, and that's the type of feeling that we got. Like we're getting higher up in the stack, and I think for modern developers, it really helped them-- >> It's a beautiful thing right now. Just think about the young guns that are coming up. This is a beautiful library of options now. 90% of the code is leverage-able. That's like unbelievable. So it really allows the creativity of the developer to be a lot more about structural engineering code-base rather than just being very creative on the 10-20% of real intellectual property that they can bring to the table. >> I would add something, it's really about creating value, as opposed to building infrastructure. When we're getting up the stack, and serverless is an example of that, it's really about creating value for enterprises, and that's what these wrappers are about. >> When you start dreaming in code, you know you're doing good. Patrick, thanks so much for coming on theCUBE, and congratulations on all the success with CNCF, and certainty Docker. You guys continue to impress and do a great job. I know there's some changes over there we're looking for, some of the cool stuff graduating out of CNCF, more Docker container goodness from you guys. Thanks for coming on theCUBE. We appreciate it. I'm John Furrier, we're live in Los Angeles, California, for the Open Source Summit North America coverage with theCUBE. I'm John Furrier, Stu Miniman back with more after this short break.

(mid-tempo music) >> Announcer: Live, from Los Angeles, it's The Cube. Covering Open source Summit North America 2017. Brought to you by the Linux Foundation and Red Hat. >> Okay welcome back and we're live in Los Angeles for The Cube's exclusive coverage of the Open Source Summit North America. I'm John Furrier, my co-host Stu Miniman, Our next guest is Steve Pousty, who's the Director of Developer Advocacy for Red Hat, Cube alumni, we last spoke at the Cisco Devnet Create, which is their new kind of cloud-native approach. Welcome Back. >> Thank you, thank you, glad to be here. >> We're here at the Open Source Summit, which is a recognition that of all these kind of ... With LinuxCon, all these things, coming events, it's a big ten event, love the direction, >> Yeah Validation to what's already happened and the recognition of open source, where Linux is at the heart of all that, Red Hat also you guys are the Linux standard, and gold standard, but there's more- >> We like to think of it that way, but- >> But there's more than Linux on top of it now, so this is a recognition that open source is so much more. >> For sure, I'm mean you can even see ... Who would've thought that there'd be a whole huge hubbub about Facebook doing a separate license for their react libraries and all the interactions with Apache, the Apache Foundation. Open source is so much ... it's the mainstream now. Like, basically, it's very hard to release a proprietary product right now and come up with some justification about why you have to do it. >> And why, and can it even be as good. >> Steve: Right. >> There's two issues, justification and performance. >> Yeah, quality, all that stuff. And also, customers' acceptability of that. Like, "Oh wait, you mean I can't actually even see the code? "I can't modify the code, I can't pay you to modify the code "and share it with everybody else?" I think customers have come to a whole ... Users of open source stuff, it's so permeated now that I think it's hard to be in the market without ... I mean, look at everybody who's here. Some of the people that are here were some of the biggest closed source people before. >> John: Microsoft is here. >> Exactly. >> John: IBM is here, although they've always been open, they were big on Linux early on. >> Yes. >> But now you're seeing the ecosystem grow, so we see some scale coming, but there's still a lot of work that needs to get done. We see greatness, like Kubernetes and Serverless offering great promise and hope for either multi-cloud workflow, workload management, all those cool stuff. But there's still some work to be done. >> Steve: For sure. >> What's your take on progress, where are we, what's the ... some of those under the hood things that need to get worked on? >> Well so, progress, I think ... the funny part is our expectations have changed so much over time that, so Kubernetes is about a little over two years old, and we're all like, oh it's moving so s-- why is it not doing this, this, and this? Whereas if this was like 10 years ago, the rate at which Kubernetes is moving is phenomenal. So, basically, every quarter there is a new release of Kubernetes, and we basically built OpenShift as a distribution on top of Kubernetes, and so we're delivering to our customers every quarter as well, and a bunch of them are like, "This is too fast, this is too fast, "like, we can't integrate all these changes." But at the same time, they say, "But don't slow down." Because, "Oh, next release we're going to get this thing "that we want and we know we want to go to that release." So, I think Kubernetes definitely has more growing room, but the thing is, how much it's already being seen as the standard, it's the ... so the way I like to talk about it, and I'll talk about this in my talk later, I think for Red Hat, Kubernetes is the cloud Linux kernel. It's the exact same story all over again. It's this infrastructure that everybody's going to build on. Now there are people who are standing up OpenStack on Kubernetes, or on OpenShift. So basically saying, "I don't want to install and manage "my Openstack, it's too difficult. "Give me some JSON and some components "and I'll just use Kubernetes as my operating plane." >> We saw Kubernetes right out of the gates, Stu and I, at the first Cube-Con, we were present at creation, and just on the doorstep of that thing just unfolded, and we saw the orchestration piece is huge, but I want to get your take if you can share with the audience, why Kubernetes has taken the world by storm. Why is it so relevant? What's all the hubbub about with Kubernetes? Share your opinion. >> Okay, so remember ... okay so this is a red shirt, and remember I work at Red Hat, so this obviously a biased opinion. I want to be up front about that. >> John: In your biased opinion ... >> Right, well as opposed to a neutral opinion, right, we definitely, so, I say that in front of my audiences just so that ... go do your own research, but from my perspective and what I've seen in the market place, there was a lot of orchestration and scheduling out there, then it kind of narrowed down, there's three players I would say right now. The three players all end with Kubernetes, but I just started with it (laughs). There's Kubernetes, there is Mesosphere, and there's Docker Swarm. I see those as being the three that are out there right now. And I think the reason we're ... So I won't talk about the others, but I see those ... Why Kubernetes has won is, one, community. So they have done a great job of being upstream, working with all people, being a very open community, open to working with others, not trying to make things just so it benefits Google's business but to benefit everybody. The other reason is the size of that community, right, everybody working together. The third is I think they, so some of it's luck, right? >> John: Yeah, timing is everything. >> Timing is everything. >> John: You're on a wave, and you're on your board and a big wave comes, you surf it, right? >> That's exactly, so I think what happened with Mesosphere is they're a great scheduler, and a lot of people said they were the best scheduler to start with. But they didn't really focus on containers to start with and it seems like they missed ... Like, Kubernetes said, "No, it's all about containers "and we're going to focus on container workload." And that's right where everybody else was. And so it was like, "I don't want to write "all that extra stuff from Mesosphere. "I want to do it with Kubernetes 'cause that's containers." And so that's the bit of luck lining up with the market. So I'd say it's the community but also recognizing that it's about containers to start with and containers are kind of taking over. >> Yeah, Steve, take us inside containers. You're wearing a shirt that says "Linux is Containers" on the front, if our audience could see the back it says "Containers are Linux." >> Steve: Exactly. >> Of course, Red Hat heavily involved. You're in the weeds, dealing with things that we're doing to make stability of containers, make sure it works in other environments. Tell us some of the things you're working on, some of the projects, and the like. >> So, some of the projects I'll be showing today, one is based off of OpenScap, Open S-C-A-P, it's another open consortium for scanning for vulnerabilities. We've written something called Atomic Scan, so it can take any OpenScap provider, plug it in to Atomic Scan, and you can scan a container image without having to actually run it. So, you don't actually have to start it up, it actually just goes in. The other thing I'm going to be talking about today is Bilda, this is part of the CNCF stuff. This is the ability to actually build a runC-compatible container without ever using Docker or MOBI. The way, a totally different approach to it, what you basically do is you say, "I want this container from this other container, or from blank," then you have a container there and then you actually mount the file system. So rather than actually booting a container and doing all sorts of steps in the container itself, you actually mount the file system, do normal operations on your machine like it was your normal file system, and then actually commit at the end. So it's another way for some of our customers that really like that idea of how they want to build and manage containers. But also, there's a bunch more. There's Kryo, which is the common runtime interface, and the implementation of it, so that Kubernetes can now run on an alternative container technology. This is Kryo, it's agnostic. If you looked at Kelsey Hightower's latest "Kubernetes and Anger," I think, or "Kubernetes the Hard Way" or something. His latest is building it all on Kryo. So rather than running on Docker, it runs ... All your container running happens on Kryo. I'm not trying to say, well of course I think it's better, but I think the point that we're really seeing is, by everything moving in to CNCF and the Linux Foundation and getting around standards, it's really enabled the ecosystem to take off. Like, TekTonic and CoreOS have done that with Rocket. We're going to see a lot more blossoming. The fertilizer has been applied, back from our ... >> Yeah, CNCF of two years old, I mean their fertilizer down big time, you got the manure and all the thousand flowers are blooming from that. >> Yeah, between Prometheus, I mean just, Prometheus, Istio, there's just ... I can't even keep track of it all. >> So Steve, you were talking earlier. Customers are having a hard time with that quarterly release. >> Steve: Yes. >> How do they keep up with all these projects, I mean you know, we rattled through all of 'em. You've got 'em all down pat, but the typical customer, do they need to worry about what do they have to focus on, how do they keep up with the pace change, how do they absorb all of this? >> Okay so it highly depends on the customer. There are some customers who are not our customers, I'll just say users, who are advanced enough on their own, who they're out there basically just, they're consuming the tip of what's coming out of CNCF. All that stuff, and they're picking and choosing and they're doing that all. For Red Hat, a lot of our customers are, "I like all that technology, you're our trusted advisor, "when you release it as a product "and I know I can sit on it for three years, "because you'll support it for at least three years, "maybe five years, then I'm going to start to consume it "and you'll actually probably put it into a more usable form for me." 'Cause a lot of the upstream stuff isn't necessary made direct for consumption. >> How are you guys dealing with the growth prospects. We've been talking about this all morning, this has been the big theme of this show is, not only just the renaming of a variety of different events, LinuxCon, but Open Source Summit is an encapsulation of all the projects that are blossoming across the board. So, the scale issues, and as a participant, Red Hat, >> Steve: Yes. >> Your biased opinion, but you're also incentive and you guys are active in the community. The growth that's coming is going to put pressure on the system. It may change the relationship between communities and vendors and how they're all working together, so again, to use the river analogy, there's a lot of water going to be pumping through the system. And so how's that going to impact the ecosystem, is it going to be the great growth that could flood everything, is there a potential for that, I mean you're an ecosystem guy, so the theory is there, it's like, Jim's stepping up with the Linux Foundation. I talked to him yesterday and he recognizes it. >> Steve: Yeah. >> But he also doesn't want to get in the way, either. >> Steve: No, no, no- >> So there's a balance of leadership that's needed. Your thoughts. >> So, I mean I think one of the things ... So I mean you know the Linux kernel has its benevolent dictator, and that works well for that one community, but then you'll see something like Kubernetes, where it's much more of a community base, there is no benevolent dictator for life on Kubernetes. I think one of the nice things that the Linux Foundation has done, and which Red Hat has acknowledged is, you know, let the community govern the way that works for that community. Don't try to force necessarily one model on it. In terms of the flood part that you were talking about, I think, if you want to go back to rivers, there's cycles in terms of 10 year floods, 100 year floods, I think what we're seeing right now is a big flood, and then what'll happen out of this is some things will shake out and other things won't. I don't expect every vendor that's here to be here next year. >> And find the high ground, I mean, I mean the numbers that Jim shared in his opening keynote is by 2026, 400 million libraries are going to be out there versus today's 64 roughly million. >> Steve: Right. >> You know, Ed from Cisco thinks that's understated, but now there's more code coming in, more people, and so a new generation is coming on board. This is going to be the great flood in open source. >> I also think it's a great opportunity for some companies. I mean, I'm not high enough in Red Hat to know what we're doing in that space, but it's also a great opportunity for some companies to help with that. Like, I think, that's one of the other things that Linux Foundation did was set up the Javascript Foundation. That is a community that-- >> But that doesn't have Node.js, it's a little bit separate. >> No, I know, but think-- >> You're talking about the js, okay. >> But I'm talking about, but if you think about the client-side javascript, forget Node. Just think about client-side javascript and how many frameworks are coming up all the time, and new libraries. >> Stu: That's a challenge. >> So I think actually that community could be one that could be good to maybe gain some lessons from, as things happen more in open source. I think there are other open source communities. Like, I'm wondering like GNOME-- >> But the feedback on the js community is that there's a lot of challenges in the volume of things happening. >> And that's coming for us though, right? >> Yeah. >> That's what's coming, that's what's going to come for this larger ecosystem, so I think maybe there's market opportunity, maybe there's new governance models, maybe there's ... I mean, this is where innovation comes from. There's a new problem that's come, it's a good problem. >> Your next point of failure is your opportunity to innovate. >> Exactly, and it's a good problem to have, right, as opposed to, we have too few projects, and we don't really, no one really likes them. Instead, now it's like, we've got so many projects and people are contributing, and everybody's excited, how do we manage that excitement? >> So another dynamic that we're observing, and again we're just speculating, we're pontificating, we're opining ... is fashion. Fashion, fashionable projects. Never fight fashion, my philosophy is. In marketing, don't fight the fashion. >> Steve: Right. >> CNCF is fashionable right now, people love it. It's popular, it's trendy, it's the hip new night club if you will in open source. Other projects are just as relevant. So, relevance and trending sometimes can be misconstrued. How do you guys think about that, because this is a dynamic, everyone wants to go to the best party. There a fear of missing out, I'm going to go check out Kubernetes, but also relevance matters. >> Yes. >> John: Your thoughts. >> So I've seen this discussion internally in engineering all the time, when we're talking about, 'cause you know OpenShift is trying to build a real distribution, not like, "Oh here is Kubernetes," but a real distribution. Like when Red Hat ships you the Linux, gives you Linux, we don't just say, "Here's the Linux kernel, have a good time." We put a whole bunch of stuff around it, and we're trying to do that with Kubernetes as well, so we're constantly evaluating all the like, "Should we switch to Prometheus now, "when's the time to switch to Prometheus? "Oh it's trending really hot. "Oh but does it give us the features?" >> John: It's a balance. >> It's a balance, it's going to have to come down to, I hate to say it-- >> It's a community, people vote with their code, so if something has traction, you got to take a look at it. >> But I would say, and this has been going on for a while, and I've seen other people talk about it, if you are the lead on an open source project, and you want a lot of community, you have to get into marketing. You can't just do-- >> John: You got to market the project. >> You got to, and not in the nasty term of market, which is that I'm going to lie to you and like, what a lot of developers think about like, "Oh I'm just going to give you bullshit and lie to you, "and it's not going to be helpful." No, market in terms of just getting your word out there so at least people know about it. Lead with all your-- >> John: Socialize it. >> Yeah. I mean, that's what you got to get it, so there is a lot of chatter now. How do you get it noticed as a Twitter person, right? You have to do some, it's the same, it's going to be more like that for open source projects. >> John: So we're doing our share to kind of extract the signal from some of the noise out there, and it's great to talk to you about it because you help give perspective. And certainly Red Hat, you're biased, that's okay, you're biased. Now, take your Red Hat off. >> Okay. >> Hat off. Take your Red Hat hat off >> Steve: Propaganda hat off. >> and put your neutral hat on. An observation of Open Source Summit, I'll see that name change kind of significance in the sense it's a big ten event. This event here, what's your thoughts on what it means? >> Hey c'mon Steve, you've got a PhD in ecology, so we want some detailed analysis as to how this all goes together. >> I mean it's good marketing, Open Source Summit, good name change, little bit broader. >> I'm actually glad for it. So, I've gone to some other smaller events, and I actually like this, because it was hard for me to get to the smaller events, or to get quite enough people. Like this actually builds a critical mass, and more cross-fertilization, right, so it's much easier for me to talk to containers to car people. 'Cause automotive Linux is here as well, right? >> John: You can't avoid it, you see 'em in the hallways, you can say, "Hey, let's chat." >> "Let's talk about that stuff," whereas in the small ... So, you know, this is more about conferences. There's a good side and a bad side to everything, just like I tell my kids, "When you pick up a stick, you also have to pick up the other end of the stick." You can't just like have, "Oh this is a great part," but you don't get the bad part. So the great part about this, really easy to see a lot of people, see a lot of interesting things that are happening. Bad part about this, it's going to be hard, like if this was just CNCF, everybody here would be CNCF, all the talks would be CNCF, it's like you could deep dive and really go. So, I think this is great that they have this. I don't think this gets, should get rid of smaller, more focused events. >> Well at CubeCon, our CubeCon, the CNCF event in Austin, we'll be there for The Cube. That will be CNCF all the time. >> Steve: Exactly. I'm glad they're still doing that. >> So they're going to have the satellite event, and I think that's the best way to do it. I think a big ten event like this is good because, this is small even today, but with the growth coming, it'll be convention hall size in a matter of years. >> Well, exactly, and the fact that you made it into a big, and the fact that you've made it into this cohesive event, rather than going to somebody and saying, "Hey, sponsor these five events." Like, No. Sponsor this one big event, and then we'll get most of the people here for you. >> It's also a celebration, too. A lot of these big ten events are ... 'Cause education you can get online, there are all kinds of collaboration tools online, but when you have these big ten events, one of the rare things is it's the face to face, people-centric, in the moment, engagement. So you're learning in a different way. It's a celebration. So I think open source is just too important right now, that this event will grow in my opinion. >> Steve: For sure. >> Bring even thousands and thousands of people. >> I mean, another way-- >> John: 30,000 at some point, easily. >> Yeah, I think definitely it's theirs to lose, let's put it that way. >> John: (laughing) I'll tell that to Jim "Hey, don't screw it up!" >> Don't screw it up. I think the way that you could almost think of this is OSS-Con, right, instead of Comic-Con, this is like, this can become OSS-Con, which is like, they should probably ... In the same way that the Kubernetes Foundation works and grows with a lot of other people, it would be great if they could bring in other Foundations as well to this. I know this is being run by the Linux, but it'd be great if we could get some Apache in here, some Eclipse in here, I mean that would just be-- >> John: A total home run. >> Those foundations bringing it in-- >> That would truly make it an open source summit. >> Yeah, exactly, as opposed to the World Series that's only in the United States. >> Yeah. (laughing) >> Although you know, I was at a hotel recently, and they had baseball on, it was little league baseball though. Their World Series is actually, Little League World Series is actually the World Series. >> John: It's a global World Series. >> Yeah, like their-- >> John: It's the world. >> Yeah, as opposed to the MLB, right? >> Alright, Steve, great to have you on, any final thoughts on interactions you've had, things you've learned from this event you'd like to share and pass on? >> No, I just think the space is great, I'm really excited to be in it. I'm starting to move a little bit more up to the application tier at my role at the company and I'm excited about that, to actually ... So I've been working down at the container tier, and orchestration tier for a while, and now I'm excited to get back to like, "Well now let's actually build some cool stuff "and see what this enables on the up--" >> And DevOps is going mainstream, which is a great trend, you're starting to see that momentum beachhead on the enterprises, so-- >> Oh, one takeaway message, for microservices people, please put an Ops person on your microservice team. Usually they start with the DBA, and then they say the middle person and the front-end people. I really want to make sure that they start including Ops in your microservice teams-- >> John: And why is that, what'd you learn there? >> Well because if you're going to do microservices, you're going to be, the team's going to end up doing Ops-y work. And it's kind of foolish not to bring in someone who already knows ... The reason you want all the team together is because they're going to own that. And you also want them to share knowledge. So, if I was on a microservice team, I would definitely want an Ops person teaching me how to do Ops for our stuff. I don't want to reinvent that myself. >> You got to have the right core competencies on that team. >> Steve: Yeah. It's like having the right people in the right position. >> Steve: Exactly. >> Skill player. >> Steve: Yeah, exactly. Okay we're here live in Los Angeles, The Cube's coverage of Open Source Summit North America. I'm John Furrier, Stu Miniman. More live coverage after this short break. (electronic music)

>> Live from San Francisco. It's theCUBE. Covering DevNet Create 2017. Brought to you by Cisco. >> Welcome back everyone. We're here live in San Francisco for theCUBE's exclusive two days of coverage for Cisco Systems' inaugural event called DevNet Create extension. DevNet their classic developer program, for the Cisco install base of network routers. Now going to the cloud, native, going to the developer where dev-ops and the enterprise are connecting. I'm John Furrier, my cohost Peter Burris. Next is Dan Kohn, who is the Executive Director of the Cloud Native Compute Foundation, CNCF. Formerly known as Kubecon. Which is the event, Kubecon.io. Dan, great to see you. Executive Director, how's business, is going good? >> Fantastic! (John laughs) Yeah, six months ago we chatted at our last event in Seattle. And it's just amazing to see the progress since then. Projects members. >> It's been a whirlwind. Even I can't keep track. You guys are announcing all these new projects. What's the current count of projects that you guys have under the Cloud Native Compute Foundation? >> So we're up to 10. I should definitely start with the fact that Kubernetes is the anchor 10 in our original project. In a lot of ways, foundation was setup around that. And that project is just continuing to do incredibly well. Where it's one of the highest velocity projects in the history of open source. In terms of number of authors, number of commits, poll requests, issues. But now we have a constellation of other projects that are in support of that one. It can be used in a lot of different ways. >> John: Yeah. >> That we've been adding in. >> We had Craig McLuckie on earlier. Now he's with Heptio. Again, when he was doing that work, at Google, back in the days with what's his name from Microsoft now. >> Peter: Brendan Burns. >> Brendan Burns, yeah. >> Now it's an interesting question, where you say, oh, wait a minute, the three sort of key people behind Kubernetes, Craig McLuckie, Joe Beda, who's his co-founder at Heptio, then Brendan Burns, they all left Google. Is this a bad sign for the project and the technology? >> John: No, I don't think so. >> And we would say it's a spectacularly good sign. Now, if they had left and said, ah you know, containers, I'm going to do virtual machines. But in fact they said, there's such an enormous market for this. And to have Microsoft and Azure step in and say, we really want to invest in this space and we want to bring on one of the co-founders, Brendan. And for the other two co-founders, say, hey Google is making a huge investment. But we also think there's an opportunity for independent venture funded startup. >> Craig is completely passionate about this because there is an interoperability ethos that's always been around the open web. >> Dan: Umhmm. >> And certainly open source has the same ethos. Cloud Native brings an interesting thing, and it's clear now to people that there's not going to be one cloud winning them all. >> It's a multi-could world. >> Dan: Right. >> How is the Cloud Native Foundation floating in the open source world? Is it gravitating towards more infrastructure, more edge, software edge? Are you guys kind of in the middle? Are you guys the glue layer? How do you view that? >> Sure. So one way of looking at what we're doing is, helping to build a stack of software. That allows you to run your applications either on bare metal in your own data center or on any of the public clouds. Or hybrid solution where you're mixing back and forth. But the key idea is that all the core parts of that are open source. They're supported by multiple different vendors. And what that means is, you get to avoid lock-it. So today, Amazon web services has some of the most extraordinary engineering. They have all these great services that make it very easy to go onboard. But if you build your whole architecture around that, then you're stuck with AWS forever. And when time goes up, time to renegotiate your contract in a year or two, you're back again and don't have a lot of leverage. Where we think AWS is fantastic platform to run Kubernetes, to run our other projects on top of. But we don't think you want to lock-in to those services to such a degree. >> Okay, when I'm on, first of all, pretend I'm Amazon, I'm a competitive strategist, lock-in, I got to get you locked-in. I'm just going to run Kubernetes on Amazon. Why don't I just do that? >> We think that's a great solution. >> John: You do? >> Heptio and lots other folks make it very easy to run Kubernetes on Amazon. But we also think you should at least look at Kubernetes on Bluemix, on Google, on Azure. And know that in the future when you're negotiation comes up, even if you never leave, you at least threaten to leave. That you're not locked into that one vendor forever. >> So if you think about how the cloud industry structure is starting to layout, you knew we were going to have IAAS. >> Dan: Umhmm. >> SAS has been around for quite sometime. >> Dan: Right. >> The big question is what happens with that platform as a service. >> The developer world. >> Dan: Yeah. Some people think it's going to end up in the IAS element. >> Dan: Umhmm. Some people end up in the SAS. If it ends up in the IAS, you got the lock-in. Do you see a world going forward where developers have their own place, where they go and build and create software independent of either target but then add it to the various platforms. Is that a direction that you think this is all going to end up in? >> I do. Our view is that Heroku, which really invented this platform as a service concept or popularized it. You do, get push Heroku and magically your application's up. And then Cloud Foundry which came along and created a open source version of that. Those were two building blocks. But the Cloud Native essentially taking that scenario and saying, hey, that continuous integration, continuous deployment pipeline, that ability to deploy your software dozens of times per day, that's an absolute table ante for being a modern company. Not just a software company but arguably every company today needs to be doing software development like that. And then Cloud Native is a whole set of infrastructure around that to allow you to, not just have that environment in development but also to push it into production. >> So compare and contrast, based on your vision >> Dan: Umhmm. >> of how things are going to play out. A developer spends her time today doing this, and in three years, she's going to spend her time doing that. Kind of give us a sense of how >> Dan: Sure. >> you think it's going to play out. >> The simplest way to say it is that, Docker came along a few years ago, and was incredibly transformative technology for software development. It solved this really basic problem that, you hire a new employee and does it take her an entire day or entire week to get her environment together. Or can she just copy over the document container and be ready to go. And so I would argue it had the fastest uptake of any developer technology in history. But now when you have all those pieces running, okay, that's great in development, how do you get it in production? And my goal is that in a few years, hopefully much sooner, that those developers that are getting the container, they're getting the different pieces of microservices working. And then it's this tiny little YAML file that just says, here's the requirements for my application, here's what kind of redundancy it needs, what is backend databases, other sorts of things. And they're deploying it up. For most developers they can get out of that business of dev-ops. Of having to worry about all those issues. Your dev-ops team can be so much more efficient cuz Kubernetes and the related platform really enables that. >> I got to ask you, I just Tweeted cuz I had, make sure I captured it. I'm blown away by your success on the sponsorship participation. And usually it's a sign of opportunity. Because there's money making to be made, having the big vendors in there. But the growth of Kubernetes as you mentioned, all the success, we're well aware of that. But you got a lot going on. You're like got the tiger by the tail, your hair's blown back, you're running as hard as you can. Why are you guys successful? What is your gut? As executive director, you got to have the 20 mile stare but you also implement the here and now. >> Dan: Sure. >> How are you rationalizing the success? >> The most important point is, there's not some sort of magic formula, that CNCF has done or the Linux Foundation. And we're just so much better promoting or marketing it. At the end of the day, it really comes down to the developers behind Kubernetes. They've built a tool that tons and tons of people want to use. And that leverages 15 years of work that Google has done on containerization. Work that IBM and Docker and all of our other member companies, RedHat, have put together. And now, I think tiger by the tail is the right analogy. That we just happen to be, luckily, do have the technology and the constellation technology that a lot of folks want to do. The biggest thing we're trying to deal with is, some of the challenges around scaling. There's over 17 hundred authors. Individual developers contributed to Kubernetes in the last 12 months. Trying to figure out how can we get good reviews of all their codes, better documentation. >> There is a secret formula if you look at it. In away, relevance is one of them. >> Dan: Umhmm. >> Being relevant and being an awesome technology. But what I want get your thoughts in is, I looked at Kubernetes right out of the gate and said, hmm, will this be a MapReduced moment for Google. >> Dan: Yeah. >> And interesting enough, they didn't pull the same move. They didn't just let Cloud Air, walk away with or someone. >> Dan: Right, exactly. >> They made sure that if they preserved it. Google kind of let MapReduced >> Dan: Yeah, I think-- >> on the side of the road. >> Dan: No, no, I think this-- >> Cloud Air ran with it. >> Google had something that they replaced it with. I mean the -- >> SPAN is pretty damn good. >> And that's an interesting thing because in a world of strategy, across technology, and this is related to this, is that it used to be, you define a process, and then let's call it the end level process, and then you would go off and you make it obsolete because you had something that was more efficient, more effective. And then you license the old technology. And that way, the industry built capacity around the old technology and you had the new, more efficient technology that drove your business forward. And I think that, I'm not saying that's exactly, I'm not saying that Google did that, that's the tremendous >> Google knew. >> effect it will have. >> John: I have sources that tell me that. I investigated this story three years ago or maybe four, maybe three years ago. Google had conversations going up to the Eric Schmidt level, and Larry Page level, do we keep Kubernetes, do we open source it? And it went all the way to the top. And they almost wanted, they were afraid of MapReduced. Because MapReduced was a lost opportunity. Now they made it up but-- >> Now I would argue that there's a slightly subtler decision they had to make, where they have this internal system board, that is just tons of engineering and analysis and improvement has gone into it. They wrote Kubernetes as essentially next generation version of that. I think they kind of had four paths. Craig McLuckie was one of the key people behind that. Where they could have made it a proprietary service that if you're a customer of Google cloud, you get access to it. That's essentially what Amazon and Elastic Container Services today. Or they could have said, hey, we're going to open source it but we're still keep control of it. Essentially that's the path they went with the Go language. Where lots of people use it, lots of people contribute to it, but it's Google who decides at the end of the day, which direction it goes. Or they could have gone and created a Kubernetes Foundation. And if they'd gone to the Linux Foundation and said, we want to create a Kubernetes Foundation, they absolutely could have and that would have been a home for it. But when you look at all the complementary technologies that have come in, they would never have gone into a Kubernetes Foundation. So instead, they really chose the most open path of saying, no we want to have a Cloud Native Computing Foundation. Have Kubernetes be the anchor tenant for it. But then have a place that companies like Mesophere with Mesos and Docker with Docker Swarm and other partners can come in and agree on something. So today, we're really pleased to announce the container network interface, just got accepted as our 10th project. And that's used by those and also by Cloud Foundry. And then they can disagree on others, about the orchestration- >> So it's a liberating move, really, if you think about it. Because at the time this happened, there was a lot of land grab talk going on. >> Dan: Umhmm. >> Until Amazon was winning big the hockey stick was going up. >> Dan: Right. You saw the numbers, and financial performance. But there was a fear of lock-in. To your point. >> Dan: Right, exactly. >> Then Kubernetes provides a nice layer. And you guys as a group, are looking holistically and saying, choice and multi-cloud. Is that the vision? >> Definitely. But, I mean you can see, strategically why Google decided to do it. Because if you pick an open source platform, and say, hey, this is the best of breed approach. Now, you're actually willing to evaluate the cloud on what the prices are, the supplementary services, et cetera. Where before that, you might have just said, ah, AWS is the safe service, I'm going just go with that. >> But Kubernetes is an invasive technology. And I don't mean that in a bad way. (Dan laughs) >> When you decide to move with Kubernetes, you are foreclosing other options at your disposal. And so, I think what you're saying is that, Google wanted to ensure that it remained a consistent coherent thing. While at the same time, making it obvious to all those around them that also wanted to invest in it, that their investments were going to be safe and sound going forward. >> I think that's fair but on the other hand, I do want to say that very few companies have moved their entire business and all of their IT over to Kubernetes. >> Peter: Oh, I'm not saying that they would. >> We do recommend that they start with a stable service. >> Peter: But Meso and some of those other companies are now investing in Kubernetes as a platform. Or making a bet on Kubernetes, want to make sure that their bets are as good as their company is. >> Sure. But there are other orchestration plateforms still. So Kubernetes has plenty of competition. And our biggest competition of course is Enertia. Of folks not changing into anything. >> I got to ask you a question. So Leonard, our producer is just telling me, Kubernetes is boring per Craig McLuckie. So Craig said earlier in theCUBE today, Kubernetes needs to be boring. He said his biggest problem with Kubernetes is it's too exciting right now. >> Dan: That's great. Now what he means by that is, he's kind of making a play on words but his point is, it should be obstracted away. >> Dan: Yeah. In terms of Kubernetes. But that's a problem you have. It's too exciting. >> Dan: Umhmm. What's your reaction to his comment that Kubernetes needs to be boring. >> He and I did a little Google trends comparison of Kubernetes and TensorFlow, which is another open source project out of Google. TensorFlow is something like three or four acts. And artificial intelligence is just so much more interesting and exciting. And yeah, I certainly would love to see a situation. We have this metaphor for Linux, with the Linux Foundation. That we describe it as plumbing. Where it's so intrinsic to almost every piece of technology in existence. And like plumbing, you'll get very upset when if it stops working. And you'll know it and you'll complain. But there's a huge piece of what we're trying to do which is the infrastructure to make things work. >> Here's an idea. Marketing idea. Just call it AI for containers. >> Dan: That's good. >> It'll be the hottest thing on the planet. >> Dan, great to-- >> Peter: Probably be more be more exciting. >> Dan, great to see you. Congratulations on your success. >> Yeah. So I do want to just make a quick mention December sixth through eighth is CloudNativeCon and KubeCon. It's our biggest annual conference. We're looking to actually triple in size from Seattle to three thousand people or more. We have every expert coming in. Michelle Noorali and Kelsey Hightower are the co-chairs and are going to be speaking there. We would love to see a lot of you guys. >> John: In Austin. >> In Austin. >> We hope you'll be there. >> TheCUBE will be there. >> We'll definitely be there. >> Dan: As well to ah, >> We've been to the inaugural >> Dan: Exactly. >> show for KubeCon and Cloud Native conference. We'll defintely be there. December sixth through the eighth, in December, in Austin. Great time of the year to be in Texas. Congratulations on all your success. And as Kubernetes and nine other projects continue to get traction. Still exciting times. And as they say, we live in interesting times. (Dan laughs) This is theCUBE with more interesting, exciting, not boring stuff coming back from the inaugural event here at Cisco DevNet Create. I'm John Ferrier, Peter Burris. Stay with us.

>> Voiceover: Live from Austin, Texas. It's the Cube, covering DockerCon 2017, brought to you by Docker and support from its Ecosystem partners. >> Hi, I'm Stu Miniman and joining me, my co-host, for the second day of theCube's program, Jim Kobielus. Really excited to have, not only the founder of Docker, Solomon Hykes, he's also the CTO, Chief Product Officer, did some keynotes here, all over the place. So, Solomon, thank you so much, thanks for havin' us. Congratulations on all the progress and welcome back to theCUBE. >> Thanks a lot! It's a lot of fun! >> So many things to talk about, but let's start with you. How ya doin'? I'm sure there's so much that went into this week. What are you most proud of? What are you most excited about these days? >> Where to start? The cool thing, for me, about DockerCon is I focus on the keynote. We just package up the nice story, try to explain what we're doing, where we're going, and that's a pretty massive team effort. I think it's 30 of us for months preparing, deciding what we want to talk about, working on demos, pulling all-nighters. It's just really fun to see a keynote go from nothing to a really nice, fun story. Then I get to show up and discover all the other cool stuff. I'm like everyone else. I just marvel at the organization, the crowd, the energy. I'm a happy camper right now. >> It's interesting some of the dynamics in the industry. Okay, what's the important part? Who contributes to what? What fits where? Two years ago we had the hugging out as to the runtime and had the Open Source Foundation step in. Big thing at the keynote yesterday, two big things: it was Moby project and Linux Kit. Can you, maybe, unpack for our audience a little bit? What is Docker, the company? What's the Open Source? Who are some of the main players? It was the whole keynote, so we don't have time to get into it. What's real, and what was there? >> You're right, that was the big announcement, the Moby Project. Basically, in a nutshell, we launched Docker and we made it a product and an open source project, all rolled into one. We just kind of adopted this hybrid model, building a product that would just help people be more efficient, developers and ops, and at the same time, we would develop that in the open. That really helped us. It participated in the appearance of this huge Ecosystem. It was a big decision for us. Over time, both grew. Docker grew as a product, and it grew as an open source project. So over time we had to adapt to that growth. On the open source side that meant gradually spitting out smaller projects out of the main one. Now we have dozens of projects, literally. We got containerd. We got SwarmKit. We got InfraKit. We got all these components, and each of those is a project. Then we integrate them. What we're doing now, is we're completing that transformation and making sure there's a place for open source collaboration, free-for-all, openness, modularity, try new things, move fast, break things maybe. Then there's the product that integrates, takes the best parts, integrates them together, makes sure they're tested, they're solid, and then ships that to developers and customers. Basically we're saying, Moby is for open source collaboration. It's our project and all of it. And Docker is the product that integrates that open project into something that people can consume that's simple. It's two complementary parts to our platform. >> Could you talk a little bit about, there's kind of that composable nature of what you're building there. There's what Docker will build from it, and I think you've got a couple of examples of some of your partners. What's going to happen in the Cloud? What's going to happen with some of these others? Walk us through one of those. >> Everything about Docker's modular. So really, if you installed Docker for your favorite platform, whether it's the Mac, Windows, your favorite Cloud provider, Linux server, etc., you're actually installing a product that's an assembly of lots of components. Like I said, these components are developed in the open and then they're assembled. Now with the Moby Project, there's a place to assemble in the open, start the assembly in the open, so that other companies, the broader Ecosystem, can collaborate in the assembly, kind of experiment with how things fit together. The really cool thing about that is it makes it way easier to ports the platform, to expand it and customize it. So if you're a Cloud provider and you see all the pieces and you think "Well, I could optimize that. "I could add a little bit of magic "to make it work even better in my Cloud or in my hardware." Then you can do that in the open. You can do that with a community. Then you can partner with Docker to test it, and certify it, and distribute it as an easy-to-use product. Everything can go faster. >> You mentioned open a lot there. Does that mean that Docker is now closed? There's certain people that are very dogmatic when it comes to open source, so maybe you can parse that for us. >> I think it's the same people that were complaining before that we were confusing our product and an open project. We think of ourselves as having a lot to learn, and there's an Ecosystem that's made of a lot of people and companies and projects that have had a lot of experience with openness in the past. We spend most of our time listening, figuring out what the next step should be, and then taking that next step. People told us, "Clarify the relative place, "open source collaboration and your product." That's what we did. Now, I'm sure someone's going to say, "I preferred it before." Well, we just have to, at some point, chose. The key thing to remember is, Docker does everything in the open, and then integrates it into a product that you can use. If you don't like the product, if you want an alternative, then you still have all the pieces in the open right now. I would say, no. Not only is Docker not going closed, we're actually accelerating the rate at which we're opening up stuff. >> Personally, I felt it was a nice maturation of what you've done before, which was batteries are included but swappable. But we've taken the next step. It reminds me of those cool little science kits my kids get. Where it's like, oh okay, I could free build it or I can do it or I could do some other things. >> We use that tagline. It used to be, Docker has batteries included, but swappable. You can make other batteries and we'll swap them in to the product. We'll decide what's in there. Now everyone can do the swapping. It's a big free-for-all. Honestly, it's fun to watch. >> Is there any piece of Docker, the project, outside of core Docker, that Docker the company will refrain from building, will rely on ISVs to build? Or will Docker the company get involved, or reserve for itself the latitude to get involved in development of more peripheral pieces of the overall project going forward? >> We spent a lot of time thinking about that. Honestly, there's so many different constraints, we just decided we're going to follow the users, follow the customers. We just want a platform that works and solves people's problems. That's the starting point. From there, we work out the implementation details, what technology to use, the order in which to build things. Also, what makes more sense in the core platform and what makes more sense as an add-on. It's kind of on a case-by-case basis. >> Is there a grand vision document or functional service layered architecture that all of these components of the project are implementing or enabling? In other words, will Docker, as a project ever be complete or will it always be open-ended, will it constantly evolve and possibly broaden in scope continuously, indefinitely? >> If you look at the Moby Project on the one side, with experimentations and all the building blocks, I think that's going to just continuously expand. Really, openness is all about scale. There's only so much one company can build on their own, but if you really show the Ecosystem you're serious about really welcoming everybody and allowing for different opinions and approaches, then, honestly, I think there's no limit to how large that project can scale. I think Moby can go into tens of thousands of contributors as open source becomes easier and more accessible, which we're really working on, I think it can go into hundreds of thousands. That's going to take a while. That will, I think, never end growing. I think Docker, the product, the company, the reason we've been so successful is that we've been, well at least we've worked really hard to focus and be disciplined in what problems we want to solve, so it's a more iterative approach. We would rather solve less problems, but solve them really, really well, so that if you're using Docker for developing or going to production, you're really delighted Just every detail kind of fits together. There's a roadmap, of course. We're going to do more and more. But we don't want to rush trying to do everything. >> Solomon, great progress on all of these pieces. I've got the tough one for you. In the last year or so, Kubernetes has really exploded out there. Lots of your Ecosystem is heavily using it. Is it that Docker Swarm and Kubernetes will just be options out there? I look at Microsoft Dasher and they're very supportive of both initiatives. Many of your partners are there. How do you guys look at that dynamic and how would you like people to think of that going forward? >> It's a great case study of why we're transitioning to this open project model with Moby. The whole point is that at any given time, Docker, the product, will not be using all of the building blocks out there. It's just not possible. There's too many permutations. So we have to chose. One of these building blocks is orchestration. A year ago when we decided to build an orchestration, we had really specific opinions on what it should look like, as product builders. We looked around and we decided it needs to be a new kind of a building block. So we built Swarm Kits for our own use and we integrated it. Now that there's an open project for elaboration, we're throwing Swarm Kit in there so that everyone can modify it, extend it, and also replace it with something else. I think the big change, now, is that if you look at something like Kubernetes or Rocket as a container on time. Honestly, I could make a super long list of all the components out there that are really cool and we don't use in Docker. Now you can combine them all in Moby in custom assemblies. And we actually demoed that on stage yesterday. We showed taking some pieces from Docker and taking Kubernetes as a piece and plugging it together and saying "Look, there you go! "Weekend project." I think we're going to see a lot of conversions and reuse of ideas and codes, especially in the orchestration piece. I think over time, the differences between Kubernetes, Swarm Kit, and others will really diminish. We'll just integrate the bits and pieces that make the most sense. I don't really think of Kubernetes as a competitor or a problem. I think of it as another cool component in the Moby Ecosystem. Yeah, I think it's a lot of cool stuff. >> I tell ya, the Kubernetes community is just so thrilled that containerd is now open source. It really solves that issue and really it hasn't been something I've heard a lot, coming into the show. It's one of the themes we wanted to look at, and it hasn't been something that is like, Oh boy! Fight, war, anything like that. Hey! Congrats on that! I want to turn back to your root there. I think about dotCloud to Docker. It's a lot about the application modernization. Fast forward to today, Ben's up on stage talking of the journey. How do we take your legacy applications and wrap them in? What do you think about that kind of progression? We like that spectrum out there to help customers, at least partially, and be able to make changes. But I can't imagine that's when you started Docker that that was one of the use cases that you really thought you'd use. What surprised you? What's changed how you built things? What do you see from customers? >> Actually, you'll find this surprising, but this actually was a use case that we had in mind from the very beginning. I think that was lost in the noise for the first few years in the life of Docker because it became this exciting, new thing. >> Come on, Cloud native, Cloud native! >> Yeah, exactly! Docker has a huge developer community now. We spent a lot of time making it great for devs. The truth is, I used to be sysadmin. I used to be on call. I'm an ops guy first and we learned how to help developers. Developers are the customer. The Docker came out of our ops roots and then it evolved to help the developers. That's something that's now lost in the noise of history. It's a really pragmatic tool. It's built to solve real problems. One design opinion we baked in from the beginning is that it has to allow you to do things incrementally. If Docker forces you to throw away what you have, just to get the benefits, then we screwed up. The whole point is that Docker can adapt to what you're doing. For example, you'll see a lot of details in how Docker's designed to allow for stateful applications to run in there, to allow for your own network model to fit. Before Docker, all the containers solutions, all the paths, required you to change your app. Even things like port discovery. You had to change the source code. Docker did not require that. It gives you extra things you can do if you want to go further. But the starting point is incremental. Honestly, I'm really glad that now that's resonating, that we're reaching that point in the community where there's a lot of people using Docker interested in that, because for a few years I was worried that that would be missed in the noise of early adopters that don't mind rewriting everything. From the beginning, Docker was not just for Cloud-Native, microservices, Twelve-Factor, etc. I'm, personally, as a designer of products, as a pragmatist, I'm just happy that we're there. >> How do you see Docker evolving to support more complex orchestrations for data? For hybrid data cloud, environments private and public? You got the likes of Microsoft, Oracle, and IBM as partners and so forth. They have these complex scenarios now, their customers or petabytes scale and so forth. Where do you see that going, the data, the persistence of storage side of the containerization under Docker going? >> I think there's a lot of work to do. I think over time we're going to see specialized solutions for different uses of data. Data has such a big word. It's like computing. Just like computing now is no longer considered one category but it's specialized, I think data will be the same. I think it's a great fit for this modular Lego approach to the Docker Ecosystem. We're going to see different approaches to different data models, and I think we're going to see a lot modularization and a lot of different assemblies. Again, I think a lot of that will happen in Moby and we'll see a lot of cool, open stuff. We, ourselves, are facing a lot of data related questions, in request for customers. There's stuff in there already. You've got data volumes. And I think you're going to see a lot more on the data topic in the next year. >> Like containerization of artificial intelligence and deep learning and all that. Clearly, that's very incognito so far because, yeah. >> We're seeing a lot of really cool machine learning use cases using Docker already. OpenAI is all on Docker. We watch what they're doing with great interest. >> Are you a member of that consortium? >> Let's say friends and family (laughs). So OpenAI came out of the Y Combinator Ecosystem and Docker is a Y Combinator company. We spend a lot of time with them. I think AI on Docker is a really cool use case. I'm a big fan of that. >> Jim: Cool! Us too! >> Solomon, unfortunately, we're runnin' low on time. Last question I have for you is, there is so many things we can do with Docker now. Here's a bunch of the use cases like, "Oh, I can run lots of applications." Everything from Oracles in the store now, things like that. What is the quick win when you're talking to customers and let's get started? What's the thing that gets them the most excited that impacts their business the fastest? >> Ya know, it's-- >> And it never comes down to one thing, but, ya know. >> Honestly, we keep talking about Lego. I think it's like asking, what's your favorite Lego toy? I think we're maturing in the model. I think Lego is just the perfect analogy because it's a lot of building blocks. There's more and more, but there's also the sets. I think we're consolidating around a few different sets. There's maybe a dozen main use cases. We're seeing people identify with one, and then we're helping them see a starting point there. Here's a starter set for your problem, and then it clicks. >> Yeah, I hear that, and I can't help but think back. You're the big green platform that all my Legos build on. I can have my space stuff. I can have my farm set. Maybe the Duplos don't quite fit on it. It's the platform helping me to modernize a lot of what we're doing. Solomon Hykes, always a pleasure to catch up. >> Likewise! Congratulations on all the progress here, and we look forward to catching up with you the next time! We'll be back. Jim and I will be back with lots more coverage here from DockerCon 2017. You're watching theCUBE. (electronic music)

(calm and chill electronic music) (moves into upbeat and energetic electronic music) >> Announcer: Live from Austin Texas, it's theCUBE. Covering DockerCon 2017. Brought to you by Docker and support from its ecosystem partners. >> Welcome back. I'm Stu Miniman with my co-host and singer and, you know, lyricist everyone once in a while, Jim Kobielus. >> Partner in crime. >> And happy to bring back to the program Giorgio Regni, who is the CTO of Scality. So good to see you again. >> Hey. Hi Jim, Hi Stu. Very nice to see you again. >> So Giorgio, I interviewed you at Amazon Reinvent. So we talked about where you fit in the cloud environment. So here at DockerCon, you bring us up to space. You're a software defined storage company, where do containers and Docker fit into the offering that you have? >> Absolutely. So with software defined storage for the enterprise, one of our goal is to simplify storage operations because it's hard to actually build a verified scale system, how can we make it easier for our customers to use, right? And one other thing that containers give us is the ability to easily package your software and deploy it anywhere. For example, we have options. Where do you want your interface to be for storage? Should it be on the client side, should it be on the server side, should it be somewhere else? With container, it's very easy to automate. And one container can do a lot of things, right? So, it's pretty easy. >> Yeah. And talk about how scalability fits into your environment. My understanding is you work with Docker Swarm, do you also work with Kubernetes? Where does that fit in? >> So we talk about an announcement we made today. Just before I do that, just a quick. So the container, we follow the imagable container design. So when you have a container, you can kill it any point in time, right? And another container will take over. So there's nothing in our architecture that's a single point of failure. So with Docker, it's very easy to do. Which we did before, but Docker simplifies all these operation aspect for us. >> Alright. And so the announcement is, did you also do Kubernetes then, or is it just the Docker Swarm right now, or? >> Yeah, so there is a container automation war. We haven't picked a side yet. >> Okay. (Giorgio chuckles) >> Yeah, absolutely. Talk to us about your customers. How much is it a pull for them, asking you about containers? How much? Is it just something your building it to your architecture because it makes sense going forward? >> So we work with very large enterprises. They don't know what the other department is doing. So sometimes you talk to a storage team and they try to tell you we never deploy containers. But then if you talk inside a company, you will see that another group has deployed containers for the last two years in production, and they actually have a support contract with Docker, they have an enterprise deployment. And so you have to find out is there Docker experience. And 99% of the time, there is Docker experience. >> Stu: It reminds me of Linux a lot. >> Yes, exactly. >> You know, 15, 10 or 15 years ago, you talked to a big group, "Are you doing Linux?" and they got no, and they're like "Wait, "Bob's been doing Linux a bunch." And we are doing it and everything. (Giorgio chuckles) So yeah, absolutely. >> Giorgio: It is the same thing, yeah. >> And this been such a huge explosion of what's been happening. You know, I've talked to some of the vendors here that have been working with containers for, you know, eight, 10 years almost. But with Docker, it's really helped, ya know, just bring it to the masses. So, yeah, can you maybe speak to how its changing your environment as CTO, how it influences your vision of the future? >> Yeah, so as a CTO, it allows us to go from the development platform of a laptop of developers to via simple one server deployment for our open source versions, but can start on any VM or any one machine, down to a distributed system with thousands of servers and hundreds of petabytes. And it's all the same container. So the flexibility is huge. And for continuous delivery, continuous integration platforms that we have, being able to use the exact same code from a laptop workstation to the actual deployment improves quality a lot. >> Alright. And Giorgio, the keynotes today talked about a lot of open source things there, there's the Moby Project, there's Linux kit. You know, are you guys involved in any of the open source? How are your customers, you know, embracing open source these days? >> So Dockers, we're using a lot of software. We can not take everything and bring it to enterprise. You know it's not, we're a software company that sells products, so we don't actually also own platform. It's our customers. So we need to go a little bit slower. So Docker is faster than ever with these new features. But that means that official (mumbles) that was released last year, like Swarm, now is ready to be used in production for all customers. And so that brings me back to the announcement from today. So the last time we talked in Las Vegas our open source was new and we had $50,000. Now we have $250,000. So in less than six months I think its four month and a half we added $200,000. And one of our reasons for that is that it's so easy to use it with Docker. And then people in the community were telling us that they need to be deployed in a, you know, a (mumbles) fashion, so being able to lose a machine and continue having the storage working, which makes sense, but not at the scale of a wing. Not at a scale of our multi petabyte systems. So something in the middle. And so we tried to look at developing our own automation, our own fault tolerance, and we said "Wait a minute. Docker is doing that." They built Docker Swarm, that does exactly what we wanted to do. So can we use that? So our videos from today is you can actually deploy our storage system using Docker Swarm, so if you come online, it will automatically be fault tolerant. If you lose a machine, it will start from another machine. And it all works, load balance automatically. And with security as well because communication can be unencrypted. So it's all of these benefits. By just using Swarm, we don't have to code anything. So we'll follow up on that. >> Giorgio, Solomon talked about this morning. Docker will be where you want it to be. So you know, on premise, in the public cloud, around. You talk a little bit, you know, your software, the breath of support you have. We talked to you at AWS, think you guys support Azure. What's driving you to certain environments, what are your customers doing, and what is that breathe that you guys offer? >> So a lot of things that Solomon said resonate with our customers. So one things is that you don't want to be stuck with one platform. You want the liberty to be able to pick and choose and change. And so storage is very sticky, so if you have a petabyte somewhere, it's going to be hard to move. But what you can be sure is the next year, it's going to be two petabyte. So when the extension comes in, you want to be able to select your hardware vendor for private, but also for public. What about if you could decide the next four petabyte go on Google Cloud Compute and the next five petabyte go on Azure so that you're not stuck with any of them. And so what we are realizing, but first we need to talk about that, is the ability to deploy your SV service, so our objects, your service, and target within some instance multiple storage backend. And it can be local, so local volumes, drives on your machine, very simple stuff. Maybe even a NFS, ZFS mount point works as well. It can be public using AWS. And we're adding Azure and Google Cloud Compute. So the same S3 code base can actually give you different location, and the location can be hybrid, local, private, public, you name it. >> Another key focus that Docker talked about, especially in the open source community, is security. Can you can speak to how security fits into your environment? Anything in your announcement that enhances the security pieces? >> Yes. So there is a lot of key management to be done. So access keys, identification key, SSL keys. And each vendor is going to build their own. They're trying to think about their own ways to actually store this sensitive information. With Docker, we haven't done it yet, but what Solomon said, there wasn't any keys there. What about if you use Docker as your security identification provider, so it takes one shop for everything else? And this is something I am going to look at. We haven't implemented it yet, but I'm going to look at it. The other thing that was said, I think it was in it, but that is portability. So we developed our own identification engine called Volt, which actually implements via Amazon IM interface, so an identity and access management. So it's pretty standard. But if you use Volt, the same identification taken for local will work on AWS. It will also work on Azure and also work on Google Cloud. So as an IT admin, I can just use mine to deactivate, connect it to a security Volt. And if a user leaves a company I can just delete it from a directory and it will disappear from all the clouds in one big portable transparent way. So yeah, this is kind of the things we look at as well. >> Jim: With multi level access control and roll based. >> So groups, roll based-- >> The delegations and so forth? >> The delegation is in there as well. So it's a big bet. Last year we decided to implement IM, which nobody else has done. And it pays off a lot because a lot of our customers are banks, insurance companies, and they need that level of security. Alright? It's a big advantage. >> Now Giorgio, one of the big things that's been talked about for the last six months or so is how things like IoT are really going to drive edge computing. I think back to the early days of object storage and I am curious how that whole development fits into what you're doing and how you think about storage. >> So we're looking at IoT very closely. There's a lot of volumes, but with volumes arrived after the data has been crunched, you got some sort of consolidation, right? And the object storage is perfect for material. So lets say we daily start a VH with very precise granularity. Then it get compressed into some kind of time service data. And this keeps very well in object storage. For the edge storage itself, I don't think there is a solution today. And there's no standard as well. So I'm looking at this and seeing what was going to happen. But I think object storage are great for for storing all of the archive but not good for the real time IoT data. But I'm still looking into what standards are going on in the archives. >> You have federated object storage for the fog, ya know, and the IoT. >> It's both a database type workload and object storage, so it's fascinating. But there's no answer yet. I don't think so, unless you guys tell me you've seen it. (laughs) >> Jim: I'm not aware of it. >> Okay Giorgio, so you've got the announcement. What other things can you tell us Scality, what's going on this week? Have you had any customer conversations this week yet that have stood out to you? >> Yes, we have a few partners at DockerCon, so it's great to be able to meet them here. I'm also looking at automation. So Docker Swarm is one, Swarm kit, but there's also Kubernetes and Mesosphere. They are all here this week, so I'm going to talk to them. And HP, which is one of our partners, is here too, so we're going to talk about this as well. And I need to find some time to understand the security model we talked about. >> Alright, well Giorgio, we really appreciate all the updates here. Want to give you a final word on what's exciting you. You talked about some of the partner things, but anything else you would want people to take away from this show? >> Yes. So I think the hybrid model for storage makes a lot of sense because you don't want to be stuck to a provider. And I was just going to say that in a few months, so in June, we're going to make a big announcement. And that will show that with Scality, you can leverage any cloud and automatically like manage your data on multiple providers. And we're going to give a hint of that next week at NAB. Where I'll be presenting a large customer of some of the prototypes that we've been working on. >> Well Giorgio Regni, really appreciate you to talk to you again. We'll be back, wrapping up day one of Docker Con 2017. You're watching theCUBE. (calm and chill electronic music) >> Thanks for watching theCUBE.

>> Announcer: Live from Austin, Texas. It's theCUBE, covering DockerCon 2017. Brought to you by Docker, and support from its ecosystem partners. (bright electronic music) >> Welcome back. I'm Stu Miniman, joined by Jim Kobielus for two days of theCUBE's live coverage, DockerCon 2017, here in Austin, Texas. We are the worldwide leader in live enterprise tech coverage, happy to welcome to the program, a first-time guest on theCUBE, happens to also be a local here in the Austin area, so Dustin Kirkland, the Ubuntu Product and Strategy, with Canonical, thanks so much for joining us. >> Thanks, Stu. >> All right, so Dustin, give us a good thumbnail, what's your role, and how excited are you to be at another local show. All the open source shows seem to be here in Austin. I mean, we love doing it. >> I'm super glad. >> Dustin: We love sharing Austin. Glad for people to come and visit. Just make sure you go home at the end of it. (chuckles) >> Jim: Keep Austin weird and keep it open. >> That's right, that's right. Yeah, it's great to be local, it's great to have the Docker community back in Austin. It was, a lot of these people were here for OpenStack. We'll be back for CubeCon later this year. OSCON in between. >> All right, and tell us a little bit about your role. >> Yes, so I lead Product and Strategy at Ubuntu. We make an operating system that runs in the cloud, on public clouds, private clouds, bare-metal, physical servers, down to desktops and embedded devices. >> Okay, so, I have a serious question for you. Every time we see the surveys of OpenStack, the surveys in the public cloud, Canonical's always there. I mean, everybody's using your stuff. >> Dustin: Good! >> But where are people paying money for it? What's kind of from the business standpoint, maybe you can give us the quick update on that. >> People pay money when it's mission-critical. When Ubuntu and OpenStack and soon, Kubernetes, certainly more and more, Docker, when that's part of the mission-critical infrastructure, they pay for that. They pay the support and the services, they pay for consulting, for design, for leads, for architecture. They pay for access to the product roadmap, and so we do have some really brand-name customers who pay us good money for that. >> Okay, it's our third year doing theCUBE at this show, and every year, it seems we come in with one of the same questions, which is like, all right, is this ready for production, is anybody using it? We backed you to knock down the doors of everybody here, and give us more customers to talk to, so, what do you see, what's your answer to that? >> Yeah, I mean, it strikes me as really odd when people are still asking, "Are containers ready "for production?" Containers have been part of our DNA in Ubuntu for almost 10 years now. Shipping an OS that boots into a container that's able to run LXD containers, Docker containers, and run those at tremendous scale. We'd run containers underneath as the control plane of every OpenStack cloud we've ever deployed, every Kubernetes cloud we've ever deployed, every Hadoop cloud we've ever deployed. So containers are part of our production system. >> So do you guys have a marketing term? You guys are the hipster Linux container company. You were doing it before it was cool. >> I guess so, I mean it's, I guess, it's like asking, and I wonder, you think cellphones are mainstream yet? It's like, yeah, it is now, but you're probably one of the first in your family to have a cellphone, right? It's, we're kind of at that juncture, where we've been doing for a long time, and it's good to see others finally taking advantage as well. >> In the keynote this morning, we talked, we saw a lot about the maturation of Docker. They really started out working with the developer, they've really grown, working with the business, working with the enterprise. Talk to us about your customers as it fits into the container space in general, Docker, specifically. What are you guys seeing? >> As an operating system that delivers the latest and greatest open source software across multiple architectures, public and private clouds, Docker fits into that very well, in fact. It sits alongside LXD at giving that machine container, replace your VM's experience, but also the new way of writing applications. Solomon talked about applications, and if you're going to develop an application, Docker is a great application development platform. So when applications are being developed, (mumbles) or microservices, from scratch, Docker is a fantastic approach, and we see more developers using Ubuntu desktops and Ubuntu in the cloud, as that development platform. As that matures, then we get into a situation where it becomes mission-critical, and then we have really interesting commercial discussions around how do we really help that platform succeed? >> All right, we just Microsoft on the program. >> Dustin: John, right? >> Yeah, John was on, talks about, (mumbles) Microsoft is talking about being open, Microsoft's talking about choice. They actually talked, John mentioned, your company and your operating system. When we get to cloud solutions, Canonical's supported everywhere. How do you guys differentiate? How do you make sure that they're choosing your product as opposed to something else? >> So Ubuntu itself, always latest and greatest. It's fresh, you're never more than six months away from the next latest and greatest everything across the board. You're never more than two years away from an LTS, a long-term support release. That's really the key differentiator for Ubuntu is its freshment, its velocity, and that maps very well to the container world, where things are revving very, very quickly. >> All right, security was a big focus this morning also. What's your viewpoint as to where security lives, how that works with all of your environment, and what you guys do for that-- >> I've been a security nerd for most of my career. In fact, it's one of those jobs you leave but you always kind of get sucked back into because you care about it, honestly. Ubuntu as a platform, security, we take very seriously. Encryption anywhere, we can use encryption, updates, latest and greatest updates, kernel patches, Livepatch for the kernel. (coughs) Livepatch for the kernel is particularly interesting from a security perspective because it enables us to address security vulnerabilities without rebooting systems, and that's really important in a containerized environment, where you're not just running one or two machines, you're running potentially thousands of machines or containers or applications, and being able to update one single kernel with a Livepatch, without rebooting any of them, that's what security people are excited about when we talk Ubuntu kernel and security. >> (mumbles) Ubuntu being deployed into Internet of things, or to what extent is your roadmap going in that direction 'cause we're seeing a lot of new development going into the Internet of things, to deploy artificial intelligence and deep learning algorithms and data, down to the edge, and so-- >> Yeah, it's beautiful, I mean, that edge-to-cloud story is something that we've got a very clear view on. We produce an OS, an Ubuntu OS called Ubuntu Core, is a read-only operating system custom-tailored for IoT devices. That's the OS, it's the same Ubuntu but rolled and managed and updated in a different way. Applications fit onto that device in the form of snaps, or Docker containers, frankly. They're a little bit different in the way that they're implemented, but we have a new packaging system that's well-adapted, well-tuned-- >> A snap is more, something different from a container, how? >> It is, it's a form of a container. It's less than a container, but it uses some of the same container primitives. It's, frankly, it's an archive and a set of security profiles that wrap that tarball, essentially, and the way it's executed in a very secure manner, so it's wrapped with AppArmor profiles, it only has access to certain parts of the system, it contains its own dependencies, but they're contained in such a way that they're protected from the rest of the system. A lot of that sounds like Docker, and it is similar to Docker, but Docker provides a little bit more of that machine experience. Docker will include a file system, it'll draw an IP address sometimes, or defroute traffic, whereas a snap actually runs directly on the underlying OS. It's more tightly linked to that OS. In terms of linking back to the machine learning, that happens in the cloud. Inevitably, IoT drives more cloud adoption because those little IoT devices, they've got so little processing power and storage by design, that information needs to go somewhere, and it goes to the cloud, where something like a TensorFlow, running in a Docker Swarm, or a Kubernetes, or some combination of those two, are really crunching the interesting problems. >> First, Google recently made a big to-do about federating more of the machine learning algorithms all the way to the edge device, so, the world is going in that direction but I hear you. That's, they're very constrained-- >> Dustin: We hear a lot about the edge. >> To run the algorithms that pull power on the edge device, but it's coming. >> Yeah, for sure. >> Great. >> Stu: All right, so Dustin, I heard Kubernetes and Swarm, you guys, agnostic to that, support all of it. >> Dustin: We are. >> What do you guys code on, what do you hear from customers? >> Yeah, so we're very proud of our position here. I'm here at DockerCon, supporting Docker. Docker Inc. is a close commercial partner of Canonical. We, Canonical is authorized to resell Docker Enterprise Edition, Docker services, Docker support. We've got mutual customers who buy that directly from Canonical, and we support Docker and Swarm and Datacenter on top of Ubuntu, and that's a great story that brings us from the developers who are running Docker on Ubuntu on their Macs and Windows machines. John, I'm sure, was talking about Windows and Docker. But when they put that into production, we've got the wherewithal to support that. We offer Kubernetes as another platform. I've spoken with some really bright, just last night, with a really bright cloud architect from a major Internet service provider, and their role is they set up Docker Swarms for their internal customers, and Kubernetes Clusters for their internal customers, and Cloud Foundries, and OpenStacks, all inside of this big telco Internet cable giant, and it makes sense, and they can do all of that, and do all of that on top of Ubuntu, because it's the platform that can offer whatever they need for their customers. >> All right, one of the other announcements in the keynote this morning was LinuxKit, so, I got a little bit of a preview before the show, and I don't feel that it was Docker trying to punch at the providers of Linux, and it didn't seem to come off that way in the keynote, but for those that hear at a glance, oh, wait, LinuxKit developed with a bunch of, you know, seems like mostly hardware companies plus Microsoft and Docker. What do you guys see, how do you look at that? >> It's genuinely fun for an open source engineer to put together a Linux distribution. It's like the thing you want to do, and customize it and tailor it, and the beauty of open source is you can absolutely do that, and so, what I saw from LinuxKit, I too got a little preview, it seems it comes out of the part of Docker that also works on unikernels, Alpine, to an extent, and they've built a container-optimized, or Docker-optimized OS from Docker, so if you want Docker all the way down, it sounds like LinuxKit is a solution that they're working on, still working on. I'll say that Ubuntu, containers are in our DNA, we built a kernel and we built a security system around containers for quite some time, and we continue to optimize that, and we work directly with Microsoft, Google, Amazon to ensure that the Ubuntu that's running in those public clouds is ready to run Docker and other container systems out of the box, and very consistently, in a way that looks exactly like the Ubuntu that's running as the bash shell on the Windows desktop, as the Ubuntu desktop itself, as the server that you might run in any one of the public clouds. It's a very consistent experience. We do tune that and tailor that, but it's in ways that ensures portability. >> All right, so Dustin, you talked about kind of the history and how long people have been using it. Production should not be a question. It's just where, what, how you're doing this. What things do you still see us needing to mature, or what excites you about this going forward? >> Yeah. The management, honestly, and that comes back to security. Ensuring that running those containers at scale, you're doing that in a secure manner. Minimal is part of it. We hear that quite a bit, that, "I want a minimal image, I want a minimal host." That is an important part of it. It's, we have to be a little bit careful that we don't go so minimal that we end up creating a bunch of snowflakes, special unicorns where every container image is a little bit different, every host is a little bit different, because it's more minimal than the previous one. That actually creates more security problems, so I think thinking that problem through is, it's one of the most important problems that I think through, or I'm working on right now, and I think others are interested in working on as well. >> All right, Dustin, you've been way too pleasant through all of this interview, so before we end up, as an Austin local here, I have to ask you the divisive question. Your favorite barbecue place. (Dustin groans) >> You know-- >> Jim: Your favorite bar band, too. Keep going. >> Okay, yeah, I mean, you can't go wrong with the award-wining Franklin's barbecue or the gas station Rudy's, we love those. My favorite's a little hole in the wall out close to where I live. It's a trailer that's been serving barbecue out of that trailer since 1997. It's called Bee Caves barbecue. Those guys, they put together some fantastic barbecue five days a week. They sell it until they're out, and then they close up the shop and they go fishing, and it's, you got to get there early, and when they're done, they're done, so I-- >> Yeah, is there a connection between people that make barbecue and people that put together Linux distributions? It sounds like a lot of the same thing. >> Maybe so, maybe so, yeah. I've got a smoker out back. I like to smoke meat as much as I can. >> Absolutely, all right, well, Dustin, really appreciate you joining us. Welcome to the >> Stu, thank you, Jim. >> Stu: CUBE alumni list now, and we'll be back with more coverage here from DockerCon 2017. You're watching theCUBE. (bright electronic music) >> I remember--

>> Announcer: From the SiliconANGLE Media Office, in Boston, Massachusetts. It's theCUBE. (upbeat music) >> Hi everyone, I'm Sam Kahane with senior WIKIBon analyst, Stu Miniman and you're watching theCUBE. In 10 minutes or less, we're going to teach you everything you need to know about DockerCon 2017. Here's the agenda, we're going to start with the basics, what is DockerCon and why you should care. Then we're going to discuss the maturity of the container ecosystem. After that, we're going to talk about Docker as a business. And then we're going to finish by talking about the users, and what they should look for at the show. So real excited to have Stu Miniman with me, he is our DockerCon expert. Stu, how many years have you been at the show? >> So Sam, it's the fourth year of DockerCon. It will be my third show, also the third year we've had theCUBE. I was at the first one in 2014. Super exciting show. Everybody got all hyped up for a couple of years, we just Docker, Docker, Docker everything. And then from the second year on, we've done the North American show. Maybe we'll do the Copenhagen show later this year because Docker will be back in Europe. But super exciting, going to do two full days of live coverage from Austin, Texas and you'll be joining us. >> I will be, and who will you be hosting with? >> So John Furrier will be there. John and I host a lot of the open source shows. John's known DockerCon since that first 2014. It was actually at a Red Hat Summit, we interviewed Solomon Hykes, who's the founder of Docker, the company. And so much history we can't get through all of it in the, under 10 minutes, but super excited for the container ecosystem, everything that's going on. It's still been a bubbling and exciting area. >> So you've seen this show grow. Let's talk a little bit about the maturity of the Docker Ecosystem. >> Yeah so, as you said, there's so much history here Sam, there's the little D, Docker, which is the open-source project itself. And big D, the company. So let's talk about containers in the ecosystem. So while Docker didn't create containers, Docker is the company that really has democratized it for the world. So reminds me a lot of VMware. So VMware didn't come up with the idea for virtual machines, which actually goes back to the mainframe era. But they helped bring it into the PC world. And in the same way, Docker is really taking this container format which had existed in a couple of other operating systems and it takes that Linux container which is how we look at bundling things really at the application layer, making it really simple, usually ties into, a lot of people talking about how microservices fits into it. A lot of these new frameworks are leveraging containers. So containers are maturing. And some of the problems that we've had in the past with infrastructure, how does it work with infrastructure? How does things like storage and networking work? The community in the container world have been knocking those down. And Docker, the company has also been knocking those down. So containers are definitely maturing, it's definitely something that in many ways we've gone through the peak of hype, through a little bit of the trough of disillusionment, if you follow the normal hype curve. And today, containers are being used in a lot of ways, we still want to see is how many companies are actually fully using containers in production environments. Is it all stateless storage? Is there stateful storage? There's lots of start-ups, lots of big companies, everything from, heck, Microsoft just bought a big company, Deis. Which if you look them up, oh, it's in the container ecosystem. We'll talk about the competitive piece at the end. Every cloud today is talking about containers in there. So, containers are here to stay, they're an underlying foundational piece of what's happening kind of in the infrastructure and application world. And so, DockerCon, is really the center place for a lot of us to gather and talk about that. >> Great, so this is Docker show. How is Docker doing as a business? >> It's interesting, we had a couple of, it's been some struggles over the last couple of years as to, reseparating containers and Docker the open source, versus Docker the company. Last year, there was a little bit of air sucked out of the ecosystem when Docker said, oh well we have this way to manage lots of containers called Docker Swarm. Docker Swarm's great, it's pretty simple, it works well. But when Docker said, when you buy our solution, it comes bundled with it. Also, people were saying, well, I might prefer to use Mesos, I might want to do Kubernetes. We've covered Kubernetes, really cool stuff, with CubeCon show that we've done, itself. So Docker's like, well, the old term was batteries are included but swappable. But the community kind of bristled at a lot of that. What I like is that Docker has done some repackaging. They now have two flavors that you can get of the Docker solution. There's Docker CE, which is the community edition, which is the free open source. Releases are coming like every six weeks, that could be tough for a lot of people. And how much? Do I just take it and use it? So Docker understands that they want to bring this to the enterprise, so they created the EE, or enterprise edition, which has release cycles that fits with the enterprise more. It has really the service and support that you kind of expect there. It reminds me lot of anybody that's been in this space. You look at what happened in the Linux world, you look at what happened with VMware, and their maturation over time. And we see Docker kind of moving in that general direction, but it still remains to be seen. We go to the show, last year, Docker Swarm, some people got frustrated as to what Docker put together. What will Docker announce this year? Will they take on a piece of the ecosystem where people are taking dollars? Or where are the dollars and how the customer consume, are some of the big questions that we look at. >> What are the competitive dynamics here? >> Yeah, so Sam, I mentioned containers are fitting in everywhere. Every note that I get from cloud players here, it's kind of assumed that there's containers underneath. When you go to Amazon show, Google show, Microsoft show, containers are there and Docker is in a big way. Most of the cloud services that are put together, have Docker, there's great partnership. Docker with Amazon. Microsoft actually created containers for Microsoft. People were like, oh my god. I looked at it and said, this is probably going to take three years. Microsoft moved faster than I ever thought they would, to be able to make, I can have Linux containers, and I can have the Windows containers, and I can actually manage them together. They're not swappable, they're still two different formats but Docker supports, has support and has worked on both of those. It was amazing to see. Google is greatly involved in containers and Docker's there. And of course, I can do on-prem solutions also. Competitively, the big question is, who makes money? Because all of these cloud players, whether you're IBM, Amazon, there's pieces of the pie that they're going to take. So where can Docker actually get a footprint, that big D Docker? Because there's lots of companies that I talk to that say, oh yeah, we're using containers and I use the Docker format. But maybe I'm only using the registry from Docker. Or, oh wait, IBM has a registry, Microsoft does registries, everybody has that. Where am I actually coming to Docker, the company? And I think as we see kind of that CE and EE that I mentioned earlier, play out, Docker does have an opportunity there, but it's an interesting competitive dynamic. There's always that given push from the ecosystem as to Docker built a big ecosystem and did they eat parts of it? AHLA, Intel in the past, even VMware has done some of that. Or can they live amongst that and make a good living because they're UNICORE? I think they were over a billion dollar in valuation when they had less than 10 million dollars in revenue, which is just one of those astronomical Valley things that you look at. But containers are all over the globe, huge adoption of the project itself. And it's going to be great next week to get the pulse from everybody as to where they are, where they're winning, and what customers are doing really cool things with that they couldn't do before they had containers in general and Docker specifically. >> Yeah, so speaking of the show, it's going to be the biggest DockerCon to date, I'm very excited for that. The users and the community that's at the event, what should they look for? >> Yeah so, the first thing is, let's look to our peers. What customers are going to get on stage? Are these, one from the Valley? Or kind of the web 2.0 companies, that you're like, oh yeah, that's interesting but people want to see the financial services companies. People want to see retail companies. Where are they using containers? Were they using it in production? What kind of use cases are they doing? How have they rewritten, changed their businesses to take advantage of this? Because the business can only move as fast as their applications are, and Docker is one of those things that can really help accelerate that pace of change and move people along. Hearing from users, hearing from that update, hearing that Docker is doing well, understand what their future is, understand where they fit into the ecosystem, I think is one things that we want to kind of take away from that show. >> Right. And if you're not at the show, you can watch theCUBE. So we'll be broadcasting on Tuesday and Wednesday. We have some great guests coming on from Cisco, Canonical, Red Hat, Scality, Logz.io, AppLariat, even more companies. Any interviews you're really excited for? >> Yeah so, first of all, some of the Docker executives, we get Solomon Hykes on. Is Solomon the benevolent dictator of the Docker community? You know, or he's the founder of Docker, so he's great. Ben is the CEO of the company. Jerry Chen, is the one who invested in it. And as you mentioned, we've got a bunch of the vendor ecosystem. Big thanks to our sponsors that allow us to broadcast from that show. Hoping to have a few users on. We always get in some of the keynote people, some of the other guests. Any practitioners that are out there, that are willing to tell their story, we always appreciate when they can reach out and talk to us. >> Great Stu, thank you so much. That's all the time we have today. Watch us next week, Tuesday and Wednesday, full days of coverage from DockerCon. And come by theCUBE on Wednesday, we're going to have Franklin Barbecue at 1:00 p.m. (upbeat music)