Introduction

Listen to Stevey's podcast: https://youtubetranscript.com/?v=Wi8SL-Tot-8&t=1212

Transcript

so let me tell you about service meshes
kind of like the terminology just to get
everybody up to speed because i know
some of you haven't looked at this space
or haven't looked at it recently
you're going to hear two terms control
plane and data plane bandied about a lot
and it's very confusing at first okay
because first of all they are sort of
poorly named and second of all there is
actually a fair amount of overlap
between the two in the in the service
offerings that we have today all right
and in the tech stacks that we have
available so let me walk you through
them all right
so starting at the uh at the service
level so you have a bunch of services
maybe they're on vms maybe they're in
kubernetes maybe they're in nomad or
fargate or whatever right but you've got
services vms or containers and you want
to have them communicate with each other
all right
well having rather than having them all
communicate with each other
which obviously means you're going to
have to build like service discovery
logic into the service itself
so if i have a player service
let's say i have a game server and it
wants to go call the player service and
say is this player real okay if so give
me their give me their information give
me their credentials okay typical
service to service uh you know function
call rpc
all right well you could have the game
server say well i'm going to call the
service registry service to see uh where
the player service lives and then i'll
make a call to the player service right
but now you're building that i'm going
to call the service registry service
which is this other service right that
you would have to build or whatever or
use ncd like grab did or whatever
and then it has to call and get the
address of the player service and then
and then it makes the call and it's like
you've built
routing logic
and discovery logic into your actual
application logic which you do not want
you do not want that okay
so
almost immediately people started moving
to proxies
you have a proxy that's your local proxy
they call it a sidecar proxy in
kubernetes land because it actually runs
in your little cluster as another
service along alongside all of your
other services
and it handles all
network uh ingress and egress for you
so you the idea is that your application
only knows about the sidecar proxy right
so to your application the proxy is the
outside world if if you you know it
knows about the service locations and it
also knows about circuit breakers and
traffic splitting and load balancing and
scaling and everything else that we'll
talk about in a bit
and that proxy becomes the thing that
other people use to talk to your service
as well because your service may be a
cluster right and so people if people
want to send something to the player
service and there's a bunch of instances
of it your proxy is the one to choose
which one maybe maybe it interacts with
an external load balancer or maybe it
does the load balancing itself the proxy
does okay by doing the health checks on
its local service instances yeah
does this model make sense so as soon as
you get this basic model of the of the
sidecar proxy you've got a helper
service that goes along with every
cluster
and it knows about the services in that
cluster and it knows about the outside
world
and your cluster talks to the outside
world through the proxy and the outside
world talks to your cluster through the
proxy okay you can use nginx for that
and that's what dropbox is doing right
but these days people always almost
always use envoy or link or d there are
a couple of other options in addition to
those in nginx but i mean those are the
really popular ones okay
envoy is the the super industrial
strength
does everything swiss army knife amazing
data plane okay by the way those sidecar
proxies i'm going to introduce you now
to the to the second term you hear data
plane the other one being control plane
data planes is just all of your sidecar
proxies in aggregate because if you if
you've got a whole bunch of clusters
right uh or even a whole bunch of
services and you want proxies for each
of them then
that mesh of proxies
that are all talking to each other
to work out the service discovery and
the routing and everything on behalf of
the application services now you've
extracted all of that you know who who's
talking to who what where and how much
and all that you've extracted it into
your
sidecar proxies
that's your data plane
it's because the network data is going
through that and i think it's a terrible
name it should have been called the
network plane or the proxy point proxy
plane would have been an absolute great
name for it right
proxy plane but no they call it data
plane so it's completely confusing
because you'd think the data plane would
be either your application logic or it
would be the data layer behind your
application logic but no
so stupid name really stupid shame on
whoever chose that name really you just
you did a huge disservice to the
industry so if you patent yourself on
the back because you came up with a name
data plane like seriously like punch
yourself in the mouth okay it just it
was a bad name
naming you know naming stuff matters man
you don't want to confuse everybody for
the rest of their lives
whatever but the name is stuck and the
name is the name now and in fact there
are well we've been ahead of ourselves
here but they're even becoming universal
standards now for data plane uh
interfaces
so the data plane i mean like you're
just going to have to learn what data
plane means it means it's the proxy
layer okay the proxies that can uh could
load balance and they can they they
handle the network for you it's software
load balancing they actually in envoy
they actually communicate through a
protocol called a gossip protocol which
is a family protocols where they're sort
of like udp multicast where
everybody just kind of like spits out
the state and consumes the state and it
sort of floods the network
and it's eventually consistent
so that's one thing to know about envoy
is they chose an eventually consistent
model
if you'll recall
i said that etcd and technologies like
it like google's chubby or uh
zookeeper or uh even hashicorp console
they're all they're all key value stores
that are
um transactional highly available and
strongly consistent okay
uh and that actually makes them uh sort
of a pain to operate
uh in practice
all of the ones that i just mentioned
chubby is an interesting one google's
chubby it was probably the first uh mike
burrows i think uh did chubby and if you
haven't heard the name mike burrows
uh you really should know his name
because you know he's easily one of the
the people who had 10 people who've had
the most impact of google right
uh he's you know i don't know he's a de
or whatever
and uh and he he came up with chubby as
far as you know among other things and
chubby is um
chubby is distinguished as
having something like seven nines of
availability it was down for 30 seconds
in 10 years something like that
so um
so yeah and it's because google has a
core competency of operating chubby at
scale
right because it's the it's the central
you know key value service for service
uh discovery and information ...