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