DUSTIN KIRKLAND: Hello, I'm Dustin Kirkland, product
manager at Google, here at KubeCon Copenhagen.
And I'm joined by one of my colleagues, Dan Ciruli,
product manager for Istio.
Dan, every single session about Istio
here is packed, people falling out of the room.
Why is there so much excitement about the Istio project?
DAN CIRULI: Well, I think that the people who have been
adopting Kubernetes-- and now, four years in, we've got
a bunch of people who are using it--
have realized that when you're deploying
lots of things in lots of containers,
there's lots of communication between those containers
and traffic into those containers.
And Istio helps them with that traffic.
When you've got all that traffic,
you need to monitor it, see what's
going on in your application.
You need to control it, where all the requests are going,
and of course, you need to secure it.
And people realized, as they adopted Kubernetes,
that there wasn't anything in the ecosystem that did
all of those things for them.
So Istio, they see us as what will be the solution for all
those problems.
DUSTIN KIRKLAND: That's great.
So people talk about the zero problems
of standing up a Kubernetes, and we help with that with GKE.
People talk about day one, day two problems
getting those upgraded.
What you're talking about is really a step beyond that.
Now you've got a Kubernetes.
How do you keep the interesting workloads
working on top of Kubernetes?
DAN CIRULI: Yeah, really, it's giving
a bunch of the tools that are similar to what
RSREs have in operating services at Google.
One of our first-- in fact, the first customer
to go into production on Istio was Descartes Labs.
They run a GKE.
And they love the move to micro services,
but they found that after they had adopted it,
when things slowed down and when their app wasn't running well,
they had no idea why.
And they had multiple dependencies
between their services and no real way
to figure out what those were or which
ones were causing the problems.
So they were an early adopter of Istio,
and they instantly had a service graph to tell them
where their dependencies were.
But most importantly, they had the golden metrics.
They could see what was going on.
They could see where the high load
traffic was, where the latencies were,
so they could solve the problems.
DUSTIN KIRKLAND: So Istio must touch a lot of different layers
in Kubernetes, certainly networking, security, maybe
storage.
Can you just talk a little bit about Istio interacts
with the rest of Kubernetes?
DAN CIRULI: Well, ultimately, it's
built on top of Kubernetes.
We run our services in Kubernetes.
We're dependent on the API server.
And really, the Kubernetes API server is--
everything that's building on top of Kubernetes
is using the API server.
We are replacing or offering alternative
as an ingress, Istio ingress, featuring the envoy proxy,
which is a really, really fast, very powerful proxy
that a lot of people are using.
And yeah, we're building on top of that great Kubernetes
ecosystem.
DUSTIN KIRKLAND: It's all about the APIs, then.
Having good, clean, well-defined APIs
and adhering to those APIs.
DAN CIRULI: Yeah, and what's interesting about that
is that Istio itself helps to govern those APIs.
So I think these two projects are going to go together
really, really well.
DUSTIN KIRKLAND: And where do you
see Istio going next, as we look out to the next six months
or so?
Can you give us a hint?
DAN CIRULI: Well, we're at version 0.7 right now.
We are fast approaching, we hope, 1.0.
We've got about 10 companies that we
know of in production today, and so the code is getting there.
We've got stability in our API.
So we're getting ready to declare 1.0.
And when we do that, I think we're going
to see a wave of adoption.
And that's going to be really exciting.
We'll see the ecosystem start to build.
We've got a lot of partners who are building integrations
right now.
So I see us going from very early adopters to more
mainstream adoption and a big ecosystem building around it.
DUSTIN KIRKLAND: And what's the last hard problems
to solve before getting to that proverbial 1.0?
Can you give us a sense of like, what's
the big thorny issues on your mind?
DAN CIRULI: Performance is an issue.
We need to make sure that people understand exactly how
much latency will this add, how much more compute
is it going to add.
We've got the APIs pretty stable right now.
We need to make sure it is stable at scale.
Although we do have--
weather.com is running it at about 400,000 requests
a second.
So we were already getting into pretty good production
stability there.
DUSTIN KIRKLAND: And I was going to ask you
about scale, actually.
You jumped one step ahead of me here.
But 400,000 containers-- all right, sorry, 400,000 requests
per second is outstanding.
Does this deal help stave off some of the work
that someone might have to do otherwise, without a service
mesh in place to help with that sort of scalability of traffic?
DAN CIRULI: What it does to your scalability of traffic--
it allows you to understand your system better.
Today, too many people are scaling pods
on things like memory consumption
or CPU, when in reality, what you
might want to scale on is the amount of traffic
that you're getting or what your latencies are doing.
And so it's actually giving better tools
to your operators to be able to run those systems better.
DUSTIN KIRKLAND: Gotcha.
So earlier today, we've just heard about the Stackdriver
announcements.
Can you tell us about how Istio and Stackdriver might interact?
DAN CIRULI: Well, we already have, in open source,
a mixer plug-in.
Mixer's one of the components of Istio that gathers telemetry.
A plug-in today that will send all of your Istio telemetry
to Stackdriver.
We've got some really interesting things
in the works with that team right now, some
stuff that we can't talk about, but they announced
this Kubernetes thing.
We're already working on the next big thing with those guys.
DUSTIN KIRKLAND: OK, last question.
Security is on everyone's mind.
How does Istio help improve the security model, or the policy
model, around Kubernetes itself?
DAN CIRULI: It gives everyone a standard way, and an easy way--
first of all, an easy way to get MTLS on every call.
We believe in a defense in-depth strategy,
and even if your perimeter is secure,
you should be securing every single call.
So MTLS lets you identify every single call that gets made,
and that, in turn, lets you put an authorization policy on it.
So it allows everyone in the world
to do what we do at Google, which
is every single call is strongly authenticated and authorized.
And as I said, it's a defense in-depth strategy
that can't be beat.
DUSTIN KIRKLAND: That's really well thought out.
Thanks, Dan.
Appreciate your time.