♪ upbeat music ♪
>> Announcer: Live from Vancouver, Canada.
It's The Cube
covering Openstack Summit North America, 2018.
Brought to you by Red Hat,
The Open Stack Foundation,
and it's ecosystem partners.
>> Welcome back to The Cube's coverage
of Openstack Summit 2018 in Vancouver.
I'm Stu Miniman with cohost of the week, John Troyer.
Happy to welcome back to the program Stephan Fabel,
who is the Director of Ubuntu
product and development at Canonical.
Great to see you.
>> Yeah, great to be here, thank you for having me.
Alright, so, boy, there's so much going on at this show.
We've been talking about
doing more things
and in more places,
is the theme that the Open Stack Foundation put into place,
and we had a great conversation with Mark Shuttleworth,
and going to dig in a little bit deeper
on some of the areas with you.
>> Stephan: Okay, absolutely.
>> So we have the Cube, and we're go into all of the
Kubernetes, Kubeflow, and all those other things
that we'll mispronounce how they go.
>> Stephan: Yes, yes, absolutely.
>> What's your impression of the show first of all?
>> Well I think that it's really, you know,
there's a consolidation going on, right?
I mean, we really have the people who are serious about
open infrastructure here, serious about OpenStack.
They're serious about Kubenetes.
They want to implement,
and they want to implement at a speed that
fits the agility of their business.
They want to really move quick with the upstream release.
I think the time for enterprise hardening delays
and inertia there is over.
I think people are really looking at the core of OpenStack,
that's mature, it's stable, it's time for us to kind of
move, get going, get success early, get it soon, then grow.
I think most of the enterprise,
it's mostly customers we've talked to
adopt that notion.
One of the things that sometimes helps is
help us lay out the stack a little bit here
because we actually commented that
some of the base infrastructure pieces
we're not talking as much about
because they're kind of mature,
but OpenStack very much at the infrastructure level,
your compute, storage, and network need to understand.
But then we when we start doing things
like Kubernetes as well,
I can either do or, or on top of,
and things like that, so give us your view as to
what'd you put, what Canonical's seeing,
and what customers-- how you lay out that stack?
>> I think you're right, I think there's a little bit
of path-finding here that needs to be done
on the Kubernetes side,
but ultimately, I think it's going to really converge around
OpenStack being operator-centric, and operator-friendly,
working and operating the infrastructure,
scaling that out in a meaningful manner,
providing multitenancy to all the different departments.
And then having Kubernetes be developer-centric
and really help to onboard and accelerate the workload
that option of the next gen initiatives, right?
So, what we see is
absolutely a use case for
Kubernetes and OpenStack to work perfectly well together,
be an extension of each other,
possibly also sit next to each other
without being too
incumbent there.
But I think that ultimately having something like
Kubernetes container based developer APIs
that are providing that orchestration layer
are the next thing,
and they run just perfectly fine on Canonical OpenStack.
>> Yeah, there certainly has been a lot of talk
about that here at the show.
Let's see, let's go a level above that,
things we run on Kubernetes,
I wanted to talk a little bit about ML and AI and Kubeflow.
It seems like we're, I'd almost say that we're,
this is like, if we were a movie,
we're in a sequel like,
AI-5; this time, it's real.
I really do see real enterprise applications
incorporating these technologies into the workflow
for what otherwise might be kind of boring,
you know, line of business,
can you talk a little bit about
where we are in this evolution?
>> You mean, John, only since we've been talking about it
since the mid-1800s, so yeah.
>> I was just about to point that out,
I mean, AI's not new, right?
We've seen it since about 60 years.
It's been around for quite some time.
I think that there is an unprecedented amount of
sponsorship of new startups in this area, in this space,
and there's a reason why this is heating up.
I think the reason why ultimately it's there is because
we're talking about a scale that's unprecedented, right?
We thought the biggest problem we had with devices
was going to be the IP addresses running out,
and it turns out, that's not true at all, right?
At a certain scale, and at a certain distributed nature
of your rollout, you're going to have to deal with
just such complexity and interaction between the
underlying, the under-cloud, the over-cloud,
the infrastructure, the developers.
How do I roll this out?
If I spin up 1000 BMs over here,
why am I experiencing dropped calls over there?
It's those types of things that need to be correlated.
They need to be identified, they need to be worked out,
so there's a whole operator angle just to be able to cope
with that whole scenario.
I think there's projects that are out there
that are trying to ultimately address that,
for example, Acumos
at Linux Foundation.
Then, there is, of course, the new applications, right?
Smart cities to connect to cars,
all those car manufacturers who are, right now,
faced with the problem: how do I deal with mobile,
distributed inference rollout on the edge
while still capturing the data continually,
train my model, update, then again,
distribute out to the edge to get a better experience?
How do I catch up to some of the market leaders
here that are out there?
As the established car manufacturers are going to
come and catch up, put more and more miles autonomously
on the asphalt, we're going to basically have to
deal with a whole lot more of productization of
machine-learning applications that
just have to be managed at scale.
And so we believe,
we're also in good company in that belief,
that having to manage
large applications at scale,
that containers and Kubernetes
is a great way to do that, right?
They did that for web apps.
They did that for the next generation applications.
This is one example where with the right operators
in mind, the right CRDs, the right frameworks
on top of Kubernetes managed correctly,
you are actually in a great position
to just go to market with that.
>> I wonder if you might have a customer example that
might be able to walk us through kind of
where they are in this discussion, talk to many companies,
you know, the whole IOT even pieces were early in this.
So what's actually real today, how much is planning,
is this years we're talking before
some of these really come to fruition?
>> So yeah, I can't name a customer,
but I can say that every single car manufacturer
we're talking to is absolutely interested in
solving the operational problem of running
machine-learning frameworks as a service,
making sure those are up running and up to speed
at any given point in time, spin them up in
a multitenant fashion, make sure that the GPU
enablement is actually done properly
at all layers of the virtualization.
These are real operational challenges that they're
facing today, and they're looking to solve with us.
Pick a large car manufacturer you want.
>> John: Nice.
We're going down to something that I can type on
my own keyboard then, and go to GitHub, right?
That's one of the places to go where it is run,
TensorFlow of machine-learning framework on Kubernetes
is Kubeflow, and you demo'd that
a little bit yesterday on stage,
you want to talk about that maybe?
>> Oh, absolutely, yes.
That's the core of our current strategy right now.
We're looking at Kubeflow as one of the key enablers of
machine-learning frameworks as a service
on top of Kubernetes, and I think they're a great example
because they can really show how that as a service
can be implemented on top of a virtualization platform,
whether that be KVM, pure KVM, on bare metal,
on OpenStack, and actually provide machine-learning
frameworks such as TensorFlow, Pipe Torch, Seldon Core.
You have all those frameworks being supported,
and then basically start mix and matching.
I think ultimately it's
so interesting to us because
the data scientists are really not the ones that are
expected to manage all this, right?
Yet they are the core of having to interact with it.
In the next generation of the workloads,
we're talking to PHDs and data scientists that
have no interest whatsoever in understanding
how all of this works on the back end, right?
They just want to know
this is where I'm going to submit my artifact
that I'm creating,
this is how it works in general.
Companies pay them a lot of money to do just that,
and to just do the model
because that's where,
until the right model is found,
that is exactly where the value is.
>> So Stephan, does Canonical go talk to the data scientists,
or is there a class of operators who are
facilitating the data scientists?
>> Yes, we talk to the data scientists
to understand their problems,
we talk to the operators to understand their problems,
and then we work with partners such as Google
to try and find solutions to that.
>> Great.
What kind of conversations
are you having here at the show?
I can't imagine there's too many of those,
great to hear if there are, but where are they?
I think everybody here knows containers,
very few know Kubernetes,
and how far up the stack of building new stuff are they?
>> You'd be surprised, I mean,
we put this out there, and so far,
I want to say the majority of the customer conversations
we've had took an AI turn and said,
this is what we're trying to do next year,
this is what we're trying to do later in the year,
this is what we're currently struggling with.
So glad you have an approach because otherwise,
we would spend a ton of time thinking about this,
a ton of time trying to solve this in our own way
that then gets us stuck in some deep end
that we don't want to be.
So, help us understand this, help us pave the way.
>> John: Nice, nice.
I don't want to leave without talking also about Microcades,
that's a Kubernetes Snap, some code you download,
Can we talk a little bit about that?
>> Yeah, glad to.
This was an idea that we conceived that came out of
this notion of alright, well if I do have,
talking to a data scientist,
if I do have a data scientist, where does he start?
>> Stu: Because Kubernetes has a learning curve.
>> It does, yeah, it does.
So here's the thing,
as a developer, you have, what options do you have
right when you get started?
You can either go out and get a community stood up
on one of the public clouds, but
what if you're in the plane, right?
You don't have a connection,
you want to work on your local laptop.
Possibly, that laptop also has a GPU,
and you're a data scientist and you want to try this out
because you know you're going to submit this
training job now to a cluster
that runs on prem behind the firewall
with a limited training set, right?
This is the situation we're talking about.
So ultimately, the motivation for creating Microcades was
we want to make this very, very equivalent.
Now you can deploy Kubeflow on top of Microcades today,
and it'll run just fine.
You get your TensorBoard, you have Jupyter notebook,
and you can do your work, and you can do
it in a fashion that will then be compatible to your on-prem
and public machine-learning framework.
So that was your original motivation for why
we went down this road, but then we noticed
you know what, this is actually
a wider need.
People are thinking about local Kubernetes
in many different ways.
There are a couple of solutions out there.
They tend to be cumbersome, or more cumbersome
than developers would like it.
So we actually said, you know, maybe we should
turn this into a more general purpose solution.
So hence, Microcades.
It works like a Snap on your machine,
you kick that off, you have Kubernetes API,
and under 30 seconds or little longer if your
download speed
plays a factor here,
you enable DNS and you're good to go.
>> Stephan, I just want to give you the opportunity,
is there anything in the Queens release that your
customers have been specifically waiting for
or any other product announcements before we wrap?
>> Sure, we're very excited about the Queens release.
We think Queens release is one of the great examples of
the maturity of the code base and really
the nod towards the operator, and that, I think
was the big challenge beyond the olden days of OpenStack
where the operators took a long time for
the operators to be heard,
and to establish that conversation.
We'd like to say and to see that OpenStack Queens
has matured in that respect,
and we like things like Octavia.
We're very excited about low balancing as a service,
taking its own life
and being treated as a first-class citizen.
I think that it was a great decision
of the community to go down that road.
We're supporting it as a part of our distribution.
>> Alright, well, appreciate the update.
Really fascinating to hear about all, you know,
everybody's thinking about it and really starting
to move on all the ML and AI stuff.
Alright, for John Troyer, I'm Stu Miniman.
Lots more coverage here from
OpenStack Summit 2018 in Vancouver.
Thanks for watching The Cube.
♪ upbeat techno music ♪