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

>> Voiceover: Live from Austen, Texas, it's theCUBE. Covering DockerCon 2017, brought to you by Docker, in support from its ecosystem partners. >> And we're back. Hi I'm Stu Miniman joined by Jim Kobielus and this is theCUBE, worldwide leader in live enterprise tech coverage. Happy to have on the program, Scott McCarty, who is technical product marketing for containers with Red Hat, thanks so much for joining us! >> Thanks for having me. >> Alright so, obviously this is the big container show, You know, Red Hat, I saw when you talk about the number of contributors, you're one of the top contributors there, but first tell us a little bit about your role at Red Hat, how long you've been there, some of your passions, what do you work on? >> Yeah for sure. So I've been at Red Hat six years and I started actually as a solutions architect, six-ish years ago, came from a startup before that, and so been in the operations space for a long time, did a lot of programming, background in anthropology computer science. Yeah. >> You're dating yourself, you call it programming >> I know, I know! >> Because it's coding now! >> I know, I know! (laughs) >> I'm like, yeah, I used to program but, uh, what's this, this coding stuff. >> I am dating myself! >> Did you say anthropology? >> I did. >> Well we've got to connect it with Red Hat at some point in our interview now. >> It matters in the culture of things. >> James: Okay, yeah. >> You know, culture is important. (laughing) So did you know, a very wide swath of our portfolio I understand from being a solutions architect and then about two years ago moved into, well when Docker first started off, you know, got into containers and got pretty heavy and that, and was excited about it, and then moved into just doing strictly technical product marketing for only containers. You know, for focusing on containers. >> Okay, so talk to us about how containers fits into the Red Hat portfolio. >> So containers is really something that touches every part of our portfolio, because whether at the lower levels of like the Linux layers you know that's the actual nuts and bolts of, you know, what builds the containers and what the containers really are. But then at the other end of the stack, if you look at our storage and our middleware, containerizing those applications and then figuring out how to package them in a cloud-native way and making them work in a cloud-native way, so that they can operate inside of something like OpenShift, there's a lot of work to be done there. So there's a wide swath of tech across our entire portfolio of work around containers going on. >> Yeah, in the keynote this morning I like there's the maturation of the use cases because it sounds a lot like, you know, remember of the early days of Linux, or the early days of virtualization, once again they've put together a load of use cases and are like, "Oh, we're running applications," >> Scott: Yes. >> In a wide variety of applications in containers, so what are your customers seeing, you know, any kind of cool use cases or things that people are doing and anything new that they're doing that they couldn't do before? >> Well, so, I'll give you a little take on that, so even for the last two years that I've been going out all over the world to talk to customers, I've noticed that there's a little bit of a disconnect between the industry and kind of only focusing on the app dev side of things. I think today, kind of hearing Soloman talk about some of the more traditional use cases, traditional or non-cloud native or, we don't like to say the word legacy but people say it. >> Stu: Kind of wrapping-- >> I would argue those have been a huge portion of what people are experimenting with and playing with, but we don't talk about them. Also I think there's a little bit of a notion of this mode one, mode two kind of mentality, but that limits the way we think about it into only production workloads. So I have some really funny use cases. So I'll give you some examples, network scanning. So, like, there are some vendors that provide network scanning software and I was a couple of months back up in Canada talking to ATTO Co., and they mentioned they they were actually putting a commercial network scanning package in containers because when you think about, you see a production oracle database and, you know, you talk to the oracle DBA, and you say, "Hey I'm going to install "this giant network scanning package on your server." And they're like, "No. You're not doing that." (laughing) So a container makes it very easy to just bring that application down, do this network scanning, troubleshoot something and then delete it, it's gone. That's just a tools use case, right? But it's something that people have been doing for a long time but nobody is really talking about it. Another one is even affecting business more transformationally. So if you think about the way startups hire people, this happened to a friend of mine that's a CTO at a startup. They're interviewing a developer, it's very common to send them home with a homework program, you know? And so they send them home with the Ruby on Rails program, and he comes back with a GitHub Repo that has like a database schema file for Postgres and a working Ruby on Rails application. And there are two hiring managers. The one hiring manager says, "Okay I'm going to," And I'm sorry, also he says, "By the way, I have a Docker Repo, "you can go out and pull it down if you want, "just run my program and see if it works." The one hiring manager decides to try to rebuild it from scratch, takes about two hours messing around trying to get the database schema to work because he used the newer version of Postgres than she had on her laptop, you can imagine the dependency, you know, chaos that is. The other hiring manager literally just said, "Okay, just Docker run this thing." And then, kind of ran the container and looked at the code. The one spent two hours, you know, getting it up on her own, the other one spent five minutes. And so now if I can give you back the most valuable people in your organization, these very, very technical architects that are doing hiring decisions and trying to evaluate really critical core developers for your startup, if I can give you back two hours, and if you have to interview 10 of those, that's 20 hours of your time, that's transformational, that's really digital transformation, essentially, but for a startup, you know. Like, we don't want to have to spend all this analog time doing that. In addition to the traditional applications like databases and even, you know, typical web servers, all of those things, but not just mode two or cloud native, but also just traditional workloads. And we've been seeing that for a long time, I mean, this is similar to the virtualization journey, it's like you said, everyone said it was impossible and even two years ago was saying, "Wait a minute, just wait for this, it'll happen," and we're seeing it happen. >> Yeah. Anything particular? You know, we've made a lot of progress, but we're still working on storage, networking seems to be a little bit more mature than storage you know, what are you guys helping to work on at Red Hat and what do you want to see going forward that we come here a year from now we're going to say, "Oh, cool, we knocked down this barrier, or we're doing something even better." >> So one of the things I'm excited about is kind of if you look at the integration points between cloud infrastructure software like OpenStack and even the cloud providers, and then something like our OpenShift solution or Kubernetes, if you look at the storage and the network interactions, today the networking is pretty mature but the interaction is pretty static, so if you provision OpenStack, you know, say you have an OpenStack environment, you want to run OpenShift on top of it, you would go pre-provision kind of a VLAN, you know a subnet for it, and then you would- we rebuild, actually, key templates to deploy OpenShift inside of it, within that subnet. In the future we're investing in Courier and you know, a year from now I'd like to see some really dynamic interactions happening between OpenShift and OpenStack. I'd like to see an administer say, "Oh, I need to provision a new project "and that project needs its own network isolation." When that happens, OpenShift goes and talks to OpenStack, provisions a subnet that's encrypted with OVS, and actually it already is kind of set up, comes back, says, "Okay cool," and then can provision a project inside that. On the storage side we've actually already got that going, So we have what's called dynamic provisioning, so if you need storage inside of OpenShift and you have a persistent volume claim that needs access to storage, we actually have something called a dynamic provisionary that will actually go create that person's environment and go to talk the the storage and carve off a LUN of exactly the size you want or a NFS share of the exact size that you want. So, so, I'd like to see more and more of that dynamic provisioning happening between the infrastructure in a container environment. >> Is that as capable, uh, should we build into Kubernetes or totally independent of that? You know what I mean-- >> So the current project is kind of neutral but it would be, kind of, think of it as almost like an interface that Kubernetes will be able to use as an interface to all the networking providers. >> James: Right. >> So it's kind of a neutral, third-party thing. Really it could be used by other things other than Kubernetes. >> I want to get your take on project Moby, that was a real interesting announcement today, to what extent, would Red Hat consider possibly using that as a tool to build custom container applications for your own product family? >> Probably the most interesting thing I found about the announcement was kind of a validation of, uh, you know already a kind of strategy that we had around Project Atomic. And if you look at Origin and Project Atomic and Fedora, you know, they mention Fedora, that model. >> James: Yeah, absolutely. >> I think it's a good model, and you'll appreciate that we appreciate it. I think that, you know, there's some validation also around the idea of an immutable host, and having control over the host and honestly I think it kind of validates that the Linux itself is not a commodity, there is something actually very technical there and you do need to actually build a dry features in that kernel to actually support the containers, because I think they made the kernel hot again, you know, in a lot of ways. So I think it's validation of that and I think that's exciting. >> At the beginning we talked about culture a little bit, you know, we've interview Jim Whitehurst, so you know, I've read his book, >> Scott: Yeah. >> You know, the open organization, >> James: The anthropology. (laughs) >> You know, when you come to a show like this where, I mean, today we talked about the developer, we talked lots about open-source and, right, you know there's Linux Kit, there's the Moby Project, you know, all these different things out in open-source, what's your take on this ecosystem and what's going on in the industry? >> I think ecosystems are harder to build than what people first think. I don't think you can just, so if you look at certain, you know if I were to analyze the way open source works, you know there sot of open-core models which are like, "Let's give enough away to get free marketing." Then there's kind of open-source models where we give away all the code but we don't really have a community, we don't really take patches, we just put it out there, use it however you want, that's fine. And then I think there's truly community-driven open-source which is what Red Hat really tries to focus on. So if you're able to get Fedora, it's truly a community. I think building those and maintaining those takes a lot of nurturing and a lot of care and a lot of love and feeding. And I also think it takes a lot of discipline around allowing these best-of-breed ideas to kind of happen the way they're going to happen and then also fail if they don't work. And so that can be tough, you know. If you look at the model of a lot of startups, it's more kind of like unilaterally make decisions and then kind of release it and then if it sticks, and it's fail-fast. The community-driven model is a lot harder to handle because consensus is harder to build and so you've seen Jim talk about this, I mean one of the dangers in an open organization of our size is consensus, finding consensus and not going towards a completely consensus-driven decision model. But that's hard because you have to satisfy everybody in the community and make sure everybody's getting something out and everybody's putting something in. And so it's tough. >> It's funny, I remember in OpenStack for a couple of years, it's like, "Do we need, you know, the fanatical dictator "of this ecosystem?" Red Hat, obviously is not, you know, a fanatical dictator of its community. >> You can't win. Do you think Docker has a fanatical dictator of their community? (laughter) >> I, I, I'm sure the-- >> Or is the person a visionary, I mean, you know they'll put the positive euphemism on it. >> Yeah, yeah. Or the joking word in the community is the benevolent dictator. >> Yeah. >> The benevolent dictator for life, I think some of the communities work that way. >> Yeah. >> I think if you look at Python, you look at Linux, you know, it works that way. But if you've all got bigger projects, and I don't want to date myself, but you think about KDE and Gnome, and some of those, there's no benevolent dictator, they're so big and so wide-reaching again. Such, you know, wide-use case differences between what people do with them, but I think it's hard to have that. There are visionaries, you know, within the group. And even that's true in the kernel, I mean if you look at what's happened, you know, Linus has other generals essentially that kind of, I mean it's become a very big community, a very boisterous community. I think that that takes again, though, a lot of discipline and maintenance to make that happen and keep that alive. >> Alright, Scott, to take us on home, why don't you give us a little view as to what Red Hat has going on this week, of course you guys have your big show Red Hat Summit coming up in a couple of weeks, we'll have theCUBE there, I'm excited to be there, also, but you know, talk a little bit about this week and what you guys are doing. >> So this week, you know, we're excited because we have kind of a bunch of three-five You know, I don't know if you guys, have you guys heard about Atomic Image? We released Atomic Image? >> So it was not discussed in Brian's interview this morning, so. >> Okay! >> We would love to hear a little bit about it. >> So Atomic Image, we've kind of looked at some of the use cases around how people are consuming containers and I've blogged on about this and talked and honestly it's pretty deep technically when you kind of get into it. It's about having, you know, Soloman talked about it today, you know, image size matters, and there is definitely a hunger for smaller images, you don't want to have stuff that you don't want. But that is also a very fine-line balance. So the challenge being that the typical way that enterprises operate is that they have a core build where they will add all the pieces that core build that they think should be everywhere, right? Because you don't, like, say you need a fundamental core library like glibc, you wouldn't add that to all of the different applications, you would add it once and then inherit it in all the, so it's kind of the dry model, do not repeat yourself, right? So when you get into this dry model you got to balance the size of that base image versus, you know and it's flexibility versus conciseness, and you know, how concise it is. Atomic Image, though, is meant for, we essentially released a very minimal image that matters for those very concise applications, so if you look at like a C binary that's very small, maybe all it needs is DNS resolutions, some other services from the OS from the userspace, it doesn't need much, but it's a real small binary, it wants a really small image to live on. So we released something called Atomic Image really targeting those use cases-- >> I don't know if I remember if Atomic is launched, so it sounds a lot like what Docker announced with the Linux Kit today, too. >> So, it's, flip-side of it-- >> Maybe you could compare contrast a little bit. >> Yeah so, so I would compare Linux Kit to Atomic Coast, which we've had for a long time. >> Stu: Okay. >> Which is the Kernel and systemd and kind of what runs the containers, right? But now we've released a different userspace setup that's smaller-- >> Stu: Oh I got that, okay. >> For, to run on top of, you know. >> So like an agile minimum viable product, this is a minimum viable container >> Yes. >> For a particular function. >> Yeah exactly, like BusyBox or some of the smaller images that you want to play with. >> And Scott, do you guys have their website or some documentation that you recommend people starting with on your sites? Yeah absolutely, I swear, I think Project Atomic's a great place to start. >> Stu: And that's in the blogs, I'm assuming, right? >> It is, if you blog for Atomic Image, too, you'll find a REL Blog entry, so REL Blog's a good place to kind of find some of that stuff, so relblog.redhat.com And then also if, if you look on just redhat.com. And also out container catalog is a good place to actually go get started with that. So if you go to access.redhat.com/containers. >> James: We'll get to that. >> Scott McCardy, it's great catching up with you. Next time we have you on we got to get the story behind "fatherlinux" as your-- >> Yes! (laughs) >> Alright, but we'll be back with more coverage here from DockerCon 2017, thank you for watching theCUBE.