>> I'm Lachie Evenson.
>> I'm William Morgan.
>> This is The Open Source Show.
[MUSIC]
>> I'm Lachie Evenson, a PM at Azure.
>> I'm William Morgan, one of the creators of Linkerd.
>> Okay, William, service meshes.
>> Yes.
>> We have a service mesh, okay?
We've made it this far.
Where do we go from here with service meshes?
>> Well, the moment you have
a service mesh, you solve all the problems.
>> Right, obviously.
>> So everything. So that's really all there is to it.
>> So who are the people that are
operating the service mesh itself?
I get the developer use case and the developer workflow,
but who do you see in the wild as
the people that are actually responsible for the service mesh?
>> Yeah. So in our experience,
the role or the title is a little
different depending on which company you're in,
but it typically falls under this role of the platform owner.
It's the same person who's bringing in things like Kubernetes and
Docker and CI/CD system,
they're building this internal platform for their developers,
and the developers are going to run their code on it.
This is a person who is not only picking the service mesh,
but also has to operate it and is on the hook for it.
It is worrying about the health of it.
>> So what kind of problems are they coming across in terms of,
they have the service mesh, they are responsible for it?
>> So the service mesh is new enough
that it's still falling into the category of,
oh, this is a new thing and whenever something breaks,
I'm going to blame the service mesh.
So that's a lot of the motivation for us adding
as much diagnostics as we can to the Linkerd.
So when things are behaving in a strange unexpected way,
you can actually dig in.
The service mesh sits at
the intersection of all these different layers,
the needs the underlying layer four,
layer three, layer four network to be in place,
needs the applications to be behaving,
needs an orchestrator to be orchestrating things.
If any of those things go wrong,
then the behavior that you see out
of the service mesh can be strange,
and then you have to understand, okay,
where's the source of the problem.
>> Right. So can you actually use
the service mesh to monitor the service mesh?
>> Yes. Great question. So the first time you install Linkerd,
before you've added the data plane
anywhere and you boot up the dashboard,
the only thing you see is the control plane
there because the control plane
runs its own data plane that's
part of it and you can use that to inspect.
Okay, here are all the different components of the control plane,
here's their success rate,
here's a request volume, here's latency,
and that's one of the basic ways of
understanding what the health of the service mesh.
>> Okay. So if I have a problem,
one common thing that I would like to know is,
how do I isolate at what point the system is broken?
How do I actually isolate quickly and
easily where exactly the problem might lie?
>> Well, this is one of the things that
the service mesh can actually really help with.
Because one of those components that we talked about
in the early part of this was the visibility layer.
What Linkerd can add is a layer of what we call golden
metrics across each of
your services and visibility into things like,
success rate, and latency distribution,
and we can do it in a way where you don't have to modify
the application at all to get those metrics.
We can paint a picture of what the health is
of each of the services in your application.
In fact, we can even draw the what we
call the service topology which is,
which services talk to which other services?
So you'll have A talking to B, talking to C,
talking E,F,D,Q, whatever, and we can draw that map in real time.
It turns out that's actually
a very difficult thing to do if you're just looking
at the code or if you're just writing things
down in a spreadsheet because it changes all the time.
We derive that map from the observed traffic.
>> Who retains the role of actually watching the service mesh
itself as you see it in these production environments?
Is there an app operator that's actually the app developer?
Is there somebody actually controlling the service mesh itself?
>> Yeah. So there's kind of two categories of
people who we try to satisfy with a service mesh.
The first is a platform owner themselves and then the operators.
So they have to feel really comfortable with this thing.
They have to understand what it's doing.
But there's also the developer.
So the developer who is deploying things to this platform.
There's a lot of value they can get out of the service mesh too.
>> Okay. So is there such thing as
a fail safe, service mesh failure?
So in the event that it goes down,
my services may still
function in a partial outage or an outage case?
>> Yeah. So the service mesh along with
your microservices application is a distributed applicant,
it's a distributed system,
and one of the core tenants of
a distributed system is that there are
going to be failures
and you're never going to be able to predict them.
So Linkerd has been
designed to take into account
all sorts of different ways that things can
fail ranging from one of the hosts that is
control plane component was running on just died all the way to,
we have a network partition,
and these two nodes can no longer talk to each other.
>> Okay. So clarify this for me,
can I use the service mesh to monitor the service mesh?
>> Yeah.
>> You do use the components to self-monitor?
>> Yeah. So when you install the Linkerd control plane,
before you add the data plane to anything else,
the only thing that you have visibility into is Linkerd itself.
You can look in the dashboard.
You can see each of the components.
You can see what their health is.
You can see the request volume.
That's a big, big part of giving you visibility into what
is actually happening in
the service mesh which is vital as an operator.
>> Okay. So I'm bought in on service meshes.
Where do I go to learn more?
>> So the best place to go is Linkerd.io.
We have a website for our open source service mesh,
and all of our activity happens on GitHub.
So you can also go to github.com/Linkerd.
Finally, we have a very friendly and active community
that is in slack.linkerd.io,
and you should definitely join and check it out.
>> So all of those links will be in the description.
Along with that, you can go to
opensource.Microsoft.com to learn more.
If you like this video,
give it a thumbs up and click
"Subscribe," and thanks for joining us. Thank you, William.
>> Thanks, Lachie.
[MUSIC]