►
Description
Presented by Sergio Canales and Hosted by Saim Safdar
If you are getting started with microservices in a Kubernetes environment, be careful to avoid falling back on monolithic constructs in a microservice environment. Sergio and Saim will explore the pitfalls of microservices and what you need to watch out for.
A
Thank
you,
everyone
for
joining
us
in
ortelius,
microservices,
visionary
event,
and
today
we're
going
to
talk
about
the
pitfalls,
monolithic
practice
in
a
micro
service
architecture
and
today
I'm
guest,
syme
softer
and
I'm
joined
by
sergio
canales.
So
let
me
introduce
myself
a
bit
for
our
audience.
I
am
currently
a
devops
engineer
at
zekra
and
also
I'm
a
good
contributor
to
the
linkedin
community
and
faster
the
linker
d.
I've
spent
a
lot
of
time
in
service
measuring
open
source
lay
five
community.
A
They
have
a
tool
called
measuring
and
right
now
I
am
spending
most
of
my
time
opens
free
time
with
my
hoteliers
colleagues
and
hoteliers
community.
I
found
this
community
very
helpful
in
terms
of
sharing
knowledge.
Instead
of
gathering
information
about
micro
services
will
be,
90
is
container
at
this
kind
of
stuff,
and
that's
bit
about
me
and
why
not,
sir,
you
can
you
introduce
yourself
update
your
audience,
what
where
you
are
and
what
you
currently
do
right
now.
B
B
A
I
I
think
the
first
question
everybody
had
talked
to
some
question
answering
sessions
and
some
of
these
kind
of
and
the
first
question
I
usually
see
people
like
to
do.
How
do
you
transition
yourself
to
the
microservices
world
and
what's
your
currently
company
is
doing
in
these
microservices
setup
and
what
are
the
practices
that
you
want
to
adopt?
Can
you
share
with
them.
B
Well,
usually,
you
start,
you
start
a
discussion.
Try
not
go
go
directly
of
what
what
they
have
to
do,
because
some
there
is
super
common
that
companies
want
to
jump
up
to
the
microservice
at
once.
So
we
start
talking.
That
is
a
process.
There
is
the
the
company
needs,
some
need
capabilities
majority.
B
B
You
are
doing
like
a
transformation
to
microservices,
but
you
start
improving,
because
in
other
cases
you
already
have
a
customer
that
is
maybe
trying
with
some
spring
spring
boot
container
stuff
like
that,
and
you
really
see
that
they
they
they
miss
some
important
things.
So
there
is
a
lot
of
gaps,
maybe
and
and
technical
dev
that
if
you
don't
solve
or
start
or
start
working
from
the
beginning
can
be
a
little
harder.
So
the
best
practices
is
usually
progress.
A
And
also,
I
think,
the
national
questions.
Okay,
people's
came
up
their
mind
if
they
have
already
a
monolithic
service
setup
is
built
in.
How
do
you
translate
translate
that
monolithic
architectures
with
the
micro
services
setup
and
what
the
translation
is
going
to
be
and
what
are
the
strategies
that
is
going
to
be
adopted
if
they
are
moving
to
the
microservices
architecture?.
B
Well,
there
is,
there
is
some
patterns
on
the
market.
Usually
people
are
going
to
propose
like
as
a
strangle,
monolithic
right
taking
some
part
of
this
big
monolithic
and
and
isolated
some
functionalities,
but
the
the
the
real
thing
is:
it's.
It
depends
when
you
are
on
this
situation.
It's
not
only
like
transforming
your
your
implementations.
There
is
a
lot
of
times
how
much
training
my
people's
going
going
to
need
how
deprecated
is
maybe
the
technology.
Maybe
it's
too
old,
it's
a
legacy
one.
B
At
the
end,
there
is
a
lot
of
money
talks
too.
So
there
is
some
point
where,
usually
you
cannot
do
like
a
big
bang?
We
say,
like
you,
cannot
just
start
over
again
in
microservices,
so
you're
going
to
try
to
have
this
monolith
working
implementing
some
new
stuff
and
there
is
a
lot
of
opportunities
to
start
fresh.
So
there
is
a
lot
of
people
that
maybe
they
have
a
huge
java
monolithic
and
are
going
to
try
to
a
little
implementation
about.
B
So
there
is
a
lot
of
things
you
can
do
on
there
over
there,
but
so
you
can
go
and
resume.
You
can
go
in
dual
mode
in
a
single
mall
on
or
you
can
just
trump
start
from
scratch.
So
you
have
to
do
a
little
deep
business
scenario
analytic
for
for
that.
But
just
don't
try
to
jump
off
micro
service
at
once.
A
Yes,
what
I
understand
from
the
conversation
is
that
when
you
have
already
a
monolithic
setup
is
built
in,
you
have
to
start
thinking
about
what
are
these
tools
and
technologies
and
the
practices
that
people
already
have
in
their
setups
and
talk
to
the
other
community
members.
What
are
their
companies
is
going
to
set
up
in
their
setups
so
trying
to
having
a
conversation
between
each
other
is
going
to
be
very
moving
forward,
and
you
have
to
build
that
as
layer
by
layer
approach.
A
Everyone
in
their
mind
that
in
the
monolithic
architecture,
we
have
some
kind
of
separation
of
concerns
between
the
business
layer
and
the
logic
layer,
the
presentation
layer
and
now,
when
we
move
to
the
microservices
architecture.
These
are
the
different,
separate
boxes,
so
how
do
we
implement
some
kind
of
domain,
driven
design
patterns
and
other
business
oriented
patterns,
and
what
do
they
have?
These
kind
of
pattern
exist
in
the
microservices
landscape
and,
if
you
don't
have
what
we're
gonna
do
in
this
way
in
that
way,.
B
Okay,
so
on
that
topia
I'm
going
to
go
really
really
light,
because
the
domain
drain
size
are
really
large
the
conversation,
but
I
have
to
say
that
when
you
start
like
doing
these
little
chunks
of
logic
and
separate
like
everything,
usually
you're,
going
to
or
or
the
normal
thing
you
I
can
see-
is
you're
going
to
take
a
like
technical
decision.
Well,
you're
going
to
take
some
layers
from
some
packages,
some
so
and
and
usually
the
thing
at
the
end.
B
When
you
your
business,
I
don't
know
how
he's
having
like
a
a
a
huge
sales
day
at
the
end
of
the
month,
and
you
really
don't
know
what
part
of
that
business
are
the
critical
one,
because
you
just
chunk
on
technical
part,
but
the
business
value
is
not
clearly
represented
or
represented
on
anyone
of
everyone.
So
I
think
at
the
end,
today
we
are
realizing.
We
need
a
lot
more
of
domain
dream
design.
B
A
And
I
also,
I
think
the
next
question
is:
that's
people
like
to
know
that
that
the
micro
services
is
just
for
the
containers
or
some
else,
part
of
it
or
a
microservices,
come
up
with
the
container
some
other
technologies.
We
can
build
micro
services
in
it,
but
we
think
the
hot
topic
of
micro
services
and
that's
today's
everyone
they're
talking
about
the
container
and
orchestration
technologies.
B
Well,
the
discussion
about
microservices
is
super
deep,
but
one
thing,
I'm
sure
that
is
a
micro,
separate
definition
is
not
a
technical
definition
by
itself
is,
is
is
a
way
to
to
work,
because
I
I,
when
I
explain
stuff,
I
really
go
to
the
problem.
Okay,
so
microservices
born
from
the
problem
where
you
are
really
couple,
teams
are
really
couple
and
functional.
It
was
really
coupled
to
to
to
introduce
change.
B
You
usually
you're,
going
to
you're
going
to
take
one
line
of
some
code
and
probably
you're,
going
to
make
a
lot
of
troubles
for
a
lot
of
things,
and
and
after
that,
if
you
resolve
that
and
everyone
integrate,
that
code
is
going
you're
going
to
have
a
lot
of
problem,
deploying
that.
So
that
is
like
what
I
try,
what
we
are
trying
to
solve
with
with
microservices.
So
when
someone
some
company
wants
to
start
using
microservices,
the
last
thing
is
going
to
to
happen
is
decide
what
doctor
implementation
is
going
to
be.
B
What
orchestration
is
going
to
be
so
start
from
seeing
your
process
and
seeing
your
pains
and
seeing
if
that
pains,
the
top
pains
are
those
ones
are
microservice
design
pattern.
However,
you
can
want
to
call,
it
is,
is
going
to
solve
so
I
I
really
like
the
destination
from
microservices
that
is
giving
you
freedom.
I
really
like
that
because
I
started
as
a
as
a
developer.
I
started
after
I
like
engineers
administration,
on
cicd
devops,
whatever
you
want
to
call
it,
but
the
the
problem,
I'm
harvesting.
So
it's
really
nice.
B
When,
when
teams
have
freedom
and
when
teams
have
freedom,
they
have
a
speed,
and
there
is
a
lot
more
innovation,
a
lot
more
and
trying
new
stuff
without
concern
that
somebody
is
going
to
complain
so
yeah.
I
I
would
like
to
put
a
point
to
that
when
we
are
talking
to
microservices
and
forget
that
there
is
a
technical
constraint
about
that,
you
totally
can
do
a
micro
survey
without
content
at
some
point
that
is
going
if
you're
you're
like
sending
on
delivering
stuff
in
a
really
independent
way.
A
Yes,
I
think
the
shorter
answer
to
this.
This
is
the
no
the
only
way
to
do
the
microservices
thing,
but
I
think
the
long
answer
to
this
is
going
to
be
the
because
the
whole
technolog
ecosystem
and
the
communities
are
moving
in
that
way
and
if
you
adore
container
and
container
technologies
orchestration
tools
there,
you
have
so
many
peoples
who
help
you
out
if
you
find
yourself
or
troubleshoot
some
kind
of
difficulties,
but
I
think,
rather
than
doing
an
isolated
land
where
nobody
has
to
help
you
join
the
community,
join
the
person.
A
Do
the
right
thing
with
that
technology
update,
you
can
join
the
so
many
community
members
help
you
out
in
these
kind
of
scenarios
and
now
moving
the
pitfalls
and
these
kind
of
topics.
I
think
the
first
question
that
is
really
harder
to
understand
right
now.
What
are
the
responsibilities
of
my
team?
Let's
say
I
have
a
micro
services
or
we
have
tons
of
micro
services.
What
are
the
upper
upper
responsibilities
of
my
dev
team?
What
are
the
responsibilities
of
my
ops
team?
What
the
devops
going
to
be
doing
these
microservices
architecture?
A
B
Okay,
so
the
responsibility
that
I'm
going
to
be.
I
will
try
to
be
more
graphic
on
on
this,
so
microservices,
another
nice
thing
they
have
they.
They
I'm
going
to
start
from
from
from
the
beginning
like
how
we
do
this,
usually
so,
like
the
the
the
more
traditional
architectures
our
way
to
work
we're
in
layers.
So
we
work
like
in
horizontal
a
logical
distribution
about
technical
stuff
and
even
prospects.
B
So
usually
you
are
going
the
the
teams.
You
have
one
team
on
the
maybe
virtualization
or
an
operating
system,
middleware
apps,
balancing,
networking
and
stuff
like
that.
So
if
you
see
you're
doing
layers
layers,
layer,
layer,
microservices
change
the
responsibilities
in
in
a
in
a
vertical
cut,
so
you're
trying
to
deliver
fast
functionality
because
for
for
anything
works
you
need
from
the
from
the
hardware
until
the
your
your
final
customer.
So
it's
a
vertical
cut.
B
So
we
are
like
putting
some
little
extended
role
and
responsibilities
that
increase
the
capabilities
about
this
team
so
and
that
point
is
the
same
from
the
infrastructure
guy,
so
they
usually
are
not
going
to
know
anything
about
the
the
applications
itself,
but
they,
this
container
still
is
a
operating
system.
It's
still
going
to
have
a
file
system,
it's
still
going
to
have
binaries,
so
it's
like
a
common
language
for
for
both.
B
So
is,
I
think,
if
I
can
do,
you
know,
explain
in
a
more
simple
way
my
teams
increase
their
responsibility
in
a
in
a
leader
in
a
in
a
real
and
a
specific
way
that
makes
with
the
responsibilities
of
the
next
team.
So
we
try
to
don't.
Have
it
like
this
silos
like
there
is
a
gap
in
each
team,
so
we
have
like
an
extended
responsibility
and
that
cross
with
some
part
of
the
responsibility
of
the
next
thing
in
the
next
layers.
B
So
it's
a
is
a
little
less
clear
that
in
the
traditional
way
to
work,
but
it
has
better
results.
So
if
I
am
a
developer-
and
I
know
that
not
for
say
something-
docker
use
some
kind
of
local
calls
to
the
local
ips
and
stuff
like
that
probably
is
going
to
going
to
be
more
easy
to
work.
My
with
my
infrastructure
team
and
solve
any
connection
issue,
for
example,.
A
We
can
somebody
jump
into
the
malicious
container
and
run
a
script
out
of
it,
but
the
developer
has
this
client
conscience
concrete
ability
to
run
the
application
in
a
contain
in
an
image
stack,
but
they
can
distribute
it
to
the
depth
on
the
dev
team
to
the
testing
team,
the
pro
team
they're
they're
working
in
a
consistent
way.
So
that's
I
think
the
develop
is
a
responsibility
of
the
developer
and
then
the
operator
has
this
ability
to
set
up
for
some
container
technologies.
A
Well,
let's
say
if
the
container
goes
down
that
they
have
some
kind
of
orchestration
technology
technology,
so
when
the
containers
of
these
kind
of
services
are
not
connected
with
each
other
say
with
the
helps
probe
and
these
kind
of
setting
that
available
for
them.
So
they
can
move
us
kind
of
some
orchestration
technology
or
cluster
platform
that
we
have
to
build
to
write
up
and
also,
I
think,
the
next
question
on
the
topic
of
the
pitfalls
and
these
kind
of
we
start
reflecting
from
the
monolithic
architecture
to
the
microservices
architecture.
A
So
we'll
we
used
to
see
the
distributed
monolith
that
people
like
to
call
it
it's
kind
of
a
micro
services
architecture,
but
the
micro
surface
itself
is
a
monolith
so
that
I
think
a
misconception
with
a
lot
of
people
right
now,
a
beginner
who
are
moving
to
this
micro
microservice
architecture
architecture.
But
as
there's
a
distributed
monolith.
Can
you
elaborate
in
this
point
what
the
distributed
monolith
and
why
we
want
to
avoid
it
and
what?
How?
What
is
the
originator
of
that
service
for
the
distributed?
Monoliths.
B
Well,
I
I
yeah,
I
think
we
we
do
a
little
introduction
of
this,
and
this
pitfall
in
particular
is
is
it's
again
when
the
the
decision
is
driving
about
the
the
in
the
technical
side.
So
if
you,
if
we,
if
we
say
that
we
want
to
modernize
our
applications
and
and
the
solution
is
running
the
same
application
and
on
a
container
as
we
say,
microservice
is
not
a
technical
thing.
So
if
we
put
anything
in
a
container,
but
we
don't
solve
the
problem,
we
are
still
having
the
same.
B
So
usually
companies
are
going
to
drive
the
technical
part,
so
I'm
moving
everything
I
already
have
to
the
cloud
to
the
kubernetes
to
a
docker,
but
still
is
pretty
much
the
the
same.
You
know
I'm
having
the
the
same
problem.
So
if
you
want
to
like
have
a
a
a
light
detector
for
having,
if
you
I
have
a
monolith
here
and
I'm
going
to
leave
it
on
microservices,
it's
easy.
B
If
you
are
having
the
same
pain
points,
you
are
having
pretty
much
the
same
monolithic,
even
if
in
container
or
even
it
is
distributed,
and
I
I
always
mention
this
an
experience
with
a
customer.
It
wasn't
just
one,
but
I
can
say
that
one
in
particular,
I
get
a
little
late
on
the
project,
so
we
were
checking
how
the
the
platform
were
used.
It
was
a
uranus
platform,
so
I
see
like
in
the
in
the
all.
B
It
was
a
floor,
complete
floor
from
admins
and
developers,
and
I
remember
that
I
wasn't.
I
have
a
little
a
few
minutes,
so
one
developer
asked
me
something
about
the
deployment
when
key
start
tell
me
what
happened
they
say
yeah.
I
need
to
to
ask
you
a
thing
a
few
things,
because
today
my
app
fails
pretty
much
all
my
all
all
department
fails.
B
I
have
like
one
micro
service,
the
spring
boot
micro
services
right
and
this
micro
service
fails
and
then
like
in
a
cascade
like
other
feb
10
microservices
failed.
So
I,
the
first
thing
I
asked
was
why
he
called
them
microservices
to
a
distributed
monolithic
that
is
clearly
coupled.
If
one
part
is
is
failing
and
everything
is
failing
at
the
end,
it's
a
monolithic,
so
yeah.
B
Yesterday
was
too
much
easier
because
you
have
like
a
a
a
wire
chip
or
something
that
you
know.
That
was
just
one
package
with
everything,
so
it
was
like
pretty
visual
or
it
was
like
a
piece
of
software
that
you
know
that
everything
was
over
there.
But
today
we
have
like
a
like
a
kind
of
a
mask
for
this
monolithic
that
you
cannot
see
it,
because
there
is
a
multiple
repositories
and
different
platforms
distributed
in
different
data.
B
You're
in
a
good
shape,
but
is
that
is
not
happening?
Yeah
you
are
having
still
a
monolithic
and
it's
not
something
related.
Then
hey,
I'm
cool,
because
I'm
doing
microservice
or
not
is
because,
if
you
have
this
coupling
always
you
want
to
like
scale
independent
freedom,
improved
time
to
mark
and
stuff
like
that,
you're
going
to
you're
you're
going
to
need
to
replicate
everything.
B
So
if
you
have
a
kubernetes
platform
with
15
microservices,
and
then
you
want
to
scale,
you
need
to
put
at
the
other
side,
another
cluster
with
the
whole
15
micro
services.
At
the
end
and
in
perspective,
you
are
having
like
in
traditional
one
phones
with
a
big
application
services
with
a
application
server
with
everything
and
the
other
and
the
other
side
they're
pretty
much
the
same.
So
it's
a
monolithic.
It's
a
it's,
a
it's
a
relation,
it's
a
direct
relation.
B
So
today
that
is
really
common
and
not
because
we
are
lacking
jazz
of
architecture
is
because
I
think
there
is
a
commercial
way
to
sell
this.
Usually
you
are
going
to
see
a
lot
of
people
saying
hey
I
have
like.
I
can
drive
you
to
to
the
cloud
with
a
really
less
effort.
Don't
try
to
do
that
because
going
to
cloud
it
really
requires
a
long
way
and
a
lot
of
work
when
you
do
less
work
at
the
beginning.
B
You
are
just
having
a
lot
of
more
issues
at
the
end
and
you
are
not
able
to
to
take
advantage
about
all
the
capabilities
in
the
globe.
For
example,
a
really
good
example
is
hey,
let's
go
and
do
list,
and
chip
left
chief
is
yeah
is
less
expensive,
he's
quick,
you
can
move,
but
at
the
end
the
only
real
benefit
is
that
you
are
not
working
in
a
traditional
host
or
maybe
the
whole
thing
put
it
on
on
in
another
falls.
B
Another
container
or
another
clothes
is
going
to
be
easy,
but
you're
not
taking
advantage
of
anything
so
take
care
about
the
the
concern
about
the
the
the
investment
you're
going
to
do,
because
if
you
want
the
real
benefits
you
need
to
do
it's
a
long
way.
It's
a
long
way.
It's
not
it.
It's
a
there
is
not
easy,
but
to
to
implement
or
change
your
monolithic
way
to
work
into
a
micro
serial,
distributed
architecture.
A
I
think
we
have
very
few
minute
laps
right
now,
but
I
think
the
whole
the
point,
the
driving
home
for
our
today's
talk,
is
that
that
was
started
from
the
continuous
technologies
and
moving
to
the
microservices
architecture
from
the
monolithic
would
have
translationally
layered
to
the
microservice.
But
the
end
up
with
doing
a
have
a
micro
services
that
end
up
having
a
micro
service
in
its
monolithic
architecture
itself.
A
So
it's
going
to
be
harder
to
explain
what
the
right
set
of
parameters
for
me
if,
in
order
to
if
I
testify
that
I
am
following
with
the
microsoft
architecture
in
a
best
possible
way-
and
we
also-
we
have
to
set
some
kind
of
service
discovery
mechanism
because
we
have
talking
with
one
microservice-
can
talk
to
other
microservices
and
you
have
to
take
the
latency
time
between
these
services.
How
much
time
it
takes
to
travel
from
one
micro
services
to
another
micro
services
and
do
it
they
have
to
discover
each
other.
A
That's
the
whole
point
of
micro
services
if
they
don't
discover
each
other,
these
different
chunks
of
boxes
that,
I
think,
is
doing
the
point
of
moving
these
architectures
with
this.
So
I
think
there
is
service
discovery,
some
roses
responsibilities
and
some
also
the
setup
of
these
practices
and
principles
of
microservices.
I
think
this
is
the
future
of
microservices
right
now
moving
forward,
and
also
I,
if
I
let
you
go
sergio,
can
you
introduce
what
the
our
community
is
helping
people
if
they
want
to
adopt
the
microservices
kind
of
architecture?
A
B
Well,
we
are
trying
to
support
a
lot
of
these
pitfalls
and
problems
we
already
told
so.
One
of
the
most
important
thing
we
are
trying
to
do
is
ask
a
a
more
balanced
way
to
take
decisions,
so
we
want
to
have
you
the
newest
technologies,
the
innovation
tools
that
are
in
the
market,
but
in
the
in
a
way
that
that
your
business
can
take
advantage
from
that.
B
Who
is
your
business?
How
is
your
business
working
because
usually
you're
going
to
have
a
really
weird
name
about
some
micro
services,
so
we
are
working
a
lot
of
in
what
is
an
app?
What
is
a
domain?
What
is
what
I
am
delivering
here?
I
am
what
is
the
value
I
I
I
am
updating
on
this
future,
so
a
more
a
more
like,
comprehensive
way
to
say
it
so,
and
this
community
with
the
reptilians.
B
We
have,
I
think,
a
really
good
opportunity
to
have
a
different
way
to
see
the
observability
with
a
more
business
labor
over
that
so
can
be
more
easy
to
to
work
in
a
collaborative
way
and
because
microservices
I
have
another
destination
for
microsoft.
Microservices
is
a
lot
of
collaboration
if
you're
done
doing
much
collaboration,
you're
not
going
to
be
able
to
to
use
my
micro
service
or
because
we
already
said
that
there
is
more
people
like
talking
with
each
other
to
have
the
the
best
the
best
solution.
B
B
A
Yes,
thank
you
very
much
sergio
for
today
joining
us.
I
think
that's
all
for
tying.
That
way
for
the
today's
talking,
I
think,
hopefully
you
guys
will
learn
from
these.
The
micro
services
is
is
a
kind
of
a
research
oriented
topic
right
now
for
the
many
companies
they
are
moving
forward,
but
luckily
we
have
a
lot
of
tools:
a
lot
of
open
source
communities,
a
lot
of
contribution
from
open
service
communities,
and
luckily
we
have
a
guy
like
sergio
sergio
canales,
and
there
are
so
many
other
rotarian
is
here
for
you
to
help
you
out.
A
I
think
having
a
starting
initial
conversation
with
us
might
be
help
you
in
moving
forward-
and,
I
think,
is
having
a
very
good
community
out
of
it
in
open
source
project
is
going
to
be
very
helpful.
That
and
if
you
have
some
kind
of
cool
ideas
on
how
you
can
help
us
or
help
you
contribute
to
these
open
source
committee
projects,
do
let.