>> 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]
