►
Description
Ankur Kumar, Director Technology, Publicis Sapient Engineering Lead - Cloud Native & Microservices
Join Ankur to hear the challenges organizations face with microservices ‘in the wild.’ Ankur will bring a clear ‘end user’ perspective on what it takes to build out a distributed architecture with microservices front and center. He will review the top ten challenges he has learned from his experience building out a true cloud native platform.
A
So
welcome
everybody.
In
today's
session
we
are
going
to
talk
about
top
10
development
challenges
in
a
distributed
architecture
using
microservices.
So
before
we
start,
let
me
give
you
a
quick
intro
about
myself.
I
am
director
of
technology
and
publicity
sapient
been
working
with
industry
for
almost
22
years.
A
I
also
run
a
blogging
portal
weightcraft.com
for
grooming,
technical
and
software
architects.
I've
been
certified
in
various
cloud
and
api
certifications,
I've
been
guest
speaker
on
elastic
and
avid
blogger
and
you
can
go
to
weight
craft
read
my
blogs
and
you
can
also
reach
out
on
twitter
for
any
questions.
So,
let's
get
started
today's
session.
We
are
going
to
talk
about.
A
We
are
all
familiar
with
microservices,
it's
been
there
for
in
mainstream
in
last
couple
of
years,
and
it's
been
there
for
last
six,
seven
years
where
everybody
is
talking
about
it.
Everybody
is
now
adopting
microservices
architecture,
so
we
all
have
different
learning.
So
in
my
past
five
plus
years,
working
in
cloud
native
and
microservices
architecture,
there
are
many
learnings
which
I
wanted
to
summarize
in
this
session.
A
So
hopefully
you
all
get
benefited
out
of
this
session
so
before
we
deep
dive
into
different
challenges,
which
I
faced,
I
want
to
put
my
perspective
from
three
different
angles.
The
first
one
is
about
the
people,
because
people,
whether
it's
developers,
whether
stakeholders,
whether
it's
business
people
and
they
all
contribute
to
the
architecture.
So
people
aspect
is
again
one
of
the
core
pillars:
technology
and
engineering,
the
other
core
pillar
and
the
process
is
the
third
pillar.
A
So
all
development
challenges
which
you'll
see
which
I'm
going
to
talk
about
will
fall
into
one
of
these
buckets.
That's
how
I
envision
that
you
know
you
might
also
be
experiencing
in
your
organization.
So,
let's
jump
into
the
first
challenge,
which
I
see
when
we
start
adopting
microservices
or
distributed
architecture.
It's
it's.
The
first
thing
where
everybody
is
talking
about
is
organization,
culture
and
organization.
Culture
is
the
is
the
most
important
thing
when
you
start
with
any
new
architecture.
A
It's
not
only
just
limited
to
microservices
right
because,
if
you
remember
conveys
law
which
got
introduced
in
1968
got
mentioned
by
martin
fowler,
any
organization,
whether
it's
a
development
or
it's
a
product
organization,
they
broadly
represented
by
the
organization
communication
culture,
that's
the
essence
of
the
convex
law.
So
if
you
start
thinking
about
your
organization
in
terms
of
ui
developers,
back-end
developers
and
dbas,
you
will
end
up
producing
the
system
which
is
similar
to
that.
That's
the
essence
of
the
law.
A
So
the
key
challenge
is
you
know
to
make
sure
that
you
try
to
build
a
team
which
is
not
a
siloed
or
you
can
say
a
vertical
stack.
It's
it's
most
mostly.
What
you
are
going
to
do
is
that
you
want
to
create
a
team
which
is
the
combination
of
functional
or
the
domain
or
the
business
perspective
right
so
putting
converse
law
in
action.
It's
it's
not
easy,
because
there
are
things
which
we
can
influence
in
an
organization,
and
there
are
things
which
we
cannot
influence
in
an
organization.
A
So
it
also
depends
on
the
structure,
the
political
culture
and
all
those
different
aspects.
But
that's
a
that's.
A
key
challenge
right:
we
all
face
that,
so
how
do
we?
How
do
we
handle
that
particular
challenge?
So
recommendation
from
based
on
my
learning
so
far
is
again:
you
need
to
ensure
that
your
leadership
buys
into
the
distributed
architecture
of
the
microservices
architecture.
First,
if
the
leadership
is
not
with
you,
definitely
you
will
not
see
that
happening
across
the
team
right.
A
So
they
need
to
understand
that
in
organization
culture
and
the
organization
communication,
culture
will
drive
how
you
are
going
to
build
the
software
and
that's
what
martin
also
talked
about
that.
Instead
of
building
that
silo
team
build
the
cross
team
right
and
the
second
second
factor
is
about
psychological
safety,
and
this
is
one
of
the
one
of
my
favorite
areas,
because
I
see
google
has
also
acknowledged
that
they
have
published.
A
If
you
have
read
about
the
devops
report,
that's
what
they
call
a
dora
report
for
last
five
years.
They
talk
about
how
developers
perceive
themselves
in
a
particular
environment.
If
they
are
not,
you
know
kind
of
respected.
They
are
not
feeling
confident.
They
are
not
feeling
getting
the
right
set
of
environment,
then.
Basically,
you
will
not
be
able
to
build
the
right
software
with
that
mindset.
So
psychological
safety
is
what
I
I
personally
feel
it's
very
important.
A
You
have
to
make
sure
the
team
understand
why
you
are
doing
micro
service
architecture,
they
they
do
understand
and
then
then
they
are
comfortable
building
that
part
as
well.
So
you
need
to
cultivate
and
again
this
is
coming
from
all
the
key
leaders,
and
I
I'm
quoting
this
from
martin's
bloggers
that
you
know
build
the
product
mindset.
If
you
are
building
a
microservice
architecture
with
project
mindset,
it's
going
to
be
again
very
limited.
You
don't
will
not
have
a
broader
respect
so
promote
that
culture
promote
the
other
culture
of.
A
If
you
are
building
a
particular
architecture,
you
have
to
run
it
also,
and
you
have
seen
it
that's
how
the
devops
has
evolved
in
last
five
years.
So
if
you,
if
you
groom
that
confidence,
if
you
groom
the
team
using
these
key
tenets,
I
I'd
say
that
you
know
every
failure
will
be
a
learning
opportunity
and
you
see
that
how
you
can
handle
this
challenge
and-
and
there
is
always
a
learning
right
that
you
you
can
use
that
learning
when
you
are
talking
about.
A
So
the
second
part-
and
the
second
part
of
the
challenge,
is
how
you
can
start
enabling
your
team
and
second
challenge
which
I
have
seen,
is
the
full
stack
knowledge
in
terms
of
whether
it's
team,
whether
it's
you
know
other
stakeholders
about
the
microservices
world.
I
know
that
it's
still
considered
not
as
a
as
an
it's
still
a
new
technology
or
it's
still
relatively
new.
If
you
compare
with
other
things,
then
different
people
have
different
expectation,
so,
just
to
just
to
give
you
some
context
right
that
full
stack
engineer.
A
A
It's
also
about
how
you,
how
you
perceive
a
full
stack
engineer
should
be
and
gartner
quoted
it
very
rightly
that
if
you
are
fully
responsible
for
something
end-to-end,
that's
a
full
stack
for
them,
which
is
a
very
simple
definition,
but
I
I
think
it's
it's
it's
again
effective,
but
the
key
challenge
which
I
feel
is
when
you
go
to
the
reality
when
you're
implementing
it.
It's
not
easy
to
find
such
people
right.
You
will
not
find
full
stack
from
engineering
perspective.
A
You
will
not
find
people
who
are
understanding
and
the
full
and
taking
the
full
accountability
of
what
they
are
developing
so
and
it's
because
of
lack
of
process,
or
you
can
say,
the
environment
in
which
we
are
all
operating
and
it's
fast
moving,
and
there
are
so
many
external
factors.
So
how
do
we?
How
do
we
move
forward
from
there
right?
A
So
my
recommendation-
and
what
I
have
seen
is
that
don't
don't
try
to
create
a
perfect
team,
you,
you
will
always
have
20
percent
or
30
percent
of
your
team
to
be
more
skilled
in
full
stack
when
I
say
full
stack.
You
know
they
know
some
job
python.
They
know
ui
development.
They
know
docker
containerization
cloud
devops
and
up
to
up
to
extent
so
that
they
can
be
operational
and
they
can
make
it
work,
but
their
majority
of
team,
like
30
percent
to
40
percent
of
the
team.
A
We
you
have
to
mentor
them,
so
you
need
to
create
the
right
path
and
that's
the
one
challenge
which
I
have
seen
in
my
experience
that
how
do
you
enable
your
team?
It's
also
important.
So
that's
the
recommendation.
Is
that
how
you
create
a
path
for
rest
of
the
team
and-
and
the
third
part
is
don't
beat
the
dead
horse?
Don't
try
that
you
know
everybody
should
be
full
stack
so
specializes.
A
If
somebody
is
a
specialized,
a
mongodb
expert,
for
example,
that
doesn't
hurt,
because
sometimes
suppose
you
are
building
something
and
you
have
a
very
specific
problem.
Maybe
you
want
to
use
that
expertise,
so
don't
just
you
know
get
into
the
trap
of.
I
need
everybody
to
be
full
stack,
so
we
need
to
be
practical
also.
So
that's
the
second
challenge
which
I
just
wanted
to
highlight.
A
The
third
one
is
again
core
to
my
heart.
It's
about
the
over
engineering
and
when
often
as
a
technologist,
we
we
start
looking
at
everything
is
an
engineering
problem
and
then,
when
we
start
solutioning
it
we
tend
to
over
engineer
the
solution
right
so
and
micro
services
is
not
away
from
that.
You
know
we
started
the
the
whole
micro
services
concept
was
start
got
started
because
we
wanted
to
make
it
more
business
centric.
We
wanted
to
make
sure
that
we
follow
domain
driven
design.
A
We
follow
business
needs
that
I
want
to
scale
quickly.
I
want
to
enable
the
organization
so
that
there
are
less
failures
and
all,
but
over
the
period
which
we
are
seeing
and
and
everybody
will
acknowledge
that
it's
becoming
more
and
more
complex,
so
the
stakeholders
also
do
not
have
the
same
expectation.
They
used
to
have
five
years
back.
A
That's
a
key
challenge
which
I'm
I'm
seeing
right
now
they
have
a
higher
expectation
earlier
people
will
people
were
okay
if
the
site
is
down
for
say
three
minutes
right,
but
everybody
is
now
aware
of
distributed
architecture
microservices
cloud,
so
they
have
like
millisecond
downtown
downtime
expectation
they
have.
They
know
that
you
can
time
you
can
you
need
to
bring
the
products
to
market
quickly,
so
they
they
understand.
A
There
is
a
complexity
behind
it,
but
they
do
also
understand
that
we
are
enabling
our
developers
and
technical
team
and
engineering
team
to
bring
the
products
quickly
to
the
market,
so
the
expectation
is,
is
the
key
challenge.
That's
why
you
have
to
also
understand
that.
How
do
you
solve
and
make
sure
that
you
meet
those
new
expectations
which
we
are
seeing
in
the
newer
world?
So
my
recommendation
coming
from
last
five
years
of
what
I've
been
seeing
and
reading
about
from
industry
experts
as
well.
A
Is
that
keep
your
keep
your
focus
in
solving
business
problem?
It's
it's
a
it's
not
simple.
I
understand
that
there
are.
There
are
always
you
know,
different
priorities,
but
if,
if
somehow,
we
need
to
make
sure
whether
it's
developers,
whether
it's
you
know
your
testers,
you
need
to
help
them,
get
the
business
context
first
and
give
them
the
business
knowledge.
The
domain
knowledge
that
will
keep
their
engineering
focus
also
on
solving
the
business
problem-
and
I
know
in
this
world
we
we
get
to
have
a
lot
of
cool
technologies
every
day.
A
There
is
something
new
coming
up,
but
that
doesn't
mean
that
that's
going
to
help
solve
the
business
problem.
Business
wants
something
which
can
help
them
get
the
business
outcomes.
So
my
second
point
is
that
cool
tech
is
good
but
focus
on
solving
again
the
business
problem
tying
back
to
the
first
point
and
simplification.
I
understand
it's
not
easy,
but
we
we
as
leaders
and
we
as
seniors.
We
need
to
make
sure
that
we
can
keep
it
simple
and
the
team.
A
Also
we
get
the
same
message
that
you
know
how
to
keep
the
architectural
engineering
simple.
So
don't
don't
solve
the
problems
which
that's,
the
essence
of
you
know
are
learning
in
the
life
that
don't
solve
the
problem,
which
have
already
been
solved.
For
example,
I'm
just
quoted
few
that,
if
you're
using
service
communication,
if
you're
using
you,
know
service
message,
you
use
that
rather
than
try
to
start
building
the
service
mess
framework
yourself
right.
A
A
You
have
already
passed
that
gate
and
and
then,
if
you
push
back
to
business
that
oh
it's
not
possible
for
me
to
now
develop
this,
then
it's
too
late
and
you
will
be
pushed
the
corner.
So
so
that's
where
we
need
to
first
see
that
you
know
how
you
get
involved
and
and
that
involvement
part
is
which,
where
I
see
a
key
challenge.
A
The
second
part
is
where,
when
you
get
to
the
estimating
your
work,
which,
because
that's
your
project
managers
need
that
to
plan
the
roadmap,
you
see
that
either
developers
are
overestimating
or
being
over
aggressive
or
underestimating,
and
both
both
side
of
the
world
are
something
which
is
not
going
to
help
right
so
and
I've
seen
that
you
know
this
happens
quite
often,
so
we
and
we
talked
about
awareness
of
the
business
that
that
is
a
key
essence
all
the
time.
So
how
do
we?
A
How
do
we
solve
that,
and
I,
I
think
in
my
experience,
engaging
with
business
and
product
team
and
asking
why
and
what
and
is
that
why
you
are
doing
this?
Why
you
need
sometimes
I've
seen
this?
You
know
a
simple
question
might
might
unpack
something
bigger
and
and
that's
why
even
a
developer,
even
a
new
developer,
who
is
new
to
the
team,
may
bring
a
fresh
perspective
right.
So
it's
very
important
that
we
we
engage
with
business.
A
We
understand
and
ask
the
right
questions
and
we
involve
early
right.
It's
shift
left
is
not
only
for
technology
shift.
Left
is
also
for
requirements
gathering,
so
we
it's
always.
I
recommend
that
you
know
if
you
can
bring
on
developers
early
in
the
game
so
that
they
can
identify.
The
second
point
is
related
to
that.
They
can
identify
few
things
which
are
accelerators
few
things
they
can
see
that
you
know
these
are
something
which
I
can
I
can
help
you
accelerate.
A
They
can
come
up
with
new
suggestions
and
and
maybe
they
can
build
something
which
can
help
you
develop
our
product
faster
and
deliver
faster.
So
estimating
is
always
an
essence
and
we
can
guide
the
team
that
how
you
can
make
sure
that
you
estimate,
but
estimates
are
estimates
you
need
to
make
sure
that
the
business
understand
if
you
discover
something
new
and
they
they
get
informed
on
time.
So
that's
something
which
is
my
third
recommendation.
You
have
to
inform
them.
Nobody
wants
surprises
these
days.
You
need
to
give
them.
A
You
know,
okay,
this
is
something
which
I
have
seen
and
based
just
surface
all
the
issues
early
on
in
the
game
and
then
sharing
your
perspective
is
the
essence,
because
I
still
believe,
even
even
if
you're
a
junior
developer
you're
a
senior
developer,
it's
always
good.
Don't
shy
away
from
asking
question:
don't
shy
away
from
sharing
your
perspective
that
that's
the
that's?
A
That's
the
key
recommendation,
so
the
fifth
thing
which
the
challenge
perspective,
which
I
have
seen
in
terms
of
now,
it's
a
technology,
can
we
are
moving
towards
a
technology
angle
now.
So,
if
you
remember
the
people
process
technology,
so
language
and
framework
is
is
in
essence
when
we
are
talking
about
distributed
architecture.
A
Now,
when
I
say
language
and
framework
you
and-
and
we
are
I'm
just
giving
an
example
of
java
jee
is
the
java
has
evolved
in
last
15
years
and
there
are
many
frameworks,
so
you
can
see
that
you
know
there.
It
started
with
the
you
know,
simple
ejb
and
all,
and
then
we
have
some
lightweight
frameworks
like
spring
framework.
We
have
reactive
frameworks.
A
We
have
frameworks
built
on
different
paradigms
right
so
and
nowadays
you
must
have
heard
how
oracle
has
they
came
up
with
haliden
and
qarcus
is
a
new,
so
these
are
new
frameworks
coming
up
so
every
day
there
is
something
new
coming
up
so
developer.
The
key
challenge
which
I
see
is
they
get
overwhelmed
and
and
then
they
think
that
you
know
I
have
to
learn
a
new
framework.
A
What
is
the
best
and
suitable
framework,
or
even
language
right,
whether
it's
python,
java
or
golang
nowadays
that
what
is
the
best
framework?
So
that's
a
key
challenge,
which
I
I
see
that
you
know
it's.
You
know
every
day
we
are
facing
this
question
by
you
know,
especially
the
engineering
team,
and
what
I
would
recommend
is
that
don't
go
don't
get
you
know
kind
of
overwhelmed
by
by
the
set
of
languages.
Languages
and
frameworks
are
giving
you
choices.
You
have
many
choices,
the
in
today's
world.
A
It
doesn't
mean
that
you
have
to
accept
all
those
parameters
and
take
all
those
choices,
learn
everything
we
choose,
something
which
is
suitable
choose
something
suitable.
As
per
your
context,
so
suppose
I
have
seen
this
and
I've
used
play
framework.
I'm
quoting
that
example.
Few
years
back,
we
were
building
something
for
a
hotel
website
and-
and
we
felt
that
you
know
reactive
is
where
we
wanted
to
build
a
reactive
system.
A
So
we
chose
certain
micro
services
to
be
developed
in
play
framework
if
you
feel
that
certain
things
are
best
suited
for
a
spring
framework.
Go
ahead
with
that,
if
you
think
that
you
know
certain
things
are
suited
for
python,
because
it's
it's
something
which
is
very
simple
and
effective
and
you
are
building
something
data,
science
related
or
anything
which,
which
is
better
suited,
use
that
so
don't
get
overwhelmed.
A
If
you
have
your
fundamentals
right
believe
me
learning
a
new
language,
it's
not
difficult,
and
also
your
micro
service
world
doesn't
tell
you
that
you
have
to
stick
to
one
language.
You
can
choose
what
is
more
suitable
in
a
particular
context.
Right,
so
polyglot
is
the
key
that
you
see
that
micro
services
world
is
more
about.
A
The
only
constant
and
you
don't
need
to
you-
know
kind
of
make
that
you
know
I
have
to
only
use
one
language
in
microservice
world
right.
So
the
sixth
thing
which
I
have
seen
once
you
choose
the
language
and
framework
it
comes
about
the
communication
that
now
you
have
many
microservices
and
how
these
services
are
now
talking
to
each
other.
A
So
selecting
the
right
communication
pattern
is
something
which
I've
seen
is
a
bigger
challenge
because
inter-service
communication,
again
the
you
when
you,
google,
it
out
you'll,
see
many
patterns
right
there,
the
synchronous
patterns
there
are
asynchronous
patterns.
Some
people
are
saying
that
you
know
synchronous
is
bad.
Some
are
saying
asynchronous,
you
know,
has
some
resiliency
and
all
those
good
things,
but
then
maintaining
it.
It
could
be
a
challenge.
So
so
there
is
multiple
school
of
thoughts
and
that's
a
key
challenge.
A
So
maybe
that's
good
for
in
in
a
particular
scenario,
if
you
want
to
d
develop
a
d
cable
system,
you
can
create
an
event-driven
application
and
an
event
driven
is
the
future
and
again
even
driven
is
supported
by
your
async
patents
and
then
again
they
have
a
lot
of
patents
to
choose
for
so
go
read
about
what
is
saga
pattern
where
you
can
differentiate
between
a
choreographer
where
you
have
a
central
orchestration.
Has
a
central
component.
A
Choreography
is
little
bit
different,
how
you
can
use
cqrs,
where
you
can
separate
out
the
command
and
query
or
even
sourcing,
where
you
know
you're
saving
everything
as
an
event
and
replaying
that
right
so
understand
these
patterns
and
apply.
As
per
your
context,
there
is
no
silver
bullet
for
sure
and
the
other
thing
which
I
see
that
it's
evolving
and
need
consideration
is
that
what
is
the
format
in
which
you
can
talk
right
now?
A
We
have
many
choices
which
is
good
and
which
is
which
can
be
overwhelming,
but
you
need
you
need
to
see
that
you
know
json
has.
It
has
been
a
standard
for
quite
a
while
now
after
soap
and
all-
and
you
can
see
that
now
graphql
is
giving
you
a
unified
endpoint
to
talk
and
it's
providing
your
ui
with
one
single
endpoint
so
that
you
can
aggregate
the
data
and
and
take
care
of
it
or
maybe
it's
suitable
in
certain
ui
application.
A
Similarly,
if
you
are
building
a
chatty
and
a
binary
protocol
based
application,
maybe
the
grpc
is
better,
which
is
the
request
response
based
model
right
so,
but
there
are
now
new
patterns
coming
up
for
async
like
using
web
sockets
to
buy
duplex
communication
and
all
and-
and
you
can
explore
how
you
can
implement
that
with
kafka
event
driven
and
web
sockets.
So
these
are
your
choices
that
doesn't
mean
that
you
need
to
use
all
of
them
or
choose
one
of
them
again.
The
key
messages
apply
the
pattern.
A
I
have
seen
this
in
my
last
application
when
we
were
doing
it,
we
had
still
some
rest
services,
because
in
that
scenario,
that
was
working
out
best-
and
that
was
something
which
is
simple,
and
we
didn't
need
to
over
engineer
that
part
so
select
the
right
pattern
based
on
what
you
see
is
suitable
in
that
context.
So
there
is
no
bad
choice
here.
A
The
next
one
is
about
how
you
manage
your
growing
list
of
micro
services
so
often
and
and
this
number
of
micro
services.
It
typically
is
you
start
small
and
you
start
splitting
your
monolith
into
microservices
and
it
it
quickly.
You
will
see
that
you
know
start
growing
and
and
you
will
have
50
hundred
and
thousands
of
services.
So,
in
my
experience
maintaining
when
you
are
maintaining
like
20
30
services,
it's
still
maintainable,
you
can
maintain
even
a
catalog
in
your
excel
file
that
that's
not
a
problem.
A
You
can
use
an
application
performance
monitoring
tool
for
tracking
dependency,
not
a
problem,
but
the
key
challenge
when
it
start
growing,
then
basically
you'll
see
that
you
know
there
is
a
lot
of
dependency
and
failures
and
different
things
will
start
popping
up.
So
so
keeping
and
your
team
composition
is
also
another
factor
which
you
need
to
see,
and
that
becomes
a
key
challenge
in
in
the
current
distributed
architecture,
context
and
my
recommendation-
and
we
have
done
this-
we
have
burnt
our
finger
where
we
started
building
something
in-house.
A
I
would
strongly
say
that
don't
reinvent
the
wheel,
there
are
now
companies
like
autelius
and
and
I've
seen
this
product
where
I'm
just
quoting
the
key
features
which
I
liked
from
there
is
where
I
can
see
that
it
takes
care
of
most
of
the
need,
which
I
have
to
do
it
myself,
that
how
do
you
create
a
catalog
of
services?
How
do
you
keep
the
versioning?
How
do
you
keep
the
inventory
of
your
services?
How
do
I
support
the
blue
green
deployment?
A
So
all
the
things
which
you
need
is
something
which
you
can
get
out
of
the
box,
so
I
think
explore
that
I'm
not
recommending
that
use
that
tool
only,
but
explore
that
and
and
understand
you
know,
instead
of
using
something
which
is
or
building
something
which
you
think
that
it's
it's
gonna
take
a
lot
of
time.
You
can
reuse
something
where
somebody
has
solved
that
problem
for
you,
so
management
of
services
recommendation
is
go
for
and
find
the
suitable
out
of
the
box
solution
and
make
it
more
operational.
A
So,
moving
on
the
eighth
lesson
is
more
about
related
to
previous
point:
how
do
you
ensure
governance
and
and
distribute
or
micro
services
architecture,
and
why
governance
is
important?
And
because,
in
my
experience
I
have
seen
that
when,
when
we
started
building
microservices
architecture,
that
outer
architecture-
and
when
I
say
outer
architecture,
service
itself
is
very
simple
right
service
is,
has
a
because
it's
micro,
it
has
to
be
simple.
A
It's
talking
to
a
database,
it's
sending
the
data
back
to
the
you
know
the
other
components,
whether
it's
even
driven
or
risk
based,
but
the
other
elements
like
how
do
you
ensure
security?
How
do
you
ensure
communication?
How
do
you
monitor
how
where's
the
platform
as
a
service?
The
other
elements
play
a
much
bigger
role
and
then
it
becomes
a
key
challenge,
because
what
happens
is
that
people
start
developing
their
own
kind
of
a
solution
where
they
start
building
their
own
patterns
within
the
organization?
A
So
the
key
recommendation,
I
would
say
in
this
case
is-
is
to
promote
the
culture
of
a
platform
team,
and
this
I
have
seen
in
many
organizations.
Now
they
have
started
adopting
this
because
platform
team
is
nothing
but
considered
as
a
common
team,
which
is
basically
responsible
for
creating
those.
You
know
common
considerations
and
accelerators,
and
and
you
can
be-
you
don't
need
to
say
that
you
know
these
are
the
only
set
of
people
who
are
doing
it.
A
You
can
also
participate
and
give
your
ideas
to
that
team,
but
essentially
it's
all
all
about
maintaining
consistency
in
the
architecture,
so
that
will
that
helps
a
lot
in
my
experience
that
helps
a
lot
to
establish
common
set
of
practices,
guidelines
and
guardrails,
which
will
help
the
entire
team
and
especially
microservices,
evolved
that
you
know
we
wanted
to
give
independence
to
the
team
right
so
again
by
having
governance.
That
is
that
doesn't
mean
that
you
have
to
enforce
something
so
that
the
team
do
not
lose
that
autonomy
right.
A
Where,
eventually
we
are,
you
are
at
a
stage
your
service
is
developed,
and
now
you
are
deploying
the
service
and
and
and
then
there
are
many
choices
right
so
in,
and
my
experience
which
I
have
seen
is
that
I
know
we
have
again
many
choices
like
the
framework
part
which
we
have
seen
and,
like
the
business
expectation,
the
key
challenges.
Now
business
doesn't
worry
about
technology.
They
they
just
need
that
there
is
no
down
time.
A
There
is
a
quicker
time
to
market,
so
they
have
a
simple
expectation,
and
sometimes
I
I
see
that
even
the
key
meeting,
these
simple
things
are:
it's
it's
very
difficult
because
of
the
complexity
behind
the
scene
right.
So
so
the
key
recommendation,
I
would
say,
is
and
then
that's
coming
out
as
a
as
a
common
sender,
is
that
if
you
have
not
adopted
kubernetes
right
now,
you
need
to
start
considering
as
part
of
your
strategy
as
a
foundational
framework.
A
If
you're
a
developer
learn
kubernetes,
that's
going
to
be
a
new
linux
new
standard
in
the
industry
and
I've
been
using
for
last
five
plus
years.
I've
seen
that
you
know
how
it
has
grown
from,
you
know,
grown
towards
becoming
and
industry
standard
right,
so
leverage
the
patterns
which
are
the
ecosystem
around
kubernetes
is
also
emerging.
So
you
I've
laid
down
certain
strategies
that
when
you
are
using
kubernetes,
if
your
team
is
not
too
technology
friendly,
you
can
use
managed
services.
A
You
can
use
serverless,
you
don't
need
to
kubernetes
doesn't
mean
you
have
to
manage
kubernetes
yourself,
so
you
have
many
choices.
So
talk
to
your
architect
understand
talk
to
your
leadership
team
understand
what
strategy
you
want
to
apply
and
and
and
follow
that
path
so
but
adopting
is
the
is
the
key
part,
and
you
will
not
regret
that
because
the
more
you
worry
about
infrastructure,
the
more
you
know,
the
less
focus
you
will
have
on
your
solving
the
business
issue.
So
I
think
that's
the
essence
which
I
can.
A
I
can
see
that's
happening
in
my
experience,
so
we
are
down
to
the
last
one,
but
the
most
effective
one,
I
would
say
the
troubleshooting
in
microservices
architecture.
So
so,
when,
when
you
develop
something
right
and
when
you
hand
it
over
right
now,
the
the
hand
over
part
is
something
which
is
gone
in
these
days.
So
the
key
principle,
if
you
consider
like
devops,
is
not
just
tools
and
technology
devops
is
more
about.
If
you
have
developed
it,
you
will
operationalize
it
and
you
might
have
to
maintain
it
as
well.
A
A
So
it's
it's
good
to
see
that
how
the
operations
people
experience
the
application
and
their
pain.
So
you
need
to
spend
time
understanding
the
production,
operationalization
aspect
of
it
and
you
need
to
train
people
with
the
right
set
of
tools
and
technology
and
fail
fast.
I
think
that's
the
key
message,
so
you
know
like
they
say
in
the
book
is
hope,
is
not
a
strategy.
A
You
can
say
challenges
and
I've
shared
my
experience
and
hopefully
you
might
get
benefited
out
of
it.
So
I
just
want
to
say
thank
you,
everybody
for
listening
to
me
and
you
can
follow
atlas
on
the
links
here
and
you
can
follow
me.
I've
shared
my
twitter,
linkedin
and
medium
link
so
happy
to
engage
in
any
conversation.