►
From YouTube: Evolution of Integration and Microservices with Service Mesh and Ballerina - Christian Posta
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Evolution of Integration and Microservices with Service Mesh and Ballerina - Christian Posta, Red Hat
Cloud-native describes a way of building applications on a cloud platform to iteratively discover and deliver business value. We now have access to a lot of similar technology that the large internet companies pioneered and used to their advantage to dominate their respective markets. What challenges arise when we start building applications to take advantage of this new technology? In this talk we'll explore the role of service meshes when building distributed systems, why they make sense, and where they don't make sense. We will look at a class of problem that crops up that service mesh cannot solve, but that frameworks and even new programming languages like Ballerina are aiming to solve
To learn more: https://sched.co/GrRO
A
A
Hopefully
this
isn't
gonna
be
a
deep
dive
on
any
of
these
topics,
really
because
it's
not
there's
just
not
enough
time,
but
hopefully
you'll,
walk
away
understanding
how
the
application
languages
that
you
might
use
to
build
your
services
interact
with
or
where
they
fit
in
an
architecture
with
technology
like
service
mesh.
Again,
show
of
hands
how
many
people
have
heard
of
service
mesh?
Okay,
awesome,
a
good
room
now
how
many
people
are
actually
using
service
mesh
Wow,
okay,
awesome,
okay!
So
let's,
let's
get
started.
A
First
of
all,
my
name
is
Kristin
posta
I'm,
a
chief
architect
at
Red,
Hat
I
work
with
our
customers
in
mostly
North
America,
to
build
distributed
systems
on
top
of
cloud
native
platforms
like
kubernetes
or
the
Red
Hat
distribution
of
communities.
Openshift
I
spent
some
time
at
large
enterprise
companies
like
banks
and
retailers,
but
I
did
have
have
the
opportunity
to
spend
some
time
with
Zappos
calm
and
with
Amazon
about
five
years
ago.
A
Before
the
whole
micro
service
DevOps
thing
blew
up
and
what
I
try
to
do
is
help
our
enterprise
customers
know
and
understand
what
it
means
to
do:
DevOps
microsomes
and
be
successful
and
achieve
their
outcomes
not
just
adopt
new
technology
for
the
sake
of
adopting
new
technology.
I
I
try
to
work
in
the
open-source
communities
when
I
have
time
I've
been
in
the
past
contributor
to
communities
that
are
involved
in
integration
and
enterprise
integration.
A
Things
like
Apache
ActiveMQ
things
like
Apache
camel
and,
more
recently
in
a
project
called
esteem,
so
I've
written
a
couple
books
on
micro
services,
I
wrote
the
first
book
on
this
deal
and
if
you
struggle
like
I,
do
in
finding
the
right
gift
for
your
loved
ones
for
Christmas
may
I
recommend
getting
multiple
copies
of
sto
in
action.
That's
the
that's!
A
The
book
that
I'm
working
on
right
now,
I'm
hoping
it's
going
to
be
a
in-depth
treatment
of
what
is
do
is
how
to
be
successful
with
it
when
and
when
not
to
use
service,
mesh
and
and
so
on.
So
so,
really
it's
it's
in
early
access.
So
if
you
go
check
it
out
right
now,
there's
only
four
chapters
there,
but
I'm
at
times
working
on
it
and
so
hopefully
get
it
done.
So,
let's
jump
into
it.
A
Our
our
industry
is
talking
about
innovation
constantly
with
with
how
it
relates
to
technology.
At
one
point,
your
enterprise
companies
that
you
work
for
were
disruptive
and
they
were
the
new
person
on
the
block
and
they
were
innovating
and
and
finding
ways
to
provide
value
to
their
customer,
and
then
they
grew
and
they
and
they
grew
and
at
some
point
they
use
technology
to
help
streamline
their
business,
save
money
on
operations
and
they
ended
up
with
a
a
complex
set
of
of
systems
over
various
years.
A
Different
vintages
of
technology,
from
mainframes
to
client-server
technology
to
the
SLA
days,
and
now
we're
talking
about
a
new
generation
of
technology
right,
but
what's
interesting
about
right
now,
is
that
the
technology
we're
talking
about
ideally
will
help
the
cuz.
These
enterprises
help
help
people
build
things
faster
and
get
things
out
to
production
faster
so
that
they
can
test
and
validate
whether
or
not
the
ideas
they
have.
A
That
would
generate
value
actually
do
generate
value,
they
don't,
but
the
faster
you
get
it
out
there
and
test
the
quicker
you'll
know
so
we're
in
this
world
where
we
need
to.
We
need
to
build
that
engine
to
be
able
to
cheaply
do
deployments
and
the
automation
and
the
infrastructure
in
place
to
safely
do
that,
but
we
can't
neglect
the
technology
that
we've
built
in
the
past,
which
helped
our
companies
get
to
where
they
are
today
a
lot
of
times
these.
If
we
call
them
legacy,
systems
are
generating
billions
and
billions
of
dollars
right.
A
So
we
can't
we
can't
just
ignore
them
or
wish
them
away.
So
in
some
way,
we
have
to
work
between
the
newer
technologies
and
the
older
technologies
to
get
things
out
to
customers
and
that
gets
very
complicated.
That
gets
very
complicated,
it's
very
hard
to
change
some
of
the
older
systems,
whereas
on
the
new
side
we're
trying
to
go
even
faster,
but
as
we
start
to
adopt
micro-services
serverless
all
this
all
these
are
these
new
architectures
for
building
applications.
A
We
realized
something
pretty
quickly
that
we
didn't
have
to
deal
with
as
much
in
the
older
older
paradigm,
and
that
is
that,
as
we
move
to
a
service
install
architecture,
we
move
and
push
complexity
that
was
otherwise
hidden
from
us
or
assumed
away
in
between
the
services.
And
now
we
have
to
face
that
head-on.
We
can't
ignore
that.
A
Take
a
relatively
simple
example,
where
customers
are
trying
to
check
out
on
your
what
your
website
and
they're
adding
things
into
their
cart
and
a
simple
click
on
their
website
might
generate
a
bunch
of
different
calls
to
back-end
services
to
legacy
services,
and
you,
the
application
developer,
has
to
figure
out
how
to
do
that
successfully.
Because
if
you
look
at
this
diagram,
so
many
things
can
go
wrong.
So
many
different
points
of
failure
here,
both
in
obviously
the
network
hops.
But
when
you
start
making
calls
out
to
services.
A
Now
you
have
to
deal
with
data
transformations.
Now
you
have
to
deal
with
splitting
messages,
calling
calling
services
that
might
update
data
on
their
end
and
deal
with
duplicates
and
all
these
weird
partial
failure
scenarios
that
that
could
throw
a
wrench
into
the
whole
system.
So
the
types
of
problems
that
we
have
to
solve
here
involve
getting
hitting
these
services
getting
these
back-end
older
systems
integrated
in
a
way
that
they
can
deliver
value.
Some
of
the
problems
I
touched
on
include
more
frustrating
a
call.
A
The
the
calls
of
services
to
a
bunch
of
different
backends
all
right
call
this
one.
Then
we
call
this
one.
Some
of
them
can
go
in
parallel.
The
integration
developer
needs
to
be
able
to
do
this
aggregate
and
combine
and
transform
messages
deal
with
errors
and
unexpected
results.
When
you
get
errors,
do
you
you
fall
back
to
some
pre
computed
value?
Do
you
try
again
what
happens
in
those
scenarios?
A
You
know
those
are
things
that
application
of
elders
have
to
think
through
problems,
especially
coming
up
when
you've
come
from
a
system
where
you've
built
on
a
nice
acid
database
and
Adam
is
taken
care
of
for
you.
Concurrency
is
taken
care
of
for
you.
Now
you
go
to
this
world
where
none
of
that
taken
care
of
for
you,
but
you
have
to
figure
it
out
somehow
and
you're,
probably
not
going
to
use
distributed
transaction.
A
A
We
need
to
build
api's
around
our
existing
serve
our
older
legacy
services,
so
it's
easier
for
the
newer
clients
and
new
applications
and
newer
services
to
interact
with
them
and,
of
course,
last
but
not
least,
we
have
to
deal
with
actually
making
calls
over
the
network
because,
if
you've
been
to
any
probably
any
of
the
talks
at
this
conference,
you
know
the
network's,
not
reliable.
The
fallacy
is
a
distributed
computing
hold
here,
so
the
problems
that
we
have
to
solve
in
that
space,
especially
on
a
cloud
platform
like
a
kubernetes
or
a
public
cloud
infrastructure.
A
We
have
to
solve
for
things
like
service
discovery
and
timeouts
and
retries
circuit
breaking
all
of
these
different
all
of
these
different
patterns,
just
because
we're
talking
over
the
network-
and
it's
not
necessarily
something
that
we
did
as
much
in
the
past,
certainly
not
on
these
unreliable
for
structures
like
like
cloud
platforms.
So
the
end
of
the
day
when
you
start
to
build
a
system
that
has
to
talk
to
a
bunch
of
other
other
services,
and
you
have
to
solve
these
different
integration
problems
and
communications
problems.
A
It
ends
up
being
the
responsibility
of
the
application
developer
to
solve
for
the
correctness
and
safety
of
the
requirements
that
they're
trying
to
implement.
You
can't
offload
this
to
some-some
infrastructure,
I,
don't
know
this
might
be
a
little
obscure,
but
there's
a
there's
a
paper
out.
There
called
the
end-to-end
argument
that
talks
about
how
there's
so
many
different
hops
in
the
system
and
things
can
go
wrong
where
it's
just
because
you
optimize
a
communication
channel,
doesn't
mean
the
system
automatically
gets
implemented
correctly,
so
the
applications
have
to
take
that
into
into
account.
A
In
the
past,
we
tried
to
centralize
that
problem-solving.
We
tried
to
centralized
how
we
dealt
with
and
implemented
this
complex
and
tricky
integration
stuff,
which
we
try
to
say
what
will
put
this
product
here
in
the
middle
of
our
architecture,
and
this
team
over
here
will
be
responsible
for
implementing
transformation,
content
based
routing
protocol
adaptation,
search
discovery,
load,
balancing
all
that
stuff
right.
So
we
said
we'll
put
that
over
here.
We
won't
change
any
of
our
systems.
A
A
So
what
we
want
to
start
looking
at
this
problem
through
the
lens
of
is
integration
is
isn't
a
silo,
isn't
something
you
can
just
offload
to
someone
else.
Integration
is
actually
part
of
building
your
applications,
so
what
we
would
like
to
do
is
enable
application
developers
to
correctly
and
consistently
build
integrations
with
back-end
systems
through
API
soar,
messaging
or
other
means
in
their
applications
and
there's
various
ways
to
do
this
right.
Everyone
has
their
favorite
language.
A
Another
interesting
part
about
our
fact
about
Ballerina
is
that
it's
it's
implemented
with
us
with
a
particular
mental
model
upfront
so
typically,
when
we
try
to
reason
about
applications
that
have
various
forms
of
concurrency
and
network
calls,
and
so
on.
It's
sometimes
it's
very
difficult
to
reason
about
them,
especially
at
runtime,
but
even
when
you're
looking
at
the
code
and
the
folks
at
at
ballerina
said
well
when,
when
you
try
to
explain
those
interactions
to
another
developer,
you
would
typically
go
and
draw
different.
Diagrams
sequence.
A
Here's
a
very
simple,
very
straightforward
example:
where
we're
declaring
a
service,
we
don't
have
a
main
and
bootstrapping
all
this
other,
all
this
other
stuff
just
to
be
able
to
build
an
HTTP
service.
It's
it's
baked
in,
and
this
is
a
language
construct
that
says
well,
we
want
a
service,
here's
the
endpoint,
and
we
want
to
listen
on
this
particular
port
and
there's
there's
patterns
for
doing
things
like
interacting
with
legacy
systems,
interacting
with
other
services
and
databases,
and
message
queues
for
doing
transactions
Security's
built
in
as
a
first-class
citizen.
A
So
you
can
do
things
like
track
the
the
state
changes
of
a
particular
variable
through
its
life
cycle.
Let's
see,
is
this
a
particularly?
Are
we
passing
this
variable
to
a
sequel
engine,
and
is
this
unchecked
by
the
by
the
client
I
mean
the
clients
were
just
passing
in
random
code?
Could
could
we
end
up
with
a
sequel
injection,
so
there's
built-in
security
in
terms
of
provenance
of
data
in
in
the
language
and,
like
I,
said
you
can
get,
you
can
get
sequence
diagrams
automatic.
This
is
obviously
a
very
simple
one.
A
This
is
a
reflection
of
the
previous
code
listening,
but
when
things
start
to
get
more
complicated
and
you
need
to
understand
and
socialize
importantly
socialize
with
your
the
rest
of
your
team,
what
it
is
that
you're
building,
then
these
these
diagrams
become
very,
very
helpful
now,
what
about
so
that?
That's
all
that's
all
good,
for
we
can.
We
can
solve
things
like
orchestration.
We
can
solve
things
like
concurrency
security
in
the
application
transactions
and
compensation
that
kind
of
stuff
we
can
solve
that
kind
of
stuff.
A
A
Surface
discovery,
timeouts
retries
circuit,
braking
rate,
limiting
metrics
collection
distributed
tracing.
These
are
not
optional
things
languages,
whether
ballerina
or
anything
else,
typically
have
some
support
for
these
types
of
patterns
now
Netflix
helped
kind
of
kind
of
jumpstart,
at
least
a
Java
community.
Initially,
with
by
calling
these
things,
you
know
they
start
talking
about
micro
services,
build
up
a
nice
wonderful
story
about
that
and
offering
to
share
their
code,
which
is
awesome.
A
Netflix
is
awesome
for
doing
that,
and
all
these
distributed
systems
things
that
we
needed
to
solve
were
effectively
called
micro
services
patterns,
so
they
started.
They
open
source,
their
libraries
that
solved
some
of
these
problems
and
and
and
brought
a
consistent
way
of
implementing
application
networking
to
the
applications
now
and
in
in
a
cloud
environment
in
the
cloud
world.
That's
that's
good.
Basically,
what
you're
doing
is
you're
co-locating
application,
business
logic,
application
integration
and
now
the
application
network
stuff
into
the
application.
It
is
the
responsible
like
like
we
said
earlier.
A
It
is
the
responsibility
of
the
application
to
do
that
and
made
it
easier
to
scale
and
deploy
into
VMS
and
containers
and
and
so
on,
but
that
was
Java
specific,
that
was
very
language
specific
and,
as
our
customers
in
the
enterprise
started
to
adopt
container
platforms
and
new
technology,
one
of
the
overarching
goals
or
benefits
doing
a
services
architecture
is
well
you
can.
You
can
don't
get
too
crazy
with
us,
but
you
can
pick
the
right
technology
for
for
the
the
service
that
you're
building.
A
So
what,
if
you're
using
nodejs
very
popular
language,
you
might
go
onto
google
and
find
go
onto
npm
and
try
to
find
well,
what's
the
his
what's
the
history
circuit-breaker
equivalent
in
nodejs,
or
if
your
I
don't
want
to
use
that
style.
I
want
to
use,
go.
You
still
have
to
go
out
and
find
again
for
that
language
and
any
framework
that
you
might
use
and
go
the
same.
The
same
thing
for
go
for
Python
for
any
language,
including
including
languages
that
you,
you
might
think,
aren't
in
use
today
and
they
they
are.
A
They
very
much
are
at
least
back
when
I
was
working
at
Zappos
again
five
years
ago,
police.
Some
of
this
has
been
pulled
out,
but
Zappos
was
written
front
and
back
and
subsidiaries
everything
on
bash
and
Perl,
and
my
sequel
and
some
of
that
code
you're
still
gonna,
see
laying
around
in
your
enterprises,
but
we
still
need
to
solve
those
those
application,
networking
problems
for
each
of
these
languages.
A
If
we
decide
to
go
the
application
language
route
and
find
an
implementation
of
circuit,
breaker
find
an
implementation
of
load,
balancing
of
distributed
tracing
of
rate-limiting
and
on
and
on
and
on
on.
We
end
up
with
a
combination,
a
large
combination
of
these
libraries
for
each
of
these
different
languages
that
we
might
use
and
the
important
bit
about
that
is
now
you
have
to
maintain
it.
You
put
that
into
production.
A
A
We
have
things
like
regular
programming
languages,
spring
pachi
camel
this
type
of
stuff
or
purpose-built
languages
like
ballerina
at
the
application
layer,
but
now
we
need
to
solve
in
a
consistent
way
for
app
networking
and
that's
where
technology
like
envoy
comes
into
play
so
envoy,
just
recently
graduated
to
the
top
level
of
CN
CF,
the
keynotes
was
fee.
Church
and
envoy
is
a
service
proxy
that
consistently
solves
the
application.
A
Networking
parts
of
this
set
of
problems
for
any
application
and
any
framework
on
any
language,
because
the
way
it's
deployed
is
as
a
service
proxy
and
that's
I'll
stress
that
again,
it's
a
service
proxy.
That's
not
necessarily
intended
to
replace
your
API
gateways
in
he8,
proxy
and
nginx.
What
it's
intended
was
originally
built
to
do
was
live
with
your
service
and
solve
for
those
application.
A
Networking
concerns
so
that
when
your
application
talks
to
another
service,
a
database
of
queue
or
whatever
it
goes
through
envoy
and
then
envoy,
applies
and
implements
these
these
these
pieces
of
functionality,
if
all
of
the
services
in
your
clusters
start
to
deploy
on
bullying
as
a
service
proxy,
you
start
to
build
the
backbone
of
a
communications
mesh.
All
the
traffic
is
flowing
through
a
service
proxy
in
this
case
and
you're
getting
consistent
behavior
around
the
resiliency
aspects,
the
metrics
collection
and
telemetry
syndication
aspects,
and
that
is
the
definition
of
a
service
mesh.
A
So
that's
how
we
get
to
service
mesh,
it's
decentralized
infrastructure
that
solves
the
application.
Networking
part
of
the
problem.
Ok
solves
things
like
security,
like
observability
policy
enforcement,
traffic
control
and
resilience
most
service
mesh
technologies.
Try
to
solve
these
these
types
of
problems,
not
all
of
them
do
some
of
them
are
subsets,
but
but
they
aim
typically
to
solve
these
types
of
problems,
which
were
the
problems
we
saw
in
the
previous
slides
about
service
discovery
and
load,
balancing
and
some
of
the
resiliency
aspects.
A
Some
open
source
service
mesh
technologies
that
solve
this
problem
or
aim
to
solve
this
problem.
Our
sto
you
may
have
heard
of
Sto
if
you
haven't
go
by
my
book
but
is
do-
is
an
open
source
project
from
Google
and
IBM
and
lyft
and,
more
recently,
more
more
folks.
So
the
community
has
blown
up
red
hats
involved,
two
pivotal
as
their
weave
works
and
and
other
folks
are
there.
A
Another
project
is
called
console,
console
connect
from
Hoshi
Corp,
which
just
kind
of
kicked
off
as
a
service
mesh
in
in
the
summer
and
is
slowly
building
up
its
capabilities.
It's
so
if
Co
is
based
on
envoy
and
console.
Connect
is
also
based
on
envoy
and
then
lastly,
linker
D,
which
has
been
around
in
various
forms
for
for
handful
years
now
three
for
years,
but
recently
switched
to
a
new
implementation
and
that's
built
on
its
its
own
custom
proxy
that
they
built
in
the
rust
language
and
don't
Lang
as
a
control
point.
A
A
That
doesn't
matter,
but
that,
on
top
of
that,
you
have
your
applications,
but
the
implementation
of
those
applications
can
be
optimized
for
operability,
with
the
service
mesh
and
for
developer
efficiency
reasons,
you
may
opt
to
explore
these
new
type
of
programming
languages
purposely
built
like
like
ballerina,
then
you're,
probably
gonna,
ask
yourself
or
me
afterward:
well,
isn't
there
isn't
there
overlap?
There's
there's
definitely
over
that,
because
these
programming
languages
solve
for
some
of
the
app
networking
stuff.
A
When
do
you
use
which,
right,
if
you,
if
you
don't
take
anything
away
from
this,
talk,
take
at
least
these
pieces
of
advice
that
just
because
you
use
a
service
mesh
does
not
mean
you're
offloading
the
responsibility
of
doing
application
networking
to
something
else,
even
if
it's
decentralized
like
a
service
mesh,
that
is
still
the
application
developers
responsibility
now
it
might
be
implemented
like
a
service
measures
implemented
out
of
process
all
right.
So
that's
a
bit
of
an
optimization,
and
we
said
that
was
because
we
want
to
be
able
to
operate
our
services
at
scale.
A
So
that's
fine,
but
the
configuration
of
those
of
the
service
mesh
dimensions
that
developers
care
about
timeouts
and
retry
circuit,
breaking
and
so
on.
That's
you!
You!
You
need
to
develop
a
workflow
that
allows
developers
to
influence
those
values
all
right
so
using
using
your
CI
CD
pipeline
as
a
backbone,
building
up
a
developer
workflow
so
that
developers
can
influence
those
those
values.
Now
that
doesn't
mean
service
matcher
is
going
to
solve
every
possible
combination
of
permutation
of
these
application.
Networking
problems.
A
Some
service
mesh
implementations,
like
the
Hashi
core
console,
actually
a
lab
built,
build
an
API
for
developers
to
write
their
own
custom
language
extensions
to
be
able
plug
directly
into
into
the
mesh.
So
that's
even
even
a
trade-off
there
or
hybrid
approach
there.
On
the
other
hand,
even
if
the
particular
service
mesh
that
you
adopt
enables
you
to
do
this,
resist
the
urge
to
jam
a
bunch
of
application,
integration
and
logic
into
the
service
mesh
now
I
know.
A
I
know
there
would
be
certain
certain
circumstances
where
maybe
it
makes
sense,
but
that's
it
becomes
a
very
slippery
slope.
Keep
things
like
call
orchestration,
aggregation
of
data
data,
consistency
models
that
kind
of
stuff
that
belongs
in
your
applications.
Don't
try
to
put
that
into
some
centralized
infrastructure
that
then
needs
to
be
managed
by
another
team,
so
I'm
very
quickly.
Gonna
gonna
show
a
demo
before
I.
Do
that
I'm
gonna
I'm
gonna
put
my
contact
information
back
up
here.
Just
so
we
can
I
can
leave
links
and
my
contact
information.
A
A
Don't
know
if
they're
gonna
accept
my
contributions,
even
the
smallest
bit
of
contribution
is
useful
to
do
these
open
source
community
so
reach
out
to
me,
if
you're
interested
in
getting
involved
in
any
other
projects
that
I
talked
about
here
or
any
other
ones,
and
just
looking
for
advice
and
thoughts
and
absolutely
reach
out
to
me,
I'd
like
to
help
people
get
more
involved
in
open
source.
So
the
demo
that
I'm
gonna
show
is
well
I'm.
A
Gonna
show
one
day,
I'm
gonna
show
one
demo
showing
some
of
the
features
of
Ballerina
and
then
I'm
going
to
show.
If
I
have
time
what
the
resiliency
aspects
that
you
can,
you
can
get
from
the
service
mesh.
Look
like
so,
let's,
let's
get
going
on
that.
So
one
thing
I
do
want
to
show
about
about
Valerie
now
I'll
increase,
I'll
increase.
The
font
size
here
is
come
here
to
the
regular
one.
A
Is
in
the
language
like
I
said
we
can
bootstrap
and
setup
and
create
a
new
service
very
quickly,
using
the
constructs
baked
into
the
language.
What's
what's
more
interesting
or
or
additionally
interesting,
is
that
the
the
bounty
has
been
been
built
for
deployment
platforms
like
docker
based
deployment
platforms
or
kubernetes
based
deployment
platforms,
so
with
the
length
within
the
language
we
can
do
things
like?
A
A
There
we
go,
we
can
see
that
the
the
right
this
recommendation
service
was
built
to
20
seconds
ago,
just
by
putting
that
little
annotation
in
there
same
thing
can
be
done
with
with
with
kubernetes.
So
by
adding
a
service
annotation
to
our
listener.
We
can
generate
a
kubernetes
service
automatically
and
we
can
also
generate
a
deployment
now.
The
last
thing
so
I
guess
I
can
I
can
do
that.
One
super
quick,
but
the
last
thing
I
want
to
show
Ballerina
run
conditions
kubernetes
at
run,
build.
A
We
can
see
it
automatically
generates
the
company's
resource
files
for
us
now.
The
last
thing
which
is,
which
is
pretty
cool,
is
you
can
add.
So
if
you're
familiar
with
SEO
at
least
you
can
add
an
annotation
to
automatically
generate
is
steel
resources
like
virtual
services
or
configurations
for
traffic
to
flow
in
through
the
Gateway
and
co-locate.
This
configuration
with
your
applications.
A
Which
clusters
is
how
we
can
use
this
do
regardless
now
of
what
language
you
might
use
to
build
your
services
to
to
be
more
resilient
and
solve
for
those
application.
Networking
concerns.
So
here
we
have
customer
which
calls
preference,
which
calls
recommendation
and
what
we're
going
to
do
some
interesting
things
in
between
the
call
from
preference
to
recommendation
so
now,
you'll
see
and
you'll
notice
on
the
bottom.
If
it
works.
Okay,.
A
A
That's
not
gonna,
it's
not
gonna
be
sufficient.
My
demo
here
so
basically,
what
I
was
going
to
show
is,
if
you
start
to
observe
bad
behavior
in
your
system,
either
that
I
was
gonna
inject,
that
behavior
using
SEO
and
then
and
then
implement
things
like
retries
and
timeouts
and
circuit
breakers.
You
can
do
that
with
is
Tio's
config
and
those
are
the
types
of
things
that
the
developers
need
to
need
to
influence.
Those
are
the
configurations
that
developers
would
need
to
influence
and
that
would
work
regardless
of
programming
language.