(upbeat music) >> Kubernetes is maturing for example moving from quarterly releases to three per year, it's adding many of the capabilities that early on were avoided by Kubernetes committers, but now are going more mainstream, for example, more robust security and better support from mobile cluster management and other functions. But core Kubernetes by itself, doesn't get organizations where they need to go. That's why the ecosystem has stepped up to fill the gaps in application development. Developers as we know, they don't care about infrastructure, but they do care about building new apps, they care about modernizing existing apps, leveraging data, scaling, they care about automation look, they want to be cloud native. And one of the companies leading the ecosystem charge and building out more robust capabilities is Red Hat. And ahead of KubeCon Spain. It's our pleasure to welcome in Stu Miniman director of market insights at Red Hat to preview the event, Stu, good to see you, how you been? >> I'm doing awesome, Dave. Thanks for having me, great to be here. >> Yeah. So what's going on in Kube land these days? >> So it's funny Dave, if you were to kind of just listen out there in the marketplace, the CNCF has a survey that's like 96% of companies running Kubernetes production, everybody's doing it. And others will say, oh no, Kubernetes, only a small group group of people are using it, it's already probably got newer technologies that's replacing it. And the customers that I'm talking to Dave, first of all, yes, containers of Kubernetes, great growth growth rate, good adoption overall, I think we've said more than a year or two ago, we've probably crossed that chasm, the Jeff Moore, it's longer the early people just building all their own thing, taking all the open source, building this crazy stack that they need to had to do a lot of work we used to say. Chewing glass to be able to make it work right or anything, but it's still not as easy as you would like, almost no company that I talk to, if you're talking about big enterprises has Kubernetes just enterprise wide, and a hundred percent of their applications running on it. What is the tough challenge for people? And I mean, Dave, something, you and I have covered for many, many years, , that application portfolio that I have, most enterprises, hundreds, thousands of applications modernizing that having that truly be cloud native, that that's a really long journey and we are still in the midst of that, so I still still think we are in that, that if you look at the cross in the chasm that early majority chunk, so some of it is how do we mature things even better? And how do we make things simpler? Talk about things like automation, simplicity, security, we need to make sure they're all there so that it can be diffused and rolled out more broadly. And then we also need to think about where are we? We talk about the next million cloud customers, where does Kubernetes and containers and all the cloud native pieces fit into that broader discussion. Yes, there's some maturity there and we can declare victory on certain things, but there's still a lot, a lot of work that everyone's doing and that leads us into the show. I mean, dozens of projects that are already graduated, many more along that process from sandbox through a whole bunch of co-located events that are there, and it's always a great community event which Red Hat of course built on open source and community projects, so we're happy to have a good presence there as always. >> So you and I have talked about this in the past how essentially container's going to be embedded into a lot of different places, and sometimes it's hard to find, it's hard to track, but if you look at kind of the pre DevOps world skillsets like provisioning LANs, or configuring ports, or troubleshooting, squeezing more, server utilism, I mean, those who are really in high demand. If that's your skillset, then you're probably out of a job today. And so that's shifted toward things like Kubernetes. So you see and you see in the ETR data, it's along with cloud, and RPA, or automation, it is right up there I mean, it's top, the big four if you will, cloud, automation, RPA, and containers. And so we know there's a lot of spending activity going on there, but sometimes, like I said, it's hard to track I mean, if you got cloud growing at 35% a year, at least for the hyperscalers that we track, Kubernetes should be growing faster than that, should it not? >> Yeah, Dave, I would agree with you when I look at the big analyst firms that track this, I believe they've only got the container space at about a 25 per percent growth rate. >> Slower than cloud. But I compare that with Deepak Singh who runs at AWS, he has the open source office, he has all the containers and Kubernetes, and has visibility in all of that. And he says, basically, containers of the default when somebody's deploying to AWS today. Yes, serverless has its place, but it has not replaced or is not pushing down, slowing down the growth of containers or Kubernetes. We've got a strong partnership, I have lots of customers running on AWS. I guess I look at the numbers and like you, I would say that I would expect that that growth rate to be north of where just cloud in general is because the general adoption of containers and Kubernetes, we're still in the early phases of things. >> And I think a lot of the spendings Stu is actually in labor resources within companies and that's hard to track. Let's talk about what we should expect at the show. Obviously this whole notion of secure supply chain was a big deal last year in LA, what's hot? >> Yeah, so security Dave, absolutely. You said for years, it's a board level discussion, it's now something that really everyone in the organization has to know about the dev sec ops movement, has seen a lot of growth, secure supply chain, we're just trying to make sure that when I use open source, there's lots of projects, there is the huge ecosystem in marketplaces that are out there. So I want to make sure that as I grab all of the pieces that I know where they got came from the proper signature certification to make sure that the full solution that I build, I understand it. And if there are vulnerabilities, I know if there's an issue, how I patch it in the industry, we talk about CBEs, so those vulnerabilities, those exploits that come out, then everybody has to do a quick runaround to understand wait, hey, is my configuration? Am I vulnerable? Do I have to patch things? So security, absolutely still a huge, huge thing. Quick from a Red Hat standpoint, people might notice we made an acquisition a year ago of StackRox. That product itself also now has a completely fully open source project itself, also called StackRox. So the product is Red Hat advanced cluster security for Kubernetes, there's an open source equivalent for that called StackRox now, open source, community, there's a monthly office hour live streaming that a guy on my team actually does, and so there'll be a lot of activity at the show talking about security. So many other things happening at the show Dave. Another key area, you talked about the developers and what they want to worry about and what they don't. In the container space, there's a project called Knative. So Google helped create that, and that's to help me really have a serverless operational model, with still the containers and Kubernetes underneath that. So at the show, there will be the firs Knative con. And if you hadn't looked at Knative in a couple of years, one of the missing pieces that is now there is eventing. So if I look at functions and events, now that event capability is there, it's something I've talked to a lot of customers that were waiting for that to have it. It's not quite the same as like a Lambda, but is similar functionality that I can have with my containers in Kubernetes world. So that's an area that's there and so many others, I mean, GitOps are super hot at the last show. It's something that we've seen, really broad adoption since Argo CD went generally available last year, and lots of customers that are taking that to help them. That's both automation put together because I can allow GitHub to be my single source of truth for where I keep code, make sure I don't have any deviation from where the kind of the golden image if you will, it lives. >> So we're talking earlier about, how hard it is to track this stuff. So with the steep trajectory of growth and new customers coming on, there's got to be a lot of experimentation going on. That probably is being done, somebody downloads the open source code and starts playing with it. And then when they go to production that I would imagine Stu that's the point at which they say, hey, we need to fill some of these gaps. And they reach out to a company like yours and say, now we got to have certifications and trust., Do you. see that? >> So here's the big shift that happened, if we were looking four or five years ago, absolutely, I'd grab the open source code and some people might do that, but what cloud really enabled Dave, is rather than just grabbing, going to the dot the GitHub repo and pulling it down itself, I can go to the cloud so Microsoft, AWS, and Google all have their Kubernetes offering and I click a button. But that just gives me Kubernetes so there's still a steep learning curve. And as you said to build out out that full stack, that is one of the big things that we do with OpenShift is we take dozens of projects, pull them in together so you get a full platform. So you spend less time on curating, integrating, and managing that platform. And more time on the real value for your business, which is the application stack itself, the security and the like. And when we deliver OpenShift in the cloud, we have an SRE team that manages that for you. So one of the big challenges we have out there, there is a skillset gap, there are thousands of people getting certified on Kubernetes. There are, I think I saw over a hundred thousand job openings with Kubernetes mentioned in it, we just can't train people up fast enough, and the question I would have as an enterprise company is, if I'm going to the cloud, how much time do I want to build having SREs, having them focus on the infrastructure versus the things that are business specific. What did Amazon promise Dave? We're going to help you get rid of undifferentiated heavy lifting. Well, I just consume things as a service where I have an SRE team manage that environment. That might make more sense so that I can spend more time focusing on my business activities. That's a big focus that we've had on Red Hat, is our offerings that we have with the cloud providers to do and need offering. >> Yeah, the managed service capability is key. We saw, go back to the Hadoop days, we saw that's where Cloudera really struggled. They had to support every open source project. And then the customers largely had to figure it out themselves. Whereas you look at what data bricks did with spark. It was a managed service that was getting much greater adoption. So these complex areas, that's what you need. So people win sometimes when I use the term super cloud, and we getting little debates on Twitter, which is a lot of fun, but the idea is that you create the abstraction layer that spans your on-prem, your cloud, so you've got a hybrid. You want to go across clouds, what people call multi-cloud but as you know, I've sort of been skeptical of multi-cloud is really multi-vendor. But so we're talking about a substantial experience that's identical across those clouds and then ultimately out to the edge and we see a super Paas layer emerging, And people building on top of that, hiding the underlying complexity. What are your thoughts on that? How does Kubernetes in your view fit in? >> Yeah, it's funny, Dave, if you look at this container space at the beginning, Docker came out of a company called dotCloud. That was a PaaS company. And there's been so many times that that core functionality of how do I make my developers not have to worry about that underlying gank, but Dave, while the storage people might not have to worry about the LANs, somebody needs to understand how storage works, how networking works, if something breaks, how do I make sure I can take care of it. Sometimes that's a service that the SRE team manages that away from me. so that yes, there is something I don't need to think of about, but these are technically tough configurations. So first to one of your main questions, what do we see in customers with their hybrid and multi-cloud journey? So OpenShift over 10 years old, we started OpenShift before Kubernetes even was a thing. Lots of our customers run in what most people would consider hybrid, what does that mean? I have something in my data center, I have something in the cloud, OpenShift health, thanks to Kubernetes, I can have consistency for the developers, the operators, the security team, across those environments. Over the last few years, we've been doing a lot in the Kubernetes space as a whole, as the community, to get Kubernetes out to the edge. So one of the nice things, where do containers live Dave? Anywhere Linux does, is Linux going to be out of the edge? Absolutely, it can be a small footprint, we can do a lot with it. There were a lot of vendors that came out with it wasn't quite Kubernetes, they would strip certain things out or make a configuration that was smaller out at the edge, but a lot of times it was something that was just for a developer or something I could play with, and what it would break sometimes was that consistency out at the edge to what my other environments would like to have. And if I'm a company that needs consistency there. So take for example, if I have an AI workload where I need edge, and I need something in the cloud, or in my data center of consistency. So the easy use case that everybody thinks about is autonomous vehicles. We work with a lot of the big car manufacturers, I need to have when my developer build something, and often my training will be done either in the data center or in the public cloud, but I need to be able to push that out to the vehicle itself and let it run. We've actually even got Dave, we've got Kubernetes running up on the ISS. And you want to make sure that we have a consistency. >> The ultimate edge. >> Yeah, so I said, right, it's edge above and beyond the clouds even, we've gone to beyond. So that is something that the industry as a whole has been working at, from a Red Hat standpoint, we can take OpenShift to a really small footprint. Last year we launched was known as single node OpenShift. We have a project called micro shift, which is also fully open source that it has less pieces of the overall environment to be able to fit onto smaller and smaller devices there. But we want to be able to manage all of them consistently because you talked about multi cluster management. Well, what if I have thousands or 10 of thousands of devices out of the edge? I don't necessarily have network, I don't have people, I need to be able to do things from an automated standpoint. And that's where containers and Kubernetes really can shine. And where a lot of effort has been done in general and something specifically, we're working on it, Red Hat, we've had some great customers in the telecommunication space. Talk about like the 5G rollout with this, and industrial companies that need to be able to push out at the edge for these type of solutions. >> So you just kind of answered my next question, but I want to double click on it which was, if I'm in the cloud, why do I need you? And you touched on it because you've got primitives, and APIs, and AWS, Google, and Microsoft, they're different, if you're going to hide the underlying complexity of that, it takes a lot of RND and work, now extend that to a Tesla. You got to make it run there, different use case, but that's kind of what Linux and OpenShift are design to do, so double click on that. >> Yeah, so right. If I look at the discussion you've been having about super clouds is interesting because there are many companies that we work with that do live across multiple environments. So number one, if I'm a developer, if my company came to me and said, hey, you've got all your certifications and you got years of experience running on Amazon, well, we need you to go run over on Google. That developer might switch companies rather than switch clouds because they've got all of their knowledge and skillset, and it's a steep learning curve. So there's a lot of companies that work on, how can we give you tools and solutions that can live across those environments? So I know you mentioned companies like Snowflake, MongoDB, companies like Red Hat, HashiCorp, GitLab, also span all of those environments. There's a lot of work, Dave, to be different than not just, I say, I don't love the term like we're cloud agnostic, which would mean, well, you can use any cloud. >> You can run on any cloud. >> That's not what we're talking about. Look at the legacy that Red Hat has is, Red Hat has decades of running in every customer's data center and pick your X 86 server of choice. And we would have deep relationships when Dell, HP, IBM, Lenovo, you name it, comes out with a new piece of hardware that was different. We would have to make sure that the Linux primitives work from a Red Hat standpoint. Interesting Dave, we're now supporting OpenShift on Azure Stack Hub. And I talked to our head of product management, and I said, we've been running OpenShift in Azure for years, isn't Azure Stack Hub? Isn't that just Azure in your data center. He's like, yeah, but down at the operating system level, we had to change some flags and change some settings and things like that, so what do we know in IT? It's always the yeah, at the high level, it looks the same, it acts the same, it feels the same. >> Seamless. >> It's seamless in everything when you get down to the primitives level, sometimes that we need to be able to do that. I'll tell you Dave, there's things even when I look at A cloud, if I'm in US East One, or US West One, there actually could be some differences in what services are there or how things react, and so therefore we have a lot of deep work that goes into all of those environments, and it's not just Red Hat, we have a marketplace and an ecosystem, we want to make sure you've got API compatibility across all of those. So we are trying to help lift up this entire ecosystem and bring everybody along with it because you set it at the upfront, Kubernetes alone won't do it, oo one vendor gives you an entire, everything that you need for your developer tool chain. There's a lot that goes into this, and that's where we have deep commitment to partnerships. We build out and support lots of ecosystems. And this show itself is very much a community driven show. And, and therefore, that's why Red Hat has a strong presence at it, 'cause that's the open source community and everything that we built on. >> You guys are knee deep in it. You know I wrote down when you were talking about Snowflake and Mongo, HashiCorps, another one, I wrote down Dell, HP, Cisco, Lenovo, that to me, that should be their strategy. NetApp, their strategy should be to basically build out that abstraction layer, the so-called super cloud. So be interesting to see if they're going to be at this show. It requires a lot of R and D number one, number two, to your point, it requires an ecosystem. So you got all these guys, most of them now do in their own as a service, as a service is their own cloud. Their own cloud means you better have an ecosystem that's robust. I want to ask you about, do you ever think about what's next beyond Kubernetes? Or do you feel like, hey, there's just so much headroom in Kubernetes and so many active projects, we got ways to go. >> Yeah, so the Kubernetes itself Dave, should be able to fade into the background some. In many ways it does mirror what happened with Linux. So Linux is just the foundation of everything we have. We would not have the public cloud providers if it wasn't for Linux. I mean, Google, of course you wouldn't have without Linux, Amazon. >> Is on the internet. >> Right, but you might not have a lot of it. So Kubernetes, I think really goes the same way is, it is the foundational layer of what so much of it is built on top of it, and it's not really. So many people think about that portability. Oh, Google's the one that created it, and they wanted to make sure that it was easy if I want to go from the cloud provider that I had to use Kubernetes on Google cloud. And while that is a piece of it, that consistency is more important. And what I can build on top of it, it is really more of a distributed systems challenge that we are solving and that we've been working on in industry now for decades. So that is what we help solve, and what's really nice, containers and Kubernetes, it's less of an abstraction, it's more of new atomic unit of how we build things. So virtualization, I don't know what's underneath, and we spent like a decade fixing the storage networking components underneath so that the LANs matched right, and the network understood what was happening in the virtual machine. The atomic unit of a container, which is what Kubernetes manages is an application or a piece of an application. And therefore that there is less of an abstraction, more of just a rearchitecting of how we build things, and that is part of what is needed, and boy, Dave, the ecosystem, oh my God, yes, we've gone to only three releases a year, but I can tell you our roadmaps are all public on the internet and we talk heavily about them. There is still so many things that just at the basic Kubernetes piece, new architectures, arm devices are now in there, we're now supporting them, Kubernetes can support them too. So there are so many hardware pieces that are coming, so many software devices, the edge, we talked about it a bit, so there's so much that's going on. One of the areas that I love hearing about at the show, we have a community event called OpenShift Comments, which one of the main things of OpenShift Comments, is customers coming to talk about what they've been doing, and not about our products, we're talking about the projects and their journey overall. We've got a at Flenty Show, Airbus and Telefonica, are both going to be talking about what they're doing. We've seen Dave, every industry is going through their digital transformation journey. And it's great to hear straight from them what they're doing, and one of the big pieces in area, we actually spend a bunch of time on that application journey. There's a group of open source projects under what's known as Konveyor, that's conveyor with a K, Konveyor.io. It's modernization in migration. So how do I go from a VM to a container? How do I go from my data center to a cloud? How do I switch between services, open source projects to help with that journey? And, oh my gosh, Dave, I mean, you know in the cloud space, I mean that's what all the SIs and all the consultancies are throwing thousands of people at, is to help us get along that curve of that modernization journey. >> Okay, so let's see May 16th, the week of May 16th is KubeCon in Valencia Spain. theCUBE's going to be there, there was a little bit of a curfuffle on Twitter because the mask mandate was lifted in Spain and people had made plans thinking, okay, it's safe everybody's going to be wearing masks. Well, now I mean, you're going to have to make your own decisions on that front. I mean, you saw that you follow Twitter quite closely, but hey, this is the world we live in. So I'll give you the last word. >> Yeah, we'll see if Twitter still exists by the time we get to that show with. >> Could be private. What happens, but yeah, no, Dave, I'll be participating remotely, it is a hybrid event, so one of the things we'll be watching is, how many people are there in person LA was a pretty small show, core contributors, brought it back to some of the early days that you covered heavily from theCUBE standpoint, how Valencia will be? I know from Red Hat standpoint, we have people there, many of them from Europe, both speaking, we talked about many of the co-located events that are there, so a lot of pieces all participate remotely. So if you stop by the OpenShift commons event, I'll be part of the event just from a hybrid standpoint. And yeah, we've actually got the week before, we've got Red Hat Summit. So it's nice to actually to have back to back weeks. We'd had that a whole bunch of times before I remember, back to back weeks in Boston one year where we had both of those events and everything. That's definitely. >> Connective tissue. >> Keeps us busy there. You've got a whole bunch of travel going on. I'm not doing too much travel just yet, Dave, but it's good to see you and it's great to be connected with community. >> Yeah, so theCUBE will be there. John Furrier is hosting with Keith Townsend. So if you're in Valencia, definitely stop by. Stu thanks so much for coming into theCUBE Studios I appreciate it. >> Thanks, Dave. >> All right, and thank you for watching. We'll see you the week of May 16th in Valencia, Spain. (upbeat music)

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

>> Announcer: From Austin, Texas, it's theCUBE covering DockerCon 2017. Brought to you by Docker and support from its ecosystem partners. (techno music) >> Welcome back. Hi, I'm Stu Miniman, joined with Jim Kobielus. You're watching theCUBE's SiliconANGLE Media's production of DockerCon 2017. We're the worldwide leader in live enterprise tech coverage. And we can't finish any DockerCon without having Jerry Chen on. So, Jerry, partner with Greylock, always a pleasure to interview you. We've had you on the Amazon shows a lot, Docker, other ecosystem shows, so, great to see ya. >> Stu, Jim. Hey, thanks for having me, as always. It's great to be here. >> Alright, so first of all, I mean, you invested back in the dotCloud days. Could you imagine, when you were meeting with Solomon and those guys and everything that we'd be here with 5,500 people as to where they'd go? What's your take on the growth? >> Every year just blows my mind, both in open-source community developers, ecosystem partners, and more recently, past year and a half, the enterprise customers that take Docker seriously, or replatformed applications on Docker, amazes me. I think I did an investment in 2013, and there were a few hundred thousand downloads of Docker, now there's billions and billions of containers being pulled. When I talk to CIOs that I deal with frequently, they're like, "Docker containers, what is this thing, pants?" And then, (laughter) three and a half, four years later, I can't have a conversation without a Fortune 500 CIO without talking about their Docker container strategy. >> By the way, I hear if you do send back a belt or something that's broken to the Docker people, they'll fix it for you, and maybe send some whale stickers. >> It's like the old school Nordstroms where they take any return. They're this urban store, with the four tires return to Nordstrom, return some pants, you'll be fine. >> You know, we work on container strategy, but we're also your repair shop for you know, men's apparel. So, it's always interesting to look at-- >> Jim: Integration fabric. >> Brilliant. You know, the maturation of technology, of ecosystem, of monetization. I feel like you talked about the growth of the containers. We've seen the ecosystem. It's gone through some fits and spurts and changes over the last couple of years. I think we're really well-received this week. And then there's the money maturation and how they mature that. What do you see? How does open-source fit into your investment strategy, and any commentary on Docker and beyond? >> I was thinking about this on the flight over here today. Open source today is very different than open source five years ago, 10 years ago, as 15. So what what Red Hat did 20 years ago, is very different than what Xen tried to do 10 years ago. When I was at VMware, very different from what Docker is doing today. And it's different in a couple ways. I think the way you monetize is different. Because you have cloud, and cloud changes things. The ecosystem's very different, because all of a sudden the developers, contributors, are not just kind of your misfits and rebels working on the weekends. They are Fortune 100, Fortune 500 companies. Their jobs are now dedicated to this. And then the business models of the developers' ecosystem, how you work with them is very different. So before, you had maybe one or two models to make money in open source. Or one or two ways to develop a community. We did that at Red Hat, which Greylock was lucky enough to be investors in years ago. I was at VMware around Cloud Foundry, we built that. We had a model mine, we had a spring source as well, and what you've seen Docker in the past three or four years, is they're really pioneering a way to bring open source and community ecosystem into the next 10-20 years. So I think it's one to watch. I think Solomon's probably as good as anybody understanding what developers need. >> So a little broader, what's your thoughts on developers today? You actually made the comment coming over, there's two big developer shows this week. You've got F8 and you've got DockerCon, two very different communities. >> Right, it's kind of funny. There's always this sense of, do you consider yourself a developer? So if I write a line of JavaScript, am I a developer? My two cents is yes. If I'm a developer, from JavaScript to Swift to Docker to cURL hacking, it's all great. But if you look at those two conferences, you have F8 going on right now, and the announcements there around augmented reality and messaging, and it's trying to be a platform, but they're doing many of the same things. You have a distribution platform be it Messenger or Facebook, and they're open sourcing technologies around the camera, the lens, the filters, to have developers a) go through the channel, b) add apps or widgets. It's really beyond my ability to comprehend these filters, but Docker today announced a couple great projects: Moby and Linux Kit, much the same way as trying to give tools to the ecosystem developers to build what they want. I think what you've learned is, if you give developers the building blocks, the "Legos" as they call it today, they're going to build some awesome structures. >> Jim was, we talked about coming in here as the role of how data science fits into the developers, and developer is such a broad term, as to what we have here. >> One of the core themes I have is that the data scientist is the nucleus of next generation developer because much of the IP that's being built in the applications now, is statistical models and machine learning and so forth, driving recommendation, but much of that development is being containerized using new tool kits and so forth. But it needs to be more containerized so you can deploy statistical predictive models, machine learning, deep porting to routing the string ecosystem into a hybrid cloud to perform various functions. >> Right now there's, in most companies, there's a data engineer, there's a data scientist, and the two typically work hand in hand. >> Jim: One manages Hadoop, the other one does the modeling. >> Does the modeling, so one speaks in R and Python and works in Jupyter Notebook, the other person runs on Hadoop or database or Redis. The two need to work together and so what you're seeing now and obviously we're investors of Cloudera, that's another great open source company, what you see now is either a) a set of tools and technologies to either blend the two together in some cases, either enable engineers to be more data scientists, or enable data scientists to be more engineers, but also see a bunch of technology tools that say, no, two different roles, I'm going to create tools purpose-built for the data scientists, create tools purpose-built for the power of a data engineer. And I think there's space for both to the extent that you have applications running from news feed or ads to predicting how my self-driving car should make a left turn, you're going to need tools that are used by both types of populations. >> I think Cloudera now has a collaboration environment in the data science department. IBM has something very similar with what they're doing, so it's a team that has specialties such as coders, such as data modelers and data engineers. Point well taken. Cloudera's made a major entrance into that space of collaborative development, of these rich stacks of IP, essentially, that include deterministic program code, but also probabilistic models in a deepening stack. >> I think you've seen Cloudera definitely follow that path from Hadoop and low-level file system HDFS, to these high-level tools for data scientists that's becoming a platform for machine learning for these next generation applications. I think you see Docker in the infrastructure analogy doing low-level tools like Project Moby and Linux Kit, to high-level services around Docker Datacenter. So you can either have the basic tools for your low-level developer, or for the system admin or administrator who wants to operate or run the cloud, you have tools for him or her, too. >> It's interesting, you look at some of these projects and some of the maturation and pivots you see. We talked about dotCloud went over to Docker. You see a bunch of open stock companies that are now Kubernetes companies. I see companies that were big data, they're now, "Oh, I'm an AI or ML company." It's always like, it's usually not the tool, it's the wave. What is the driver? Is data the driver of our next wave there? Is it the application? Is it some combination of the two? Those are the two that I usually look at. Follow the data, follow the application. >> I would say it's data driving. It's really data application, it's data, and the applications make use of the data. Algorithms, I think, is a component. They're important, but they're a component. So what you see now is, to be on the right side of history, data is outstripping compute and storage, so the amount of videos and center data that we're generating from our phones, our cars, our homes, that is outstripping most of the other charts in compute, networking, whatever. That's definitely kind of a rising tide or a wave, as Stu was saying. Now how do we extract data, or value from this data? And historically, because you didn't have infrastructure, that cloud, or compute capacity to make use of this data, it was kind of stranded, so what you've seen in generation technologies like Hadoop or big data or cloud technologies like Docker did, is distribute your applications across a cloud. That's actually enabling you to now build applications to get value out of this data. And that value can be something like forecasting your sales this quarter. It can be about figuring which shade of brown belt you should wear with your pants, going back to our clothing analogy. Or it could be like, let me build a model around how this car or this drone should drive or fly itself. So you combine the vast amount of data, nearly infinite resource of compute, with these machine-learning or AI techniques. Machine learning is one AI technique, but all these other techniques, you can build another generation application, this new intelligent application to power everything from your home, your car, your watch, or your enterprise app, as wonderful as that is. >> Much of the sea change is less and less coding or programming is actually being done or needs to be done because more of the application logic is being distilled directly from the data in the form of machine learning. There's automated machine learning tools that are coming. Google has been a major investor as is Facebook in automated machine learning. >> I would say application logic from the inside, right. So in my mind, application logic, an application is reflecting business process. Hire to fire, order to cash. You still need a program that does logic. Data in itself, or AI in itself without that context, without that business process, is meaningless, right. Just having a model around Jim or Stu, it doesn't matter unless you're trying to buy something. Google pioneered machine learning in a workflow perfectly. You're searching for something, they knew who you were based upon history, you're searching the right ad and say, "Oh, you really want to buy a car, you want to buy a house." So in the workflow, or in the application logic of a search, they used ML to serve you timely information. Now if you're an enterprise, you're looking at help desk tickets, be it ITSM like ServiceNow, or support tickets like Zendesk supporting B to C support tickets. That's a workflow, there's application logic. They take information on a user or a grumpy customer, and they do things like automatically respond to a help ticket, reset your password, provision a server. So I think when you have AI or have applications using this data in the context of a business process, that's magic. And I think we're seeing some core technologies like TensorFlow out there that are super compelling. But we're seeing a generation of developers and founders take that technology, apply it to a problem, it could be HR or CRM, ITSM, or true vertical. Construction, finance, health care. >> Jim: Streaming media analytics is a core area where that's coming in. >> Media analytics because there's a ton of data. Understand what you watch and what you want to see, and so you apply things to a vertical, like health care, or apply the technology to a problem space like media analytics, and you have a wonderful application and hopefully a great company. >> Jerry, we've talked a lot at the cloud shows about how do the startups maintain relevant and get involved when there's all of these platforms. We talked about what Google does, Amazon of course is eating the entire world in everything. Microsoft is making lot of moves here. How do companies, what do you look for? Has your investment strategy changed at all in the last couple of years? >> It is daunting. I think about this a lot in terms of business models and defensibility, and the question goes, what are the sustainable moats you can build around your business as a startup anymore? 'Cause you feel like economies of scale and ecosystems, network effects, those were historically big defensive moats for a Windows operating system. Now those apply to Facebook's platform, Apple's platform, or AWS. They have scale and they have network effects for the ecosystem, so now your startup is saying, okay, how can I either a) overcome those moats, or b) how can I develop my own IP or my own moats around myself that I can actually sustain and thrive in this generation. I think you got to play a different game. As a startup, you're not going to try to out-scale Google or Microsoft; leave that to Amazon and those three or four players. But you can get scale in a domain, so either a problem space like autonomous vehicles, security is a great one, or vertical construction or health care. You redefine the market that you can dominate, can you build your own moat around that IP. >> It's interesting. did you hear Adrian Cockcroft who went from Battery Ventures over to AWS. He's like, "Well, rather than go startup that business, "come build that next thing at Amazon "and we'll do it there." Is that a viable way for people with the entrepreneurial spirit to go be part of that two-pizza team doing something cool inside a large platform? >> I think Adrian probably has motivation and more developers on Amazon now, but I would say most of our companies, not all, but a lot of them started at Amazon. Some start in ads, some start in Google, some start with their own data centers. I think what they believe is they'll get started in one of these clouds but I don't believe, so we talked about this first, it's not a one-cloud-rules-all world. I think there'll be three or four, if not more, clouds in every different geography from Europe to Asia to Russia to the US, will have different clouds, different players. So I think it's fine to get started in Amazon and be a two-pizza team with the other two-pizza team, but over time I see these applications being cross-cloud, and that's where something like Docker comes into play. Docker wants to be cross-cloud, better than any other technology out there. >> On some level, actually, the moat could be, or increasingly is, the training data that drives the refinement of your AI, like Tesla is a perfect example. The self-driving capabilities that they built into the vehicle, they have now a few years' worth of rich test data, training data I should say, that is a core moat in terms of continuing refinement of those algorithms. So that gives you sort of an example of some startup might come along with some very specialized application that takes the consumer world by storm and then they build up some deep well of training data in some very specialized area that becomes their core asset that their next competitor down the pipe doesn't have. >> It has to be a set of data that's unique or proprietary. You're not going to basically out-train your model on cat photos from Google, right? So it has to be a combination of either proprietary data or a combination of data sources that you can stick together. So it's not just one data source, I believe you have to combine multiple data sources together. >> So Jerry, sitting over Jim's shoulder is VMware's booth. I haven't talked about VMware at all this week. You worked at VMware, I've worked with VMware since pretty early days. What advice would you give VMware in the containerized cloud future? How should they be doing more to be part of more conversations? >> I think it's amazing that they have a presence here in the size and scale. The past couple years they're really done a lot to embrace containers and Docker, so I think that's first and foremost. They've done a couple great moves lately. Embracing Amazon last year, with VMware on Amazon, was a big move. Embracing containers with some of their cloud and data technologies I think was an aggressive move too. So I think they're moving in the right direction. I think what they need to understand is, are they going to revolutionize themselves and push these new technologies aggressively, or are they going to keep hanging onto some of their old businesses? For any company of their size and scale, they have multiple motivations, but I think they're making the right steps. So five years ago, or four years ago, I don't think they would have taken this DockerCon seriously. I don't think they were exhibitors at the first DockerCon. But in the past 24 months they've done some amazing moves, so I would say it makes me smile to see them take these great steps forward. >> Jerry, I want to give you the last word. Any cool companies we should be looking at, or things that are exciting to you without giving away trade secrets? >> I can't broadcast the companies I want because everyone else is going to chase those investments. I don't know, I think I'm going to enjoy spending time, actually less with the companies here but a lot with the developers and customers, because I think by the time they have a booth here, everybody knows the company's investment is probably too far along maybe for me to invest, maybe not. But talking to developers to hear what are their friction points? I think when you hear enough friction either in this ecosystem or another ecosystem or at AWS or VWware, then there's something there, you just got to scratch. >> I was talking to some of the people working the booths and they just said the quality of the attendees here, you learn something with every single person you talk to, and there's only a few shows that say that. Amazon reinvented one, the quality of the attendees always real good, this one and a few others. >> I think people who come here by definition are learners, both the companies and the individuals, and you want to surround yourself with learners, people who are open and honest and always learning. >> Jerry, I think that's a perfect note to end it on. We are always learners here and helping to help our audience in trying to understand these technologies, so Jerry Chen, always a pleasure. And we'll be back with the wrap-up here of day one DockerCon 2017. You're watching theCUBE. (techno music)