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