>>welcome to the session. Long live swarm with containers and kubernetes everywhere we have this increasing cloud complexity at the same time that we're facing economic uncertainty and, of course, to navigate this. For most companies, it's a matter of focusing on speed and on shipping and iterating their code faster. Now. For many, Marantz is customers. That means using docker swarm rather than kubernetes to handle container orchestration. We really believe that the best way to increase your speed to production is choice, simplicity and security. So we wanted to bring you a couple of experts to talk about the state of swarm and Docker enterprise and how you can make best use of both of you. So let's get to it. Well, good afternoon or good morning, depending on where you are on and welcome to today's session. Long live swarm. I am Nick Chase. I'm head of content here at Mantis and I would like to introduce you to our two Panelists today eight of Manzini. Why don't you introduce yourself? >>I am a van CNI. I'm a solutions architect here at Moran Tous on work primarily with Docker Enterprise System. I have a long history of working with support team. Um, at what used to be Ah Docker Enterprise, part of Docker Inc. >>Yeah, Okay. Great. And Don Power. >>I, um Yeah, I'm Don Power on the docker. Captain Docker, community leader. Right now I run our Dev Ops team for Citizens Bank out of Nashville, Tennessee, and happy to be here. >>All right, Excellent. So All right, so thank you both for coming. Now, before we say anything else, I want to go ahead and kind of name the elephant in the room. There's been a lot of talk about the >>future. Yeah, that's right. Um, swarm as it stands right now, um, we have, ah, very vested interest in keeping our customers on who want to continue using swarm, functional and keeping swarm a viable alternative or complement to kubernetes. However you see the orchestration war playing out as it were. >>Okay? It's hardly a war at this point, but they do work together, and so that's >>absolutely Yeah, I I definitely consider them more of like, complimentary services, um, using the right tool for the job. Sort of sense. They both have different design goals when they were originally created and set out so I definitely don't see it as a completely one or the other kind of decision and that they could both be used in the same environment and similar clusters to run whatever workload that you have. >>Excellent. And we'll get into the details of all that as we go along. So that's terrific. So I have not really been involved in in the sort of swarm area. So set the stage for us where we kind of start out with all of this. Don I know that you were involved and so guys said, set the stage for us. >>Sure, Um I mean so I've been a heavy user of swarm in my past few roles. Professionally, we've been running containers in production with Swarm for coming up on about four years. Now, Um, in our case, we you know, we looked at what was available at the time, and of course you had. Kubernetes is your biggest contender out there, but like I just mentioned, the one of the things that really led us to swarm is it's design goals were very different than kubernetes. So Kubernetes tries to have an answer for absolutely every scenario where swarm tries to have an answer for, like, the 80% of problems or challenges will say that you might come across 80% of the workloads. Um, I had a better way of saying that, but I think I got my point across >>E Yeah, I think I think you hit the nail on the head. Um, Kubernetes in particular with the way that kubernetes itself is an a P I I believe that kubernetes was, um, you know, written as a toolkit. It wasn't really intended to be used by end users directly. It was really a way to build platforms that run containers. And because it's this really, really extensible ap I you can extend it to manage all sorts of resource is swarm doesn't have that X sensibility aspect, but what it was designed to do, it does very, very well and very easily in a very, very simple sort of way. Um, it's highly opinionated about the way that you should use the product, but it works very effectively. It's very easy to use. It's very low. Um, not low effort, but low. Ah, low barrier to entry. >>Yes. Yes. Absolutely. I was gonna touch on the same thing. It's very easy for someone to come in. Pick up swarm. You know they don't They don't have to know anything about the orchestrator on day one. Most people that are getting into this space are very familiar with Docker. Compose um, and entering from Docker compose into swarm is changing one command that you would run on the command line. >>Yeah, very, very trivial to if you are already used to building docker files using composed, organize your deployment into stacks of related components. It's trivial to turn on swarm mode and then deploy your container set to a cluster. >>Well, excellent. So answer this question for me. Is the swarm of today the same as the swarm of, you know, the original swarm. So, like when swim first started is that the same is what we have now >>it's kind of ah, complicated story with the storm project because it's changed names and forms a few times. Originally in is really somewhere around 2014 in the first version, and it was a component that you really had to configure and set up separately from Docker Ah, the way that it was structured. Ah, you would just have docker installed on a number of servers are machines in your cluster. And then you would organize them into a swarm by bringing your own database and some of the tooling to get those nodes talking to each other and to organize your containers across all of your docker engines. Ah, few years later, the swarm project was retooled and baked into the docker engine. And, um, this is where we sort of get the name change from. So originally it was a feature that we called swarm. Ah. Then the Swarm Kit project was released on Get Hub and baked directly into the engine, where they renamed it as swarm mode. Because now it is a motile option that you just turn on as a button in the docker engine and because it's already there the, um, the tuning knobs that you haven't swarm kit with regard to how what my time outs are and some of these other sort of performance settings there locked there, they're there. It's part of the opinionated set of components that builds up the docker engine is that we bring in the Swarm Kit project with a certain set of defaults and settings. And that is how it operates in today's version of Docker engine. >>Uh, okay for that, that makes sense. That makes sense. So ah, so don, I know you have pretty strong feelings about this topic, but it is swarm still viable in a world that's sort of increasingly dominated by Kubernetes. >>Absolutely. And you were right. I'm very passionate about this topic where I work. We're we're doing almost all of our production work lives on swarm we only have out of Ah, we've got something like 600 different services between three and 4000 containers. At any given point in time. Out of all of those projects, all of those services we've only run into two or three that don't kind of fit into the opinionated model of swarm. So we are running those on KUBERNETES in the same cluster using Moranis is Docker enterprise offering. But, um, no, that's a very, very small percentage of services that we didn't have an answer for in swarm with one. The one case that really gets us just about every time is scaling state full services. But you're gonna have very few staple services in most environments for things like micro service architecture, which is predominantly what we build out. Swarm is perfect. It's simple. It's easy to use you, don't you? Don't end up going for miles of yamma files trying to figure out the one setting that you didn't get exactly right? Um yeah, the other Thea the other big piece of it that way really led us to adopting it so heavily in the beginning is, you know, the overlay network. So your networks don't have to span the whole cluster like they do with kubernetes. So we could we could set up a network isolation between service A and service B, just by use using the built in overlay networks. That was a huge component that, like I said, let us Teoh adopting it so heavily when we first got started. >>Excellent. You look like you're about to say something in a >>Yeah, I think that speaks to the design goals for each piece of software. On the way that I've heard this described before is with regard to the networking piece the ah, the docker networking under the hood, um, feels like it was written by a network engineer. The way that the docker engine overlay networks communicate uses ah, VX lan under the hood, which creates pseudo V lands for your containers. And if two containers aren't on the same Dylan, there's no way they can communicate with each other as opposed to the design of kubernetes networking, which is really left to the C and I implementation but still has the design philosophy of one big, flat sub net where every I p could reach every other i p and you control what is allowed to access, what by policy. So it's more of an application focused Ah design. Whereas in Docker swarm on the overlay networking side, it's really of a network engineering sort of focus. Right? >>Okay, got it. Well, so now how does all this fit in with Docker enterprise now? So I understand there's been some changes on how swarm is handled within Docker Enterprise. Coming with this new release, >>Docker s O swarm Inside Docker Enterprise is represented as both the swarm classic legacy system that we shift way back in 2014 on and then also the swarm mode that is curly used in the docker engine. Um, the Swarm Classic back end gives us legacy support for being able to run unmanaged plane containers onto a cluster. If you were to take Docker ce right now, you would find that you wouldn't be able to just do a very basic docker run against a whole cluster of machines. You can create services using the swarms services, a p I but, um, that that legacy plane container support is something that you have to set up external swarm in order to provide. So right now, the architecture of Docker Enterprise UCP is based on some of that legacy code from about five or six years ago. Okay. Ah, that gives us ability to deploy plane containers for use cases that require it as well as swarm services for those kinds of workloads that might be better served by the built in load balancing and h A and scaling features that swarm provides. >>Okay, so now I know that at one point kubernetes was deployed within Docker Enterprise as you create a swarm cluster and then deploy kubernetes on top of swarm. >>Correct? That is how the current architecture works. >>Okay. All right. And then, um what is what is where we're going with this like, Are we supposed to? Are we going to running Swarm on top of kubernetes? What's >>the the design goals for the future of swarm within branches? Stocker Enterprise are that we will start the employing Ah, like kubernetes cluster features as the base and a swarm kit on top of kubernetes. So it is like you mentioned just a reversal of the roles. I think we're finding that, um, the ability to extend kubernetes a p I to manage resource is is valuable at an infrastructure and platform level in a way that we can't do with swarm. We still want to be able to run swarm workloads. So we're going to keep the swarm kit code the swarm kit orchestration features to run swarm services as a part of the platform to keep the >>got it. Okay, so, uh, if I'm a developer and I want to run swarm, but my company's running kubernetes what? What are my one of my options there? Well, I think >>eight touched on it pretty well already where you know, it depends on your design goals, and you know, one of the other things that's come up a few times is Thea. The level of entry for for swarm is much, much simpler than kubernetes. So I mean, it's it's kind of hard to introduce anything new. So I mean, a company, a company that's got most of their stuff in kubernetes and production is gonna have a hard time maybe looking at a swarm. I mean, this is gonna be, you know, higher, higher up, not the boots on the ground. But, um, you know, the the upper management, that's at some point, you have to pay for all their support, all of it. What we did in our approach. Because there was one team already using kubernetes. We went ahead and stood up a small cluster ah, small swarm cluster and taught the developers how to use it and how to deploy code to it. And they loved it. They thought it was super simple. A time went on, the other teams took notice and saw how fast these guys were getting getting code deployed, getting services up, getting things usable, and they would look over at what the innovation team was doing and say, Hey, I I want to do that to, uh, you know, so there's there's a bunch of different approaches. That's the approach we took and it worked out very well. It looks like you wanted to say something too. >>Yeah, I think that if you if you're if you're having to make this kind of decision, there isn't There isn't a wrong choice. Ah, it's never a swarm of its role and your organization, right? Right. If you're if you're an individual and you're using docker on your workstation on your laptop but your organization wants to standardize on kubernetes there, there are still some two rules that Mike over Ah, pose. And he's manifest if you need to deploy. Coop resource is, um if you are running Docker Enterprise Swarm kit code will still be there. And you can run swarm services as regular swarm workloads on that component. So I I don't want to I don't want people to think that they're going to be like, locked into one or the other orchestration system. Ah, there the way we want to enable developer choice so that however the developer wants to do their work, they can get it done. Um Docker desktop. Ah, ships with that kubernetes distribution bundled in it. So if you're using a Mac or Windows and that's your development, uh, system, you can run docker debt, turn on your mode and run the kubernetes bits. So you have the choices. You have the tools to deploy to either system. >>And that's one of the things that we were super excited about when they introduced Q. Burnett ease into the Docker Enterprise offering. So we were able to run both, so we didn't have to have that. I don't want to call it a battle or argument, but we didn't have to make anybody choose one or the other. We, you know, we gave them both options just by having Docker enterprise so >>excellent. So speaking of having both options, let's just say for developers who need to make a decision while should I go swarm, or should I go kubernetes when it sort of some of the things that they should think about? >>So I think that certain certain elements of, um, certain elements of containers are going to be agnostic right now. So the the the designing a docker file and building a container image, you're going to need to know that skill for either system that you choose to operate on. Ah, the swarm value. Some of the storm advantage comes in that you don't have to know anything beyond that. So you don't have to learn a whole new A p I a whole new domain specific language using Gamel to define your deployment. Um, chances are that if you've been using docker for any length of time, you probably have a whole stack of composed files that are related to things that you've worked on. And, um, again, the barrier to entry to getting those running on swarm is very low. You just turn it on docker stack, deploy, and you're good to go. So I think that if you're trying to make that choice, if you I have a use case that doesn't require you to manage new resource is if you don't need the Extensible researchers part, Ah, swarm is a great great, great viable option. >>Absolutely. Yeah, the the recommendation I've always made to people that are just getting started is start with swarm and then move into kubernetes and going through the the two of them, you're gonna figure out what fits your design principles. What fits your goals. Which one? You know which ones gonna work best for you. And there's no harm in choosing one or the other using both each one of you know, very tailor fit for very various types of use cases. And like I said, kubernetes is great at some things, but for a lot of other stuff, I still want to use swarm and vice versa. So >>on my home lab, for all my personal like services that I run in my, uh, my home network, I used storm, um, for things that I might deploy onto, you know, a bit this environment, a lot of the ones that I'm using right now are mainly tailored for kubernetes eso. I think especially some of the tools that are out there in the open source community as well as in docker Enterprise helped to bridge that gap like there's a translator that can take your compose file, turn it into kubernetes. Yeah, Mel's, um, if if you're trying to decide, like on the business side, should we standardize on former kubernetes? I think like your what? What functionality are you looking at? Out of getting out of your system? If you need things like tight integration into a ah infrastructure vendor such as AWS Azure or VM ware that might have, like plug ins for kubernetes. You're now you're getting into that area where you're managing Resource is of the infrastructure with your orchestration. AP I with kube so things like persistent volumes can talk to your storage device and carve off chunks of storage and assign those two pods if you don't have that need or that use case. Um, you know, KUBERNETES is bringing in a lot of these features that you maybe you're just not taking advantage of. Um, similarly, if you want to take advantage of things like auto scaling to scale horizontally, let's say you have a message queue system and then a number of workers, and you want to start scaling up on your workers. When your CPU hits a certain a metric. That is something that Kubernetes has built right into it. And so, if you want that, I would probably suggest that you look at kubernetes if you don't need that, or if you want to write some of that tooling yourself. Swarm doesn't have an object built into it that will do automatic horizontal scaling based on some kind of metric. So I always consider this decision as a what features are the most I available to you and your business that you need to Yep. >>All right. Excellent. Well, and, ah, fortunately, of course, they're both available on Docker Enterprise. So aren't we lucky? All right, so I am going to wrap this up. I want to thank Don Bauer Docker captain, for coming here and spending some time with us and eight of Manzini. I would like to thank you. I know that the the, uh, circumstances are less than ideal here for your recording today, but we appreciate you joining us. Um and ah, both of you. Thank you very much. And I want to invite all of you. First of all, thank you for joining us. We know your time is valuable and I want to invite you all Teoh to take a look at Docker Enterprise. Ah, follow the link that's on your screen and we'll see you in the next session. Thank you all so much. Thank you. >>Thank you, Nick.

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