►
From YouTube: Lightning Talk: Domain-Oriented Microservice Architecture with Kuma - Mike Beaumont, Kong Inc
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Domain-Oriented Microservice Architecture with Kuma - Mike Beaumont, Kong Inc
Microservice and service mesh architectures bring big benefits along with significant architectural complexity. A single call to one service can fan out to countless other microservices in a homogenous mesh, making debugging a Herculean task. Without cautious architecture an organization can end up with a "distributed monolith". One strategy to avoid this is the domain-oriented service architecture. A DOA applies the ideas of domain-driven design to a distributed system. Services are grouped into domains and domains communicate over gateways. Kuma (CNCF Sandbox project) has recently introduced first class support for a DOA architecture with its gateway feature. The new MeshGateway API features logical service level domain isolation and enforcement of cross domain routing and control policies. This talk illustrates how to achieve a domain-oriented architecture in a microservice platform with the power of Kuma's MeshGateway.
A
Yeah,
so
what
that
means?
You
have
to
start
coordinating
with
other
teams,
so
you're,
the
owner
of
your
service,
but
you've
got
to
talk
to
the
owners
of
the
other
services
and
you've
got
to
coordinate
deployments.
You've
got
to
make
sure
that
that
what
they're
running
doesn't
break
when
you
change
yours-
and
maybe
one
of
the
teams
doesn't
have
the
bandwidth
to
do
this
at
the
moment.
But
you
want
to
get
your
release
out.
A
So
maybe
you
just
implemented
yourself
in
their
service
just
to
get
it
done
right,
and
this
doesn't
scale
very
well.
What
you've
basically
created
is
what's
known
as
a
distributed
model
with
where
the
services
appear
to
be
independent
but
really
they're
very
tightly
coupled
and
if
we're
using
a
service
mesh.
There's
another
aspect
to
this,
and
that
is
in
a
service
mesh.
A
Every
node
is
able
to
communicate
with
every
other
node
right,
that's
kind
of
the
idea
of
a
mesh,
and
what
this
means
is
that
the
control
plane
is
calculating
configuration
for
all
the
sidecars
for
these
services
and
if
we
imagine
a
new
service
coming
up
the
control
plane
in
order
to
handle
this
new
service,
the
control
plane
needs
to
calculate
configuration
for
sidecars
of
all
other
services.
This
uses
CPU.
A
So
those
are
some
issues
with
this
sort
of
naive
way
to
do
a
microservice
architecture
and
I'm
going
to
talk
about
Doma,
which
is
domain
oriented,
microservice
architecture.
But
first
I
want
to
jump
back
to
domain
oriented
design
which
sort
of
applies
to
you,
know
a
single
Deployable
application
or
a
library,
and
it's
also
an
answer
to
the
question
of
how
do
you
design
your
software
with
ideas
like
maintainability
and
ownership
in
mind
and
what
it
says
is
basically
use
the
business
domain
that
your
application
lives
in
create
modules
for
your
application.
A
A
The
first
is:
do
you
take
your
services
and
you
group
them
together,
according
to
the
business
domain
that
they
live
in
and
then
we
say
inside
a
domain,
and
these
are
examples
here
inside
a
domain.
Services
communicate
with
each
other
directly,
but
services
in
different
domains
can't
communicate
at
all,
so
you've
essentially
privatized
the
interfaces
of
those
microservices,
and
then
you
introduce
the
idea
of
a
domain
Gateway
which
exposes
the
functionality
of
those
domains
in
a
public
interface,
and
this
public
interface
can
be
consumed
by
the
services
in
other
domains.
A
So
now,
you've
got
private
and
public
interfaces
for
your
microservices
and
domains
and
gateways
are
really
just
rules
about
how
Services
communicate
with
each
other
and
that's
kind
of
what
a
service
mesh
does
right.
It's
what
a
service
mess
is
there
for,
and
maybe
we
can
use
a
service
mesh
to
help
us
enforce
and
implement
this
architecture
and
I
think
we
can
with
Kuma
the
first
way
we're
going
to
do.
That
is
the
mesh
resource
that
Kuma
offers
now
the
mesh
the
word
mesh
can
refer
to
like
the
entire
control
plane.
A
The
whole
data
plane,
but
Kuma
also
offers
a
resource
which
is
basically
called
mesh,
which
is
basically
a
way
to
partition
your
data
plane
into
separate,
separate
meshes,
and
it
does
this
by
virtue
of
the
fact
that
in
a
mesh,
every
mesh
defines
its
own
CA.
So
for
every
service
that
ends
up
in
a
mesh
mcls
guarantees
that
it
can
only
communicate
with
other
services
in
that
mesh
via
mtls
and
and
the
fact
that
they
have
their
individual
Cas.
A
This
allows
us
to
make
an
optimization
in
the
control
plane
if
a
new
service
in
say
mesh,
a
comes
up.
The
control
plane
knows
that
it
doesn't
need
to
recalculate
any
configuration
for
mesh
B
because
it's
impossible
for
a
meshp
service
to
reach
a
service
in
meshe
anyway,
and
so
our
resource
usage
becomes
independent
between
meshes.
A
We
can
also
create
a
like.
We
don't
have
to
create
any
additional
permission
policies
here.
We
can
rely
on
the
ca
to
enforce
this
separation
between
meshes
and
otherwise
say.
Okay,
every
service
inside
a
mesh
can
just
communicate
freely
and
we
still
only
have
one
actual
control
plane
deployment
to
worry
about,
so
one
control
plane
deployment
is
handling.
These
multiple
meshes
the
second.
A
These
two
things
together
give
us
a
pretty
great
way
to
model
the
domain
from
domain
oriented
design.
So
in
domain
oriented
Kuma
we
model
domains
using
meshes.
The
second
part
for
gateways.
We
recently
introduced
the
built-in
Gateway
in
Kuma,
which
is
an
Envoy
based
Gateway
for
north
south
trap
for
North
South
traffic,
and
when
we
were
looking
at
how
to
handle
communication
between
meshes,
we
decided
to
reuse
the
Gateway
a
little
differently.
A
A
We
accept
at
traffic
from
NECA
at
a
Gateway,
and
so
this
allows
us
to
take
the
functionality
that
the
microservices
in
a
mesh
Implement
and
then
expose
it
via
the
cross
mesh
Gateway
for
the
other
meshes
to
use
for
those
Services,
which
makes
it
a
perfect
way
to
model
the
domain
Gateway
of
DOMA,
so
yeah,
so
we've
got
meshes
modeling
domains
and
we
have
cross
mesh
gateways
modeling
the
domain
Gateway
and
as
an
example.
If
you
were
here
earlier,
you
saw
the
talk
about
Gateway,
API
and
you'll
recognize
this.
A
This
is
a
gateway,
API,
Gateway
and
so
Kuma
supports
Gateway
API.
Here
we've
created
a
Gateway,
we've
labeled
it
with
the
mesh
we
want
it
to
belong
to,
and
we've
pointed
to
a
Gateway
class
that
Kuma
provides
for
making
cross
mesh
gateways.
The
hostname
that
we
set
is
the
name
that
the
cross
mesh
Gateway
will
be
accessible
at
for
all
other
services
in
our
mesh,
and
then
we
can
create.
A
You
know
HTTP
routes
like
normal
to
expose
that
functionality
from
our
services
inside
the
mesh
to
services
in
other
meshes
just
to
drive
home
the
point
about
how
mtls
is
what
mtls
is
doing
for
us
here.
If
we
imagine
a
client
here,
making
a
request
to
The
Domain
Gateway,
like
I,
said
it's
at
orders.mesh,
the
envoy
config
is
made
up
of
well.
A
We
model
this
in
Envoy
by
on
the
client
side,
creating
a
cluster
which
is
basically
a
set
of
envoy
endpoints
that
point
to
a
yeah
point
to
an
endpoint
in
the
Gateway.
We
have
a
listener
that
corresponds
to
The
Listener
we
created
earlier
and
the
client
is
it's
opening
a
TLS
connection
Upstream
and
it's
providing
an
identity.
That's
given
to
it
by
the
payments,
which
is
the
mesh,
it's
a
part
of
CA.
A
It
sends
this
when
it's
making
a
request
to
The
Domain
Gateway
listener.
The
domain
Gateway
identifies
itself
with
the
orders,
with
a
certificate
from
the
order
CA,
and
then
we
have
on
the
client
side.
We
trust
the
order
CA,
because
it
that's
what
the
cluster
is
configured
to
do,
because
it's
configured
for
a
domain
Gateway
and
on
the
Gateway
side
we
are
trusting
the
payment
CA
amongst
the
other
Cas
in
our
mesh.
A
So
we
see
that
these
two
things
in
combination
mean
that
the
request
will
be
successful
and
we've
maintained
our
mcls
guarantee,
but
we're
moving
between
meshes
here
yeah,
so
that's
domain,
oriented
Kuma,
in
short,
the
takeaways
here
I
think
are
Doma
is
a
good
way
to
avoid
some
of
the
complexity
of
microservices
and
avoid
some
of
the
pitfalls
and
Kuma
is
a
great
service
mesh.
That
is
a
great
way
to
add
an
infrastructure
layer
for
that
implements
the
Domo
architecture.