►
From YouTube: How MS3 Supports 10,000+ Transactions Per Second with Kuma Service Mesh Across VMs a... Jose Montoya
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
How MS3 Supports 10,000+ Transactions Per Second with Kuma Service Mesh Across VMs and Kubernetes - Jose Montoya, MS3
With more businesses moving to digital, MS3 needed a simple way to address cross-cutting concerns such as security and observability, to accelerate the delivery of cloud native applications in a microservices architecture using containers and Kubernetes. This session covers how Kuma end-user, MS3, leveraged the service mesh project for a cost-effective way to address these concerns at the platform level and removed from the application developers’ responsibilities. We'll provide real-world examples to help other organizations implement service mesh to expedite digital transformation initiatives due to COVID-19. We’ll cover how MS3 leverages Kuma, an open-source control plane for service mesh built on top of Envoy, for their Enterprise Integration Platform to support commercial and federal customers with no performance impact for apps handling over 10,000 transactions per second
A
Hey
guys,
my
name
is
jose
montoya.
Welcome
to
this
talk
named
tavros
and
kuma,
essential
software
concerns
at
the
platform
level.
A
little
bit
about
myself.
I
work
for
a
company
called
mountain
state
software
solutions
or
ms3.
For
short,
we
specialize
in
enterprise
integration,
software
cloud
migration
strategies
and
api
enablement.
A
So
I've
been
doing
this
for
about
five
years
now
and
for
the
last
six
months
to
a
year,
I've
been
the
principal
product
manager
for
tavros.
Tavros
is
a
enterprise
integration
platform
from
ms3.
Today,
I'll
be
taking
you
guys,
a
little.
You
know
journey
between
what
tavros
is
and
how
we
use
kuma
to
address
some
of
these
essential
software
concerns
at
the
platform
level,
so
we'll
get
right
into
it.
A
So
the
first
thing
that
we
should
do
is
talk
about
this
essence
of
software
right,
so
the
concept
comes
from
a
book
called
the
mythical
man
month
you
might
be
familiar
with.
It
is
is
sort
of
a
classic
in
software
engineering
in
in
this
book,
frederick
brooks
it
has
basically
a
collection
of
essays
about
software
engineering
in
general
in
particular,
there
is
one
called,
no
silver
bullets,
the
essence,
an
accident
in
software
engineering,
where
he
basically
describes
what
he
thinks.
A
The
essence
of
engineering
is
of
software
engineering
is
and
here's
what
I
have
here's
what
he
says
the
hard
part
of
building
software
is.
Is
this
specification,
the
sign
and
testing
of
this
conceptual
construct,
not
the
labor
of
representing
it?
Basically,
what
brooks
is
saying
is
that
the
hard
part
is
really
understanding
what
it
is
that
we
want
to
build
and
kind
of
creating
our
mental.
This
conceptual
construct
right,
designing
it
even
as
a
conceptual
construct.
A
A
A
A
He
does
have
a
few
things
that
he
considers
to
be
worthwhile
attacks
on
on
the
essence
of
engineering,
to
provide
this
kind
of
boost
of
productivity.
He
lists
four
I've
grouped
them
here
in
two
groups
of
two,
because
I
think
they,
you
know
these
groups
kind
of
go
together
and
so
I'll
go
through
them
now.
So
first
is
the
requirements,
requirements,
refining
and
rapid
prototyping.
A
Basically,
here
he
talks
about
you
know
it
is
iteratively
refining
your
your
requirements,
gathering
right,
so
there's
no
way
that
we
can
get
our
requirements
precisely
and
accurately
all
up
front.
So
we
might
as
well
just
prototype
and
learn
as
we
go
just
keep
refining
our
requirements
and
prototyping
as
we
go.
A
I
think
in
the
same
vein,
he
talks
about
incremental
development
where
he
basically
says
that,
instead
of
trying
to
deliver
all
of
the
features
of
a
software
product
kind
of
all
at
once
with
the
final
nail
just
kind
of
do
it
do
it
incrementally
right
so
start
from
a
kind
of
very
bare
piece,
maybe
even
useless,
but
you
know
standalone
and
functional
and
start
adding
features
incrementally
right.
So
the
analogy
is
to
grow
software
instead
of
building
it
as
a
building
just
grow
it
that's
a
living
thing.
A
The
idea
is
that
we
want
to
go
at
it
piece
by
piece
incrementally,
not
all
at
once
so
agile
and
continuous
delivery.
I
think
kind
of
fit
that
same
idea
of
you
know:
incremental
development,
prototyping
and
requirements,
refining,
microservices
and
containerization.
I
have
here
because,
as
we
make
these
units
of
functions
smaller,
it
makes
it
easier
for
us
to
prototype.
It
makes
it
easier
for
us
to
try
different
languages,
different
designs,
different
frameworks,
etc
and
observability.
A
I
have
here
because
it
is
imperative
for
us
to
have
good
observability
into
our
systems
in
order
for
us
to
really
inspect
meaningfully
and
have
the
ability
to
make
educated
decisions
on
that
inspection
in
order
to
adapt
the
other
few.
The
other
two
attacks
that
brooks
talks
about
in
his
book
is
buy
versus,
build,
which
I
think
is
the
main
one
he's
basically
saying
the
most
productive
time
you
know
trying
to
deliver.
Software
is
where
we
is
when
we
don't
spend
that
time
at
all.
A
So,
basically,
you
know
you
buy
an
off-the-shelf
product
that
meets
all
if
not
most,
of
your
requirements
and
the
other
one
is
great
designers
where
he
basically
just
says
hey
at
the
end
of
the
day,
software
is
is
sort
of
a
creative
process.
It's
an
artistic
process,
so
some
people
are
just
going
to
be
better
at
it
than
others.
A
Specifically,
you
know
more
experienced
developers
are
always
just
going
to
be
better
than
those
non-experienced,
so
he
talks
about
you,
know,
spending
time
and
resources
on
people
and
get
them
to
be
these
great
designers.
But
at
the
end
of
the
day
again,
you
just
gotta
have
good
good
people,
good
designers,
and
so
these
two,
I
kind
of
take
me
into
domain
driven
design
right.
A
A
How
fast
a
customer
can
open
a
checking
account
from
their
phone
internally,
how
fast
or
how
easy
internal
developers
can
gather
information
from
you
know,
six
or
seven
different
back-end
systems
that
have
different
types
of
accounts,
how
easy
they
can
consume
compose
and
maybe
filter
that
data
to
provide
a
mobile
phone
user
interface,
maybe
even
an
alexa
conversation
or
a
website,
etc.
So
these
are
things
that
do
drive
the
business
value
that
we
can
offer
as
a
bank
that
differentiate
us
as
a
bank,
so
these
will
be
our
core
domain.
A
The
other
point
that
eric
evans
makes
is
that,
because
generic
subdomains
are
generic
across
industries,
they've
been
studied
more
they're
kind
of
more
tractable
they're,
not
domain
specific
they're,
easy
to
understand
and
attack,
so
they
sometimes
attract
your
more
skilled
developers.
So
what
ends
up
happening?
Is
your
your
great
designers
end
up
working
on
the
things
that
bring
you
the
least
amount
of
value?
A
If
we
take
it
one
step
further,
we
can
identify
even
more
things
that
ought
to
be
considered
in
this
process,
which
I
call
generic
cross-cutting
concerns.
These
are
things
that
applied
regardless
of
whether
there
is
a
core
domain
or
a
generic
sub-domain
things
like
security
logging
tracing
any
of
these
cross-cross-functional
cross-cutting
concerns
that
apply,
and
you
need
to
think
about
because
even
though
they
they
still
play
a
supporting
world,
it's
still
essential.
No
one's
going
to
use
your
system
if
it's
not
secure
so
yeah.
A
We
need
to
to
keep
this
in
mind
and
try
to
bring
this
into
this
strategic
buy
versus
build,
but
we'll
start
with
the
generic
subdomain.
So
let's
say
once
we've
identified,
you
know:
I'm
a
bank,
I
don't
need
to
build
a
crm
and
we
identify
all
these
products
and
we
say
we're
just
gonna:
buy
them.
We're
gonna,
liberate
our
developers,
our
great
designers,
to
work
on
our
core
domains
and
not
on
the
generic
subdomains
that
are
only
you
know,
supporting
they're
the
supporting
cast
great
great
first
step.
A
Now
the
surface
area
is
going
to
be
smaller
than
your
core
domain,
because
integration
is
mostly
going
to
be
about
translation
and
orchestration,
but
it's
still
a
place
where
you
can
drive
value
that
value
from
right.
So
if,
if,
if
you're
a
bank
again
and
you
bought
a
system
for
mortgages,
mortgage
accounts,
a
system
for
credit
cards,
credit
card
accounts,
if
you
develop
a
integration
component
that
allows
you
to
view
all
of
those
accounts
uniformly
from
independently
developed
components.
That's
a
differentiating
factor
right.
A
A
How
do
we
buy
versus
build
these
generic
cross-cutting
concerns
that
are
not
really
what
gives
us
value
as
a
bank
or
any
other
industry
right?
How
do
we
address
these
so
that
we
can
focus
even
more
on
the
core
domain
or
the
integration
domain
to
drive
value?
So
there's
two
ways
of
solving
this:
one
is
through
application
or
language,
specific
library.
So
we
can
say:
okay,
you
know
what
there's
a
a
a
spring
boot
library
or
a
dot
net
core
library
that
solves
security
and
it
solves
tracing.
A
So
you
know,
given
the
rise
that
we've
seen,
obviously,
because
we're
in
this
industry
of
enterprise
integration,
we've
seen
a
clear
demand
in
in
continuing
to
grow
demand
for
an
integration
platform
that
solves
a
lot
of
these.
You
know
kind
of
generic
concerns
for
them
because,
as
as
more
off-the-shelf
products
become
available
and
as
you
know,
we
kind
of
digitalize
ourselves
as
a
society.
More
and
more.
These
companies
are
figuring
that
hey.
A
Maybe
I
really
should
only
spend
my
time
on
what
makes
me
you
know
better
than
my
competitors
instead
of
trying
to
solve
logging
and
tracing
and
security
over
and
over
again,
because
that's
what
we
find
as
a
consulting
companies
are,
we
end
up
solving
observability
in
10
different
ways
and
10
different
clients,
because
they
try
to
do
it
on
their
own
way,
not
to
say
that
that's
bad,
but
that's
not
those
are
not
the
the
main.
You
know
the
principal
drivers
of
value
for
this
company,
so
that's
not
where
they
should
be
spending
their
time.
A
So
we
committed
to
tabras,
which
is
our
enterprise,
integration,
platform,
writing
and
orchestration,
and
data
transformation
are
at
the
heart
of
it.
But
we
also
wanted
to
make
containerization
important,
because
we
didn't
want
to
be
that
platform
that
says
hey
only
if
you
use
our
engine
and
our
data
transformation
framework
can
you
deploy
to
our
platform
if
you're
not
using
that,
then
you
can
use
it.
You
have
to
use
a
different
platform
for
your
other
workloads
and
we
know
some
platforms
that
are
like
that
and
we
find
them
to
be.
A
So
what
we
want
to
do
is
make
sure
that,
whatever
choices
we
made
to
address
some
of
these
concerns
for
our
customers,
that
they
were
being
addressed
in
a
way
that
was
independent
of
the
language
and
then
the
framework,
and
so
that's
what
we
achieved
through
service
mesh
and
through
kuma,
like
our
explanations
before,
and
then
we
just
chose
open
source
components
to
address
other.
These
concerns
right
so
like
observability
security
and
continuous
delivery.
A
This
is
a
pretty
high
level
overview
of
what
tavros
is
so
on
the
top
right.
For
example,
we
have
our
observability
components
on
the
top
on
the
bottom
right.
We
have
some
of
the
other
ones
like
he
clocked
for
security.
Sonar
cube
for
static
code
analysis
things
like
that
on
the
left.
We
have
jenkins
and
flux,
for
example,
driven
by
git,
so
this
is
kind
of
git,
ops
and
continuous
delivery.
A
So
what
it?
What
that
ends
up
meaning
for
us
is
that
we
have
this
generic
workload
that
there's
an
application
in
whatever
language,
and
then
there's
scuma
in
this
particular
diagram,
we're
highlighting
observability.
So
we're
saying
hey
regardless
of
where
or
how
you
implemented
your
application.
Kuma
is
going
to
do
observability
for
you.
If
your
application
happens
to
be
aware
of
distributed
tracing,
then
you
can
augment
what
kuma
offers
with
application
specific
tracing.
But
if
it
doesn't
no
worries,
a
generic
workload
will
still
participate
in
your
distributed
tracing
because
of
cool.
A
A
You
know
tracing
information
like
the
step
in
the
route
in
your
integration
flows
and
then
you
can
do
custom
application,
specific
context,
diagnostic
tags
and
things
like
that.
But
the
whole
point
of
all
of
this
again
is
to
address
these
essential,
but
supporting
concerns
of
software,
so
the
the
great
designers
so
that
the
application
developers
can
own
can
can
focus
only
on
the
application
level.
You
know
concern
so
they
can
actually
get
to
the
va
to
the
part
that
drives
value
in
their
business,
so
they
can.
A
So
talking
about
kuma,
specifically,
what
we
do
in
tavros
is,
we
have
you
know
designated
namespace
environments
for
workloads
anytime,
there's
a
deployment
in
one
of
these
namespaces
you'll
automatically
get
some
policies
applied
to
your
application
again,
so
that
the
application
developer
transparently,
get
transparently,
gets
all
this
value
without
really
thinking
about
how
it's
installed
and
configured
etc.
So
what
happens?
Is
this
on
as
soon
as
an
application
is
installed
is
deployed
into
one
of
these
environments?
They'll
automatically
get
a
tracing
policy.
A
If
this
application
happens
to
be
one
of
the
integration,
an
integration
workload
from
our
framework,
then
you'll
get
that
optional
application
level
data.
But
again,
if
it's
not
no
worries
you'll,
you
still
have
the
benefits
of
getting
these
cross-cutting
concerns
addressed
because
of
kuma
working
outside
of
your
application
language,
and
so
in
our
demo.
What
we
have
here
is,
for
example,
this
is
our
logical
structure
right,
so
we
have
kong
being
the
load
balancer,
the
the
ingress.
Basically,
then,
you
have
crm
mobile
and
crm
conductor
implemented
in
a
language
different
than
our
integration
framework.
A
It
could
be
net
could
be
you
know
anything
really,
so
you
can
imagine
crm
mobile
doing
some
mobile,
specific
transformations
and
crm
conductor
is
basically
an
orchestrator
that
goes
into
two
integration:
specific
applications.
One
is
crm
salesforce
that
goes
to
talk
to
salesforce
and
the
other
one
is
the
database
that
talks
to
a
database.
A
The
idea
is
that
you
have
some
customer
data
in
both
of
these
sources
and
you
want
to
compose
them,
for
you
know,
displaying
them
in
a
mobile
application,
and
so
what
ends
up
happening
once
once
you
know,
kuma
is
involved
and
all
this
tracing
information
starts
gets,
it
starts
being
gathered
and
and
reported.
Is
you
end
up
with
a
graph
like
this
in
in
a
system
like
jager,
which
is
the
distributed
tracing
system
that
we
install
and
configure
automatically
for
unitabros?
A
So
you
can
see
it's
almost
a
one-to-one
representation
of
our
logical
understanding.
So
you
have
kong,
crm,
mobile
conductor
and
then
the
two
one
for
each
implementation,
with
their
integration
specific,
you
know,
applications,
and
so
what
this
does-
and
this
is
just
a
general
point
on
observability-
is
because
we've
adopted
microservices
as
an
architectural
style
across
you
know,
basically
in
the
whole
industry,
you
start
needing
these
sorts
of
tools.
A
You
start
needing
graphs
in
in
in
charts
in
order
to
make
sense
out
of
dozens
and
hundreds
of
services
you
need
to
start
being
able
to.
You
need
to
start
being
able
to
have
analysis,
root,
cause
analysis,
latency
analysis,
figuring
out,
what
sort
of
stuck
to
what
other
services
why
this
particular
transaction
failed?
Where
did
it
fail
things
things
of
that
nature?
A
So
you
get
this
for
free
in
tavros
because
of
kuma's,
you
know
tracing
policy
and
its
ability
to
work
regardless
of
the
implementation.
This
is
another
example
for
that
we
have
here.
So
if
you
see
here
in
the
middle,
we
have
crm
database,
and
this
is
again
because
the
crm
database
workload
was
in
our
integration,
specific
framework.
We
get
application
level
tracing
data,
so
here
we
have
data
around
a
set
header,
operation
or
a
processing
operation.
A
Here
we
have
a
logger.
We
have
a
delay
things
like
that.
So
the
idea
is
that
when
you
have
an
application
that
can
can
augment
what
kuma
can
do
great,
but
if
not,
we
still
have
a
conductor.
Here
we
still
have
mobile.
We
still
understand
what
is
actually
going
through
our
integration
stack
through
our
iet
landscape,
so
that
is
the
value
that
we
needed
to
achieve
for
our
customers
and
that
we
wouldn't
have
been
able
to
without
something
like
kuma.
A
When
we
tie
this
into
your
log
aggregation
system,
like
we've
done
between
jaeger
and
elastic,
you
can
do
a
lot
of
neat
things
like
correlating
your
traces
with
your
logs
doing
like
we
said
all
these
root
cause
analysis,
latency
analysis,
you
can
start
doing
trend
forecasts
and
things
of
that
nature.
You
can
start
seeing.
You
know
your
worst
offenders
and
sorts
of
errors,
and
you
know
in
one
single
pane
of
glass,
navigate
from
a
high
level,
dashboard
or
who's
been
having
more
errors
in
the
last.
A
A
Okay,
so
that's
observability,
the
second
one
that
I
wanted
to
highlight.
Let
me
do
a
quick
time
check
here,
I'm
over
time
already,
okay,
so
the
other
one
that
I
wanted
to
highlight
is
mutual
tls,
and
this
is
another
one
that
we
do
by
default
in
tabros,
which
is
basically
any
deployment.
That
is
any
any
workload
that
is
deployed
into
one
of
the
environments
that
we
manage
through
mesh
through
kuma
service
mesh
will
automatically
also
be
enrolled
in
mutual
tls.
Kong
sits
in
the
middle
because
it
needs
to
take
in
requests
externally.
A
Obviously,
but
anything
from
that
point
on
needs
to
be
in
this
trusted
environment.
It
needs
to
have
a
certificate
provided
by
kuma,
so
we
transparently
provide
all
this
information.
Your
developers
no
longer
have
to
worry
about
certificate
authorities,
certificate,
signing
requests,
rotating
certificates,
all
the
stuff
that
it's
really
really
hard
to
do
really
gets
addressed
transparently
by
tavros
through
kuma
for
the
developer
again,
to
only
have
to
worry
about
that
application
level
logic
about
really
driving
business
value
for
that
company,
they
don't
have
to
worry
about
the
stuff.
A
These
are
those
generic
things
that
we
wanted
to
address
and
we're
able
to
we're
able
to
because
of
kuma,
and
this
allows
us
to
provide
things
like
zero
trust,
security
and
extending
that
to
open
policy
agent.
We
can
say:
hey,
not
only
are
we
providing
the
security,
but
we're
doing
it
in
a
way
that
is
so
simple
to
understand
and
configure
through.
A
So,
like
I
said,
I'm
basically
out
of
time,
so
I'm
running
through
this
last
slide.
That
kind
of
does
it
all
for
me,
I
think
I'll
be
taking
questions
now.
These
are
some
links
that
I'm
putting
out
for
you
guys
in
case
you're
interested
in
tavros
and
the
work
we're
doing.
Thank
you
so
much
for
your
time.