 Live from San Francisco, California. Extracting the signal from the noise. It's theCUBE, covering DockerCon 2015. Brought to you by SiliconANGLE Media. With special thanks to Docker. Now your hosts, John Furrier and Jeff Frick. Okay, welcome back everyone. We are live in San Francisco. Here, this is theCUBE, our flagship program where we go out to the events and they extract the signal from the noise. I'm John Furrier, my coach Jeff Frick. Our next guest is now a celebrity. Solomon Hikes, the founder and CTO of Docker. We knew you went, we did it first thing before it was called Docker, but welcome back to theCUBE. Great to see you. Thank you, yeah, it's great to be here. Congratulations on all your success and we're big fans. We were saying on the intro, we've talked about this on theCUBE before, about the role of the developer in DevOps Cloud, but the genie's out of the bottle. Cloud computing era is now upon us. The front wave of that change is pretty radical disruption. Innovation cycles are going to be hitting pretty hard over the next 10 years. Developers in DevOps, which was kind of a small community now going mainstream, it's the center of the action. DockerCon represents that movement. So congratulations. Thank you, I'm certainly part of it. So I got to ask you. So, obviously the developers are you for. It's like intoxicating here. I call it the wood stock of developers. People handing out, I said Kool-Aid on Twitter to kind of keep it PG-13, but it really is an environment where everyone's excited. But there's a lot of work to do. I want you to talk about that work. What is going on in your mind around making this go faster? Because at the end of the day, the cost to run an app should be lower in cost every day with DevOps and Cloud. So what's your thoughts on where the app market is from a standardization standpoint to get to that nirvana, that true cloud scale? Yeah, so you're definitely right. There's a lot of work to do. I mean, the way I think about it, we're at the very beginning of an effort throughout the industry that's going to last several years. So, I mean, that's why everyone's so excited. It's, you know, there's this idea that we get to build a new architecture, actually fix these fundamental problems that have been slowing people down. So, you know, in terms of what's left to do, you know, I would say the big- There's a long list on GitHub. Yeah, there's a long list. But you know, if you think about the big picture for a second, I think, you know, the task at hand is building applications that are completely different from applications we built before because they're designed, they're modeled after the internet itself, right? They're designed to run across many different machines across the internet, private infrastructure, public infrastructure. You know, we call these distributed applications. The problem for developers is that they've known for a while that they need to create applications like that because that's what people are asking for, right? They need applications. Everyone expects now they're out to be online all the time, just always work, even if there's millions of people just hitting it. It's going to work from every device. So, the need is there, but the tools are not ready, basically. They're inadequate. So everyone's kind of making it work with the old tools and they're kind of hoping for new tools to come along, but at the same time, they're kind of stuck because no one can throw away their existing stuff, right? It has to be a gradual improvement. So there's this big dilemma of the need for to rebuild everything and the constraints of having existing infrastructure. So there's three buckets we're seeing on the Wikibon research. One is new apps, clean sheet of paper. That's really great. Existing apps and then migration to cloud. So kind of three major buckets where the buyers are actually writing checks. And there's a lot of money on the table, a lot of opportunity. Hey guys, out there, three areas go faster. So that causes a lot of tension in the community because you want to be free with open source. You want to make money and the business model pressures will be coming, not yet, but it will be there. But there's a lot of pressure to get go faster. What's the vibe in the community? Because you're in there, I've seen some of the comments and the threads. It's really positive, but yet there's that good tension in open source right now. What is the dynamic inside the community right now? The biggest dynamic right now, the biggest tension is that is caused by the overlap between two different worlds. There's developers and they have certain needs and then you have operations engineers, IT, and they have different kinds of needs, right? And they need to work together. Together they're building something, but day to day their priorities are different. The developers need to go fast, they need to ship the new feature, they need to be able to reuse past components. So time in the market is super important. Collaboration is super important. Ops care about keeping things running, scale, security, compliance, right? Is it going to break in two months, right? Can I, if I wake up at four in the morning because something's broken, can I just go in there and fix it? And so Docker is at the middle of those two worlds. It's used by both developers and ops. And a lot of the tension you're seeing is simply by demands and priorities that are simply sometimes mutually exclusive. So what we're doing is we're splitting the two efforts so that each area of Docker can focus on the right audience. So the developer, there's a developer toolbox that's focused on the needs of developers and there's what we call plumbing, infrastructure plumbing, which is a set of components focused on the needs of ops. And I think that's going to solve a lot of the tension. The motto is build, run and ship, which is awesome. Talk through some of the things happening that you're excited about because this software is the key here, right? And again, customers don't want to have, you know, three different same functional sets of code running different code bases that kind of create some incompatibility. So forward compatibility is a huge deal. So talk about what's exciting to you that's going to make that happen. So what I'm really excited about is I think we figured out a model for introducing new things that can bring about a new architecture, upgrade the architecture of people's applications and infrastructure, but not force them to throw everything away. So that philosophy, we call it incremental revolution. It's not rocket science, it's basically don't throw everything out at the same time. Yeah, exactly. Or if you do one piece at a time, so that's how we approach the toolbox. We're adding one tool at a time and saying, hey, there's a new tool, it works well with the others, but you're not forced to use all of them now. You can pick and choose and over time you can expand. And we've done that with a bunch of tools, Docker engine, Docker registry, Docker compose, Docker swarm, et cetera, Docker machine, we're just adding them. So what's really exciting to me is two years in, it's working. We see people who started with one, a year later they're using five of the tools. So that moves the needle on adoption. And so we didn't, if we had come in the beginning and said, hey, use this mega platform, you got to throw everything out, they wouldn't have used it, but now they're getting there. And so we're seeing people taking existing apps and upgrading gradually to make them better. So I want to go to a comment. February 13th, you wrote on GitHub, I wrote some DNS mapping namespace issue, I don't want to get into the details. At the end you say, hey, stop the charade, let's go back to competing normally like the rest of the open source world. Because the whole thesis was, why would you have existing different image code bases? Anyway, that was, so that's a philosophy. Hey, let's go back to being grownups, if you will. And then Patrick Riley chimed in, maybe it should be an open container summit or something to address all these issues in the open. So here we are, you have now, you guys put together as an industry consortium, OCP, not to be confused with the OCP in the big data world, but talk about what this is all about, how it all came together, give us the inside color on who's involved, what's the purpose. So it's pretty simple. We built a toolbox for developers and we want to solve one problem for developers at a time. The first problem we solved was repeatable runtime for applications. Same app, same code, you want to run it in lots of machines, you need a runtime that can actually be portable. To do that, we used available technology and one of those technologies is Linux containers, right? We use a lot of other stuff, but containers are kind of the well-known ones, right? And so we just used that and defined a low-level format that the rest of the Docker platform uses for portability and that format, Docker got adopted widely, so that format is now a de facto standard. And over the last six months, we started getting feedback that because it's a de facto standard, we should take responsibility and make that a proper standard, right? And actually provide a real specification, formal specification, not just... Kind of protect it, if you will. Yeah, protect it. And then you open. Yeah, protect it, there's a few things. Not protect it, but you don't say it. No, no, no, you're right. It's protect it from, you know... Being mangled by somebody. Exactly, who knows what can happen. But also make it possible for others to implement those low-level bits. And the thing is Docker is not that low-level container runtime. It does a lot more. And so we don't actually need, it's not in our interest to prevent that. The only barrier to that was just slowing us down. We like to ship stuff. And so we were not in a big hurry to do that. And what happened is a bunch of people put together this proposal for a format and an open specification. So it was great in that it was an open specification. But it did not work with a de facto standard. You guys drinking beer around the table and the proposal comes across the desk. You go, hey, let's do that. I mean, we'll take us through the decision-making. So, well, it was really too, it's very simple. At some point, the volume of requests and complaints about not having a spec and not having a separate low-level tool for running containers prompted us to do it. So we did two things. First, we detached all of the codes, all of the plumbing from Docker that's related to containers. Since Docker, and that's 5% of Docker's code. So the 5% of Docker that has to do with containers, we split up and released yesterday as a tool called Run-C. And so you can use Run-C to do the container part of Docker. And so now people using Docker can use all of Docker. And if you don't want the rest, you just want to use the containers, you can use Run-C. And then on top of that, we announced an open specification based on the format of Run-C for others to implement any other tool like Run-C. And so we defined that spec. We donated it to a foundation called the Open Container Projects with the help of the Linux Foundation. And then we asked around, we asked other vendors that they wanted to join. And we ended up with this coalition of pretty much everybody. And in particular, there was a group that had put together a completely different specification earlier called App-C that was kind of a first concrete proposal on what a specification might look like. The main problem of that specification is not at all compatible with Docker. So basically no one can use it. But it has a lot of really good ideas in there. And the people working on it are really smart. A lot of them also work in Docker, because it's a small world. So we also invited them to join. And so the creators of this App-C project are now joining Open Container Project. It's a great rallying cry. People said, hey, let's just align up. So people who need this specification are happy because they see that there's a standards to build on top of. The people who are worried that a standard would stifle innovation are reassured because the last thing I want is a giant mega bureaucracy that prevents everyone from innovating. This is a very small standard. It does just what you need. But it enables more innovation because then you guys don't have the FUD coming at Docker saying, hey, you're trying to both guard everything. Yeah, exactly. We're happy because people are now focused again on what I think matters most, which is building awesome tools for developers. Well, I personally think that there's a ton of beach head out there. It's early days. And there's so much innovation. Squabbling over scraps is just a waste of time. Does it make sense? Yeah. Okay, so Orca, tell us about Project Orca. It was demoed today on stage. What's that all about? So today, day two of DockerCon, the focus was Docker in production. We showed real commercial users. We showed the US government deploying Docker, being our first commercial customer. And the two aspects of Docker, build, ship, and run these applications, we focused on the commercial products for the build and ship. There's a registry which lets you organize the contents that goes into assembling your application. You can distribute that securely. It's kind of like an internal app store for your enterprise. But there's been a lot of demand for the run part. Okay, I got a great, this great application. How do I use my infrastructure, me, the enterprise, to build a deployment platform that can run all my apps, old and new, in a scalable way? And we just got a lot of demand for that. That's what Project Orca is. So it integrates all of the open source pieces, the Docker engine, swarm, all the pieces that you hear about into a single platform that just runs the app. So ops get all the controls they want. There's a GUI, there's policies, there's scaling, there's troubleshooting. Developers don't need to know what's going on. They just send the app and it works. All right, so talk about, pretend we're at a friend's house and he works for a big company. He's like, hey, Solomon, I heard about this Docker thing and I just got a huge budget from my CIO. I got to essentially transform my enterprise. And we have cool developers and we're going to add more and more develop, we're going to really heavily invest in the transformation over the next five years. I really want to do the right thing. What's this Docker thing all about? How should I be thinking about it? What should my plan be from a development standpoint? Share your thoughts on, because a lot of folks out there really want to understand what the path is. Yeah, well, I think the way I would say, hey, Bob, the problem in the enterprise today, Bob, is that you're solving complicated problems using complicated technology, a lot of it. And whatever you're using today, next year it's going to be different. Some of it's still going to be there. Some of it you're going to need to rip or replace. There's going to be an M&A, there's going to be real organization, whatever. So you have this giant, complicated mess of technologies and tools and vendors. And code, by the way. And code. And soft, actually real soft. Yeah, so it's all thrown in there and you're supposed to make sense of it so that your organization can be competitive so that technology becomes an asset instead of a liability. And so you're supposed to run this ship and provide a kind of a unified platform, a unified view of that. And the problem is that every vendor out there that you're talking to, they're trying to take their product that does whatever and say, oh, that's the platform, right? Take my thing. Yeah, I'm an X shop. Yeah, I only buy X. Use my storage product, well, for storage, but well, just lock yourself onto that. Lock yourself onto this. Especially if there's some big vendors that have a lot of successful products, the big worry from enterprises is, am I going to be stuck with this big vendor forever? Well, even just two years out, if you just say, okay, if I'm a storage only company, my platform was written years ago, before cloud. So BC, before cloud. So Bob is in trouble in the year because now I'm like, okay, will this company be around in two years from a source code base? Yeah, so I have to make a decision. What's the bridge to the future? The metaphor I would say is the problem is we have all these toys and they're too big in their model thing, there's just one thing, I can't change it. And so what Docker brings to the enterprise is basically Lego, right? Small bricks that come in all shapes and sizes, there'll be more bricks later. Whatever the next brick is, you can be excited about it. There's a new spaceship coming out later, but you don't have to worry, oh, do I have to throw away all my existing Lego? No, you don't because you're using Docker, which is an open toolbox that focuses on actually the interfaces and how everything fits together. So Docker's not trying to sell you one particular spaceship. It's saying, hey, can you use Lego? So Bob, I'm Bob here in this example, I say Solomon, but I don't know what I'm going to run on premise and I don't know what I'm going to run on the cloud, so how do I decide? The important thing about Lego, in this metaphor that's Docker, is that it's designed well enough that you can build pretty much anything you want. If you bind to that, and in the case of Docker, that means Docker runs on cloud, it runs on premise, it runs on developers' laptops, it can run Java applications, it can run PHP applications, whatever next language comes along, we'll make sure it can run that too, because that's our expertise, we focus on the right level of abstraction. Great, thank you very much for the consulting, I used to check for the free consulting. Thank you so much on that. Next question is, okay, so the world of the future is a lot of resource out there in the cloud, hopefully software's going to be important on any environment, ton of containers, a lot of virtualization, a lot of stuff out there. How do you manage it? Because it's not a race to zero, everyone said Amazon was a race to zero, certainly commoditizing, you could say is a race to zero, but they're going to do $10 billion in revenue. Now, they do funny math on the balance sheet, but the business model is, the value's going to shift to the apps. So the question is, how do you manage it all? So how am I managing all the containers? Who orchestrates it? I mean, there's so many people out there, there's a lot of noise, what's the signal on the management piece? I think management builds on what we were just talking about around using a standardized toolbox and integrating that with standard interfaces. Once you have that, then you're in control of the management piece. You can, because the objects in your enterprise are now compatible with each other, it's now possible to do things like monitoring of all the pieces in a unified way or security policies and all the pieces. You don't have to silo things. You don't need one management dashboard for VMs, one management dashboard for containers, one management dashboard for whatever comes after containers. And what we're building with Docker is that approach to things. So for example, you were talking about Orca. With Orca, you can deploy your application on VMs and on containers. Docker supports both. With the Docker trusted registry, you can ship assets in there that will run in the cloud, on-premise, whatever, right? So it's really about breaking down silos, I guess. It's pretty excellent. Well, I got to ask you, for the folks watching, what's your take on this show? I mean, just kind of at a core level, what's the vibe? People who aren't here at the show, I mean, obviously it's exciting, what is the most important thing to take out of this week at DockerCon? The people who aren't here, whether it's the mood, it's the excitement, the code, projects, announcements, what would you share as some important takeaways for the folks watching? You know, I mean, this is a personal take, right? But, and it's the same as last year. It was 500 of us last year. It's, I think it's 2,000 this year. It's just very positive, you know, and it's something you find in the online community around Docker also. We worked really hard to make it inclusive, and there's a lot of tech events or there's a subset of the tech scene that uses a lot of, you know, that uses war as a metaphor for everything. You know, the war of this, the war of that, and, and you know- They're dead. This is the killer app. Exactly, exactly. And you know- Something's dead, something's at war. So I think it's easy to forget the reason technology is so exciting and such an important part of society. The reason there's so much money in technology is because it's about building better things and not about, you know- Killing things. Killing things or just making life miserable for someone else, right? Yeah. And so that's why we're here. So it's the Woodstock of, well, I'm showing my age, but there's a new version of Woodstock out there. I don't know, the younger developers, you know, it's got to be some sort of cool, my kids go to the things in, you know, there's different concepts these days. Well, maybe we'll have to work on the live music selection then. Yeah, it's love and peace and it's good, love and peace, I mean, it's what it's all about. It's a love fest. Yeah, you know, it's builders want to build stuff and, you know, left in peace to build cooler stuff and that works for the enterprise, for, you know, hobbyists, startups, whatever. Okay, so what's the implied protocol to keep this love and peace going? Because again, you know, this is a good environment. There's a lot of growth. Again, a lot of beach head. No need to fight over the low-hanging fruits. There's a lot of opportunities, a lot of fertile ground. So how do we keep it going? What is the guiding principles? What are some of the implied protocols in the community? What shouldn't people do? What's the right thing to do? Share your opinion on that. So, well, I think there's two suggestions. One is specific to Docker, which is, you know, since DockerCon is the event for the Docker ecosystem, I would say we want to help the ecosystem as much as possible. The best way to take advantage of this ecosystem is to look at the APIs and interfaces that we're introducing and use them and to not hesitate to come to us and tell us when you're missing an API or it doesn't quite work the way you want. But the more you use the Docker's native APIs, the more we can help you distribute your tools, make them better, et cetera. I would say a wider opinion is simply, you know, the more you focus on building something people want, building a cool product, the better off, you know, the better everything else goes. And so, you know, BizDev's sales marketing are extremely important, but they're a multiplier of how useful and good your product is in the first place. The business model question will figure yourself, value creation's shifting. Final question, two parts. What is the hot programming language that's emerging out of this new normalcy? No JS is out there, Angular's getting a lot of buzz. What's going on with software languages that are popping out? And second part, what is something that you want to share that's not well known that people should know more about around this movement of Docker? Well, I think the two questions are linked actually. There's a lot of cool languages out there. I mean, for low level infrastructure, we use Go obviously, but there's another language called Rust out there that is pretty unique. In mobile, you know, Apple introduced Swift. No JS is going strong. Java, you know, is a cornerstone of a lot of enterprise stacks. You know, I would say, honestly, the takeaway is that if you have a general impression that there's a lot of languages coming out and it seems like there's just more and more choice and confusion, well, you're right. That's what's going on. And it's actually a good thing. So I don't think there's going to be a winner takes all language anytime soon. Whatever the best tool is, doesn't get stuck on a hammer. So exactly, I would say it really depends on the industry you're in. You know, if you're in gaming, you know, there's a little language called Lua, which probably most of the people here have used once or twice, maybe, because this is more of a cloud and, you know, infrastructure, web world. But if you go to a gaming conference, everybody in there writes their scripts in Lua. All right, final, final question. I always have a final, final question. What language should someone wants, a young kid came to me and said, I want to learn a programming language. What one should I start with? To give me the breadth, maybe it's a structured language, something that would be versatile to learn, a good first start, to have some of that breadth so that when they sample or test or maybe fall in love with a certain code, code bay or software base, what was a good starting point? You know, I think a kid could figure out pretty much to get any language to work. I would say the main factor is the learning environment. There's a really excellent book called Learn Python, The Hard Way by Zed Shah. And not that Python is better or worse than other languages for learning, but just because of that book and the methodology behind it, I would say if you're serious about learning programming the right way and building solid foundations, then I would say, read that book and as a result you'll learn Python, but that's okay, you'll learn another program. It's a great tool for data science and exploration. All right, Salma, thanks so much. We've been over time. But again, congratulations on your success. We're looking forward to seeing you in the hallways and of course after the event. Thanks so much. We'll be right back more with theCUBE here at Dr. Khan in San Francisco after this short break.