>> Live from the Julia Morgan Ballroom
in San Francisco.
Extracting the signal from the noise,
it's TheCUBE.
Covering Structure 2015.
Now your host,
George Gilbert.
>> This is George Gilbert,
we're at Structure 2015.
Reborn and really healthy
from the old GigaOM,
and we're pleased to welcome Alex Polvi
from CoreOS,
everyone seems to want to talk to Alex these days.
So we've got first dibs.
Alex why don't you tell us a little bit about CoreOS
and why it's of such relevance right now.
>> Sure, so we started CoreOS a little over two years ago,
about two and a half years ago now.
And our mission is to fundamentally improve
the security of the internet.
And our approach in doing that
is to help companies run infrastructure in this way
that allows it to be much more serviceable
and have much better security and so on.
This way that we're modeling
looks a lot like what we've seen
from the hyperscale companies.
Folks like Google.
So we often call it Google's Infrastructure For
Everyone Else,
GIFFY for short 'cause that's kind of a mouthful.
And that involves distributed systems, containers,
and running on standard hardware
which in 2015 can be a bare-metal server,
or could be an instance in AWS.
>> Okay.
So help us understand though that,
if CoreOS,
it sounds like there's an operating system
at the core. >> Yeah.
>> Is this like a cut down version of Linux
that gives it a small attack surface
and a sort of easier deployment and patching?
>> Exactly, so in our quest to
run the world servers to secure the internet
we start at the lowest level component possible.
There's the OS,
then there's the distributed system side.
So CoreOS is our company name,
but it's also the name of the first product
that we released, CoreOS Linux.
CoreOS Linux is a lightweight container-based OS
that automatically updates itself,
'cause we think that updates are the key to good security.
So it's a combination of the updates,
the container weight,
the lightweight container-based application model.
As well as just stripping everything else out.
I mean the last 20 years of Linux distributions
have created lots of cruft
so it was time to kind of
rebirth a new lightweight Linux OS.
>> Sticking to CoreOS >> Yeah.
>> For a moment,
in an earlier era,
might we have called this like an embedded OS
where you just sort of chopped out everything
that was not necessary for the application?
>> Yeah,
it's very much inspired by embedded OSes.
On servers you know,
you really want to get everything out of the way
of the resources like the memory
and CPU and so on
so you get as much as you want out of it.
So while it's a little bit counterintuitive,
you have this really monster server,
you still want as light and thin of an OS
on there as you possibly can
like an embedded OS so you can really maximize
the performance.
>> So something that abstracts the hardware
but gets out of the way.
>> Exactly. Just focus,
get on the things that matter
which is running your applications
and managing the actual hardware
and really nothing else.
>> Okay, so,
presumably to provide Google's infrastructure
for everyone else,
and I don't remember the acronym,
>> GIFFY. >> Okay.
What other products did you have to fill out
to make that possible?
>> Sure, great question.
So the next major piece that we released
is a tool called ETCD.
It's meant for doing shared configuration amongst servers.
Whenever you have a group of servers,
the first thing you need to do
is they all need to know about each other,
and tell each other about the configuration.
This is load balancers knowing where the app servers are,
the app servers knowing where the databases are
and so on.
And to do this in the most robust distributed systems way,
you have to do this thing in computer science
that's very difficult called "consensus".
Consensus algorithms is an area of computing,
actually speaking about here in a little bit
with Eric Brewer,
who is a huge academic,
a very well respected engineer in the area of consenus
and distributed systems.
And so we built ETCD,
which solves this really hard distributed systems problem
in a way that's usable by many operations teams.
>> So let me just interrupt you for a second,
>> Yeah. >> I mean I've got this
sound going off in my head that says "Zookeeper, Zookeeper".
>> Exactly.
It's Zookeeper for everyone else.
>> It's simplified.
>> It's a simplified Zookeeper
and make it accessible.
Areas that a lot of people wanted to use distributed systems
but Zookeeper is a little bit too difficult to use
as well as really oriented toward the Java
and Hadoop community,
and there's a whole wide array of other folks out there.
>> So it couldn't make as many
constraining assumptions as yours,
which would simplify.
>> It just couldn't be as widely adopted.
And so we released ETCD around the same time
we released CoreOS Linux
and this point,
there's been over a thousand projects if you go on GitHub
that have built things around ETCD,
so our bet was right.
Even things like Kubernetes,
itself has a hard dependency on ETCD.
Without ETCD, Kupernetes will not run.
So our hypothesis there was
let's make the hardest part of distributed systems easier,
and then we will see distributed systems overall accelerate.
And that is definitely what's happened with ETCD.
>> Okay so help us understand,
how you've built up the rest of the infrastructure
and then where you'd like to see it go.
>> Sure,
so the thing that we're targeting
is this distributed systems approach.
And again we care about this a lot
because we think that the ability to manage
and service your applications,
is what is the key to the security.
Keeping things up to date,
and when we mean up to date,
we don't just mean like patch a vulnerability.
Of which we've fixed many of those.
But it's also about company's comfort
rolling out a new version of their application
that they won't break something.
If you run your infrastructure in a distributed system,
you can roll out a version,
if it breaks a little bit of the application that's okay,
but you didn't take the whole thing down.
And that's kind of the safety net
that distributed systems give you.
>> Does this require the sort of micro-service approach
where there's a clean separation
between this new set of bits
and the rest of the app?
>> It really does.
And that's why we've invested so heavily in containers.
It requires a container,
it also requires the distributed systems components of it.
So we first built CoreOS Linux,
then we built ETCD,
then we started building some distributed systems work
very early in the market.
And then things like Kubernetes came along,
and we were like,
"Hey, instead of us reinventing all of this stuff
let's partner up with the guys from the Google"
if we're monitoring Google's infrastructure
for everyone else,
let's partner up with the team at Google that built that
and get their solution more widely adopted out
in the world as well.
So the whole platform comes together
as this combination of Kubernetes,
ETCD,
CoreOS Linux,
we have our own container runtime called Rocket,
which we built primarily to address some security issues
in Docker.
And so all of these pieces come together
and what we call that piece when they're all together
is Tectonic.
Tectonic is our product that is that
Google's infrastructure in a box.
>> Okay let me just drop down in the weed for a sec.
Derek Collison calls,
I'm sorry I'm having a senior moment.
And I hope it's not early onset Alzheimer's.
The Docker,
he calls sort of this generation's Tarball,
you know,
like to distribute you know,
just a sort of I guess equivalent of an executable.
Are you providing something that's compatible
or does what's inside the container have to change
to take advantage of the additional services
that's sort of Google-centric.
>> Sure.
So the packaging, that Tarball piece,
we're compatible with.
And will always remain compatible with.
To even further the compatibility,
we've put together standards
around what that container should be
so many vendors can inter-operate more widely.
We've done that first through the app container project
and then more recently through the open container initiative
which is a joint effort between Docker and us,
and the rest of the ecosystem.
And so we always,
we always want the user to be able to
package their application once
and then choose whatever system they want to run it in,
and the container is what really unlocks that portability.
>> Okay.
So then let me ask you,
does the Google compute engine folks,
or the passgroup,
do they view you as a way of priming the pump
outside the Google ecosystem
to get others using their sort of
application model or their infrastructure model?
Because I'm trying to understand,
you know Azure sort of has its own way
of looking at the world,
Amazon has its own way of looking at the world,
are they looking at you as a way of
sort of disseminating an approach to building applications?
Or managing applications.
>> Sure.
So the Google team
and their motivations behind Kubernetes,
you'd have to talk to them about it.
My understanding is that they see that as a way
to have a very consistent environment
between different cloud providers and so on.
It is a next-generation way of running infrastructure
as well,
and its just better than the previous way
of running infrastructure.
>> That's sort of the answer I was looking for which is,
they don't have to either give away their stuff
or manage their infrastructure elsewhere.
But you're sort of the channel to deliver
Google style infrastructure in other environments.
>> Sure, I mean Google Cloud's motivation
at the end of the day is selling cores of memory.
They put all these other services on top of it
to make it,
to make it more attractive to use,
but the end of the day anything that drives more usage
of these products is how they run their business.
At least that's my perception of it.
I'm obviously not speaking on behalf of Google.
>> So where are you in attracting showcase customers?
Guys who've sort of said
"okay we'll bet",
if not the entire business,
"we'll bet the success of this application
or these set of applications on this".
>> Right,
so first the technology's been very, very exciting.
I mean the past two years we've seen
this whole space explode in interest,
but the discussion around
"how does this solve business problems,
how does this actually get adopted to these companies
and what motivates them to actually do this"
outside of the tech being very cool.
That's a discussion that
is just getting started
and in fact in about two weeks here
in early December in New York
we're hosting that discussion
at an event called the Tectonic Summit.
The Tectonic Summit is where we're bringing together
all the enterprise early adopters
that are using containers,
using distributed systems,
and talking about why did their management
and their leadership decide to make investments
in these technologies.
And what we're seeing are use cases
about multi-data center between
your physical data center and your cloud environments.
We're seeing folks build their
next-generation web services.
Many businesses that weren't traditionally
in the web services businesses need to be now
because of mobile, just modern product offerings.
And so we're hearing from these large guys
and how they're using our technologies
and other companies' technologies today to do this,
and it's just two weeks at our event.
>> Would it be fair to say,
I'm listening to this and what seems to becoming across is
that your technology makes it easier to abstract
not just the machine, which would be CoreOS,
but hybrid infrastructure.
And it doesn't even have to be hybrid,
it could be this data center
and that data center. >> Right.
>> Or your own data center
and a public cloud. >> Exactly.
One of the biggest value props of all this
is the consistency between environments.
We just give this compute, CPUs, memory, storage,
we don't care if it's on cloud
or if it's a physical data center,
we can allow you to manage that
in an extremely consistent way.
Not just between your data centers
but also between development and production,
and that's a really important part of all of this.
>> Do you need a point of view
built into the infrastructure
to make it palatable to developers
who want a platform?
As opposed to just infrastructure.
>> Sure.
So one of the things that's most exciting about this space
is we're splitting the difference of
platform and infrastructure.
Platform is typically, platform is a service,
this very prescriptive way of running your
server infrastructure.
And there's raw infrastructure which is a like,
"here is a canvas, go to town but you need to
bring all your own tools".
What's happening right now in this
distributed systems container space is a middle category.
It's still infrastructure,
but it's application focused.
And at the end of the day that's what a developer
is trying to do, is deploy their application
out into the server infrastructure.
>> So it doesn't have an opinion that tells the developer
"we think you should build it this way",
but it does hide all the sort of,
the different types of hardware
and their location pretty much.
>> Right, it gives you a prescriptive way
to how you package and deploy that,
but doesn't put on any constraints of
what you can package or deploy.
>> Okay. Very interesting.
It's sort of like a,
if platform as a service was constraining
because developers didn't want a straightjacket
for how they should build the app,
and infrastructures, our service was too raw.
You're giving them a middle ground.
>> Exactly.
It's still infrastructure,
but it's a consistent way of running that infrastructure.
And that's why companies like Google
and Facebook and Twitter do this,
they have millions of servers and data centers
all over the world.
>> And they can't prescribe.
>> Well they need to be able to have
a consistent way of doing it
so that they don't have to have an infinitely growing
operations team as they scale their infrastructure.
You need to have consistency,
but at the same time you need to be able to have
a wide array of tools and things to deploy
and interact with that infrastructure.
So it's that middle ground,
and that's why the hyperscale guys have adopted it
because they're forced to,
because they have to have that consistency
to have that scale.
>> Okay let me ask you then,
not on the,
separate from the hyperscale guys,
the sort of newest distributed system
that mainstream enterprises are struggling with
and sort of off the record,
maybe choking on, you know is Hadoop.
Because they haven't had to do elastic infrastructure before
and like you said the Zookeeper is
not that easy,
and there's 22 other projects
by the way that also have to get stood up.
Can you help someone who is perhaps flailing in that
or if not flailing,
finding the skills overhead really, really tough?
>> So, Hadoop.
Let's remember Hadoop's roots.
Where did that come from?
>> Well Yahoo!.
>> Well but where did Yahoo! get the idea?
>> Oh yeah, Google, sorry.
>> Exactly.
Yahoo! gets all the credit for it.
Even though it was a Google paper that was modeled after.
And so again,
if Kubernetes and containers and everything
is the equivalent of Google's borg,
which is that raw application infrastructure,
Hadoop is a certain application that consumes
the spare resources on that cluster
in order to do these map reducing computational jobs.
>> So the next question is,
how much can you simplify what mainstream enterprises do
that don't have the Google infrastructure yet?
>> Right, so they have to manage that
as its own whole separate thing.
It's its own set of infrastructure,
it's its own set of servers to manage their Hadoop cluster.
If you combine it with this application infrastructure,
we just treat Hadoop as another application
that runs on the platform.
It's not its own distinct, special thing.
It's just another application running out there
along with your web servers
and your databases,
and everything else,
you have your Hadoop workload in the mix.
So you have this consistent pool of infrastructure
and Hadoop is just another application
that's monitored or managed the exact same way
as everything else.
>> So,
for folks who are a little more familiar with Mesos,
which is the opposite of a virtual machine,
it makes many machines look like a single one,
I assume.
>> Well this is a very similar message to Mesos.
Mesos is also building Google-like infrastructure
for everyone else.
The difference with what we're doing
is really we just partnered up with the team
that built that at Google,
and focusing our solution around Kubernetes
which is what the Google efforts are behind.
So we're all modeling Google's infrastructure.
>> Okay. >> Mesos took their own
spin on it with Kubernetes,
and CoreOS and ETCD,
we're taking a different spin on it.
>> So and what other products have you built out
that we haven't touched on,
and what do you see the roadmap looking like?
>> Sure, so really,
all these things we've talked about
are open source projects.
They're all components for building
this Google-like infrastructure.
Tectonic is our platform for companies
that want this style of infrastructure
but they don't want to have to figure out
all the different pieces themselves.
And we think once companies adopt Tectonic,
just this general style of infrastructure,
that we can give them all the benefits of this,
better utilization,
that consistency,
easier management of lots and lots
of servers and so on.
But we also think we can dramatically improve
the security of their infrastructure as well.
And that's what we're investing in our roadmap
is to leverage this kind of change,
and then with that change we can do some things
to the infrastructure that was never possible before.
>> Okay. >> And that's the things
that we're investing in as a company.
>> Okay, great.
We're going to break at that,
this is George Gilbert,
at Structure '15,
with Alex Polvi of CoreOS.
And we'll be back in just a few minutes.
(light music)