>> I'm Aaron.
>> I'm Armon.
>> This is The Open Source Show.
[MUSIC].
>> I'm Aaron. I'm a Cloud Advocate at Microsoft.
>> I'm Armon, I'm one of the founders and CTO of HashiCorp.
>> All right Armon. We're here talking about service meshes today.
I'm going to confess though,
I don't know what a service mesh even is.
So, can you school me a little bit on this.
>> It would be my pleasure. It's definitely a new concept.
I think the way we like to think about a service mesh really
is how do we go back to what
the problem is that we're trying to solve.
In this modern cloud era we have containers,
we have our serverless functions,
and we have our VMs and we're running this whole collection of
infrastructure, but how do all these things talk to one another?
I think that the core of the problem is
running all of these different pieces of distributed applications,
distributed infrastructure but they need a way to communicate.
So, a key challenge becomes how do I
route and discover to all of these different applications?
How did all of these components find each other?
Let say I have a web server and it
needs to talk to the database to be able to query data.
How does the web server even know where the database is running?
It's running somewhere in the cloud and
maybe my database fails and it moves somewhere else in the cloud?
And that's a really simple example, that's
just web server to database but you can imagine if
I have caching layers and
API services and all sorts of backend pieces.
There's many, many components that
all suffer from the same problem.
So, this can scale from like,
I just got a little web app that's got
a front-end and a database but once I
grow and I've got a 1000 person team with
all these microservices, to use another buzzword of our time,
what does it do for me when I go up to that level as well?
This really comes back to the question almost
of "when should I use this technology?"
So, I think if we start by saying what
a service mesh really does is:
gives us a consistent way to route between all of our services,
discover between them. Then it's like when do I use this?
Does it make sense for me to use this if I have
two services like a web server and database?
I would say not really, it's overkill.
Then in the scenario you're talking about where
it's like I have 1000 developers,
many services, many microservices,
that's a sweet spot which is now I have
a ton of complexity and I don't want to
solve that same problem of how does
this thing talk to that thing a 1000 different times?
I'd rather solve it once with
a central service mesh and then apply it to all 1000 applications.
I've heard of this thing.
These two things actually in services meshes like data plane,
control plane, is like all these planes,
it feels like I have to go catch a plane or something.
Can you walk me through what these two things are all about?
Yeah, I think when we talk about service mesh there's
a bunch of these other topics under it and I
think control planes are one of them and I think first
let me talk about observability because
I think that's also an important piece of it.
Okay.
When we talk about service mesh,
again the first level of concern is, how do we route?
How do we discover? How do we connect these pieces?
But on the second level one is,
okay well once you've connected all these pieces,
how do we know how much traffic is
going from our web server to our database?
Is there no requests happening?
Is there are too many requests or they're
getting errors between them?
It's too slow? What's going on?
So, I think that opens up this whole question around how do I
observe what's happening in the service mesh?
So, when we talk about observability then the question is,
well how does that actually happen?
How do we actually enable getting
that data in terms of who's talking to who and things like that?
That's where the control planes come in.
So, observability is the goal then the questions is well,
how do we get any of that data?
So, I think that brings us to how does this system actually work?
How does the service mesh function?
There's these two critical layers of it.
Layer one is the control plane which
is a central kind of management portal is the way to think about it.
So, if I'm the operator or
I'm the system administrator and I want to set up a rule that
says my web server is allowed to talk to my database
or I want to see how much traffic is flowing between those things.
I go to the control plane as
the central management unit but in some sense if it's the brains,
it's lacking the body.
>> I see.
>> That's where the data plane comes in. All right.
So, the data plane is then the flip side of that, it's the body.
It's the one that's actually querying data between these things,
enforcing who can talk to who,
collecting that data of how much traffic are we seeing,
all that's done at that lower level.
I see, I see the separation but if I'm running the cluster,
I'm probably be talking to the control plane mostly?
Right.
Is that done with a Web UI, scripts,
or an API or how does that,
or both? I mean how does that work?
It's all of the above.
So, in some sense,
the data plane lives everywhere.
So, you run either an agent or a proxy on every container,
every VM, every serverless function.
So, it's ever-present but it's really talking to
the control plane on your behalf so that
the only thing you talk to is the control plane.
Then you might use the UI,
a CLI, and API.
You might interface with the control plane
in many different ways but then
it's the brain that's controlling
the rest of the data plane for you.
So, then if I'm the app developer,
it sounds like I'm not really going to
touch the control plane at all, right?
To a large degree yeah,
it should be invisible to you.
As an app developer,
you're writing your web server and
it needs to talk to the database.
You don't necessarily care
how it's talking to the database. Right?
Okay.
So, there's probably some small tweaks you need to do in
sense of instead of hard-coding let's say the database IP.
You need to talk through the data plane.
So, you need to talk to the local proxy or
the local agent to make sure data goes over the data plane,
but beyond that it's invisible to you as an application developer.
I love it when other software that I didn't have to
write does all the work for me, that sounds amazing.
Then you get all those observability benefits that
we talked about plus you get all the code of routing,
discovery, and security benefits for free,
you don't think about it as a developer it just happens.
How do I get started?
If I'm running on Kubernetes let's focus on that.
How do I get all this goodness into my app,
into my cluster what have you?
So, we actually have a really good blog on
the Azure blog about how do you actually get started with Consul,
which is our service mesh tool on
Azure, Azure Kubernetes specifically.
Then the second piece is that data plane we talked about.
That has to be ever present.
So, to make that really easy with Kubernetes,
there is an admission controller
that will automatically inject it into every pod.
You don't have to really think about the data plane
because it's getting injected
behind the scenes for you automatically.
Behind the scenes?
Yeah, you just submit your pod,
it gets added to the pod and it's
just another container that's not doing that local routing.
Wait, okay. All right. Let's backup.
So, if I Helm install my app,
I don't change a thing in my Helm,
install in any of my templates. This still works?
Yep, it's just auto
injects the control plane for you behind the scenes.
Whoa! That's nice.
There's some annotations you can put on to
say I want the pod or I don't want it.
So, you can opt-in or opt-out
if you don't want to make use of that.
But in general, the goal is for it to be really,
really easy as a developer to consume this.
So, you mentioned there's some links in the blog posts?
Yes. So, there's some links already
on the Azure blog about how do
I get Consul up and running on AKS but then beyond that,
there's going to be an upcoming Azure Friday video
that people can check out.
There's a bunch of resources on the HashiCorp site,
so you can then go to HashiCorp's console homepage consul.io or
learn.hashicorp.com and we have a whole set of
walkthroughs and tutorials of
how to actually get started with this.
Cool. So, check out the show notes below.
We've got links to all the HashiCorp stuff and go check out
opensource.microsoft.com as well. Thanks a lot everybody.
Thanks.
[MUSIC]