►
From YouTube: Microservices Implementation Stories- March Podcast
Description
Hosted by Saim Safder with guest speaker Brad McCoy discussing microservices implementation stories. Join Brad McCoy as he talks about getting started with microservices.
A
A
B
Sure
so
my
name
is
brad.
I'm
yeah,
as
I've
said,
from
new
zealand,
I'm
currently
working
in
australia
at
the
moment
in
queensland,
so
working.
I
recently
moved
back
to
software
engineering.
So
before
I
was
the
head
of
platform
engineering
doing
a
lot
of
cloud
and
devops,
and
then
I
decided
you
know
to
it
was
getting
a
little
bit
boring
for
me
to
you
know:
do
yaml
files
all
day
and
I
felt
like
I
sort
of
mastered.
B
You
know
most
of
it,
so
I
decided
to
go
back
into
software
engineering
to
then
apply
that
knowledge
to
make
the
apps.
You
know
work
in
the
cloud
and
not
the
other
way
around,
so
other
companies
that
I
work
for
they
would
build
the
code
and
then
they
would
just
say:
okay,
here's
the
code.
Can
you
put
it
somewhere,
whereas
now
I'm
going
to
try
and
take
a
step
back
and
try
and
build
those
apps
to
be
working
in?
B
A
Yes,
absolutely
absolutely
brad
is
a
wonderful
guy,
he's
helping
us
a
lot
in
the
hotelies
community
and
he's
helping
us
connect
with
the
highly
skilled
individuals
from
the
industry
and
we're
really
really
looking
forward
to
his
contribution.
So
tell
us
about
as
we're
talking
about
today.
The
micro
services
and
the
one
of
the
tools
that
we
are
developing
on
the
hotelier
side
is
kind
of
kind
of
getting
people
life
more
easier
who
are
migrating
to
the
microservices
architecture,
because
it's
really
a
painstaking.
A
It
looks
very
attractive
in
a
theory,
but
when
you
implement
a
microservices
base
architecture,
it's
really
really
a
painstaking
task.
There
are
so
many
like
you
have
a
one
box
previously
where
everything
is
reside
in
that
box
and
when
you
want
to
distribute
those
application
in
a
separate
languages
on
a
separate
deployment
matter.
It's
look
really
really
a
difficult
model
to
implement
at
so
tell
us
about
first
or
your
own
story
of
migrate.
B
A
B
To
you
have
three
months
to
do
this,
so
it's
very
tough
like
to
do
the
actual
planning
of
it
as
well,
because
if
you
have
time
to
market
where
your
product,
you
know
you
want
your
product
in
the
hands
of
customers
straight
away
and
not
disrupting
sales
marketing
or
the
other
side
of
the
business.
So
technically,
it's
probably
you
know
pretty
straightforward,
but
all
these
other
factors
coming
into
it
as
well.
It's
really
difficult!
So
things
like
you
know.
B
Traditionally,
you
know
a
monolith
would
have
like,
let's
say
one
one:
data
store,
maybe
one
database
for
example,
and
now
that
if
you
have
like
10
micro
services,
you
know
it
said
that
in
a
true
microservices
architecture,
they
should
have
their
own
data
store.
So
things
like
reporting
become
harder
as
well,
because
from
when
you
used
to
run
your
reports
for
accounting
or
sales
or
custom
success
managers
you,
instead
of
just
querying
one
database
and
maybe
uploading
it
to
a
data
warehouse
or
data
lake.
You.
B
How
should
this
microservice
talk
to
each
other?
How
should
it
expose
itself
and-
and
you
can
really
go
around
in
circles
as
well?
So
I
think
the
biggest
pain
point
that
I've
seen
is
that
businesses
don't
really
truly
understand
what
they
are
and
and
how
they
work
in
the
business,
because
they
can
always
work
a
little
bit
differently.
So
so
that's
some
of
the
challenges
that
I've
seen
I
mean
the
technical
stuff
is
a
little
bit
easier,
but
it's
agreeing
with
all
the
business
as
well.
B
That's
the
hard
part,
so
you
have
to
agree
with
engineering.
They
have
to
understand
why
you
do
it.
You
have
to
agree
with
the
cloud
team,
the
architecture
team
when
it's
a
startup,
it
does
become
a
lot
easier,
so
yeah
that
that's
just
some
of
them
that
I
can
think
of
show
away,
but
it
is
yeah
even
like
team
topologies
as
well.
B
Cost
as
well,
so
I
think
sql
server
being
used,
so
they
wanted
to
pull
a
sql
server
database
and
they
wanted
to
do
microservice
architecture,
so
they
then
had
they
had
10
sql
server.
You
know
which
cost
a
lot
of
money,
and
these
are
for
small
things
as
well,
so
they
could
have
used
or
something
like
that.
B
But
the
old
mindset
of
being
in
sql
server
sort
of
so
old
mindsets
is,
you
shouldn't
really
carry
that
to
the
microservice
world
as
well,
so
they
and
remember
like
when
you
have
10
when
you
have
10
databases,
if
you
have
four
environments,
that's
generally,
you
know
times
four,
you
know,
let's
just
say
traditional
dev
test
staging
uat
or
prod.
You
know
around
four.
B
B
You
know
breaking
your
code
down.
You've
got
to
think
about.
You
know
how
can
this
code
talk
back
to
the
other
microservice
or
function?
How
can
we,
how
can
we
not
make
development
time
slow
down
and
lead
time?
You
know,
although
all
those
metrics,
that
we
look
at
as
business
of
how
we're
performing
and
and
even
I've,
seen
like
tech
debt
being
made
with
new
services
as
well
so
yeah
in
general,
the
biggest
challenges
I've
seen
are
actually
with
people.
A
Absolutely,
yes,
absolutely
absolutely!
I
think,
like
I,
I
I
just
started
the
conversation
like
we
know
there
are
some
limitations
to
the
traditional
model
and
you
need
to
know
like
it.
The
microservice
gives
you
a
lot
of
the
flexibility
like
if
I'm
using
the
language
and
some
of
the
people
are
using
the
ruby
languages.
Having
a
previous
model
doesn't
give
me
that
kind
of
flexibility
to
have
two
different
languages
and
the
same
same
box
with
everything
written
inside,
but
now
we
distribute
these
responsibilities
with
the
different
teams.
A
So
I
can
write
my
microservices
in
dotnet
and
somebody
else
work
write
their
microservices
and
go
language
and
somebody
else
is
writing
their
language
in
the
ruby
on
rails.
That's
good!
That's
really
good
model
that
everybody
like
about
it,
but
as
you
man,
as
you
draw
from
the
conversation
like
how
you
can
orchestrate
these
micro
services
at
the
run
time,
how
they
behave
and
how
they
interact
with
it.
A
That's
really
a
challenging
how
the
communication
between
these
micro
services
is
another
challenge
and
what
are
the
patterns
available
for
us
as
a
as
a
technologist
in
this
era
of
time
to
having
a
micro
services
communication
rather
simpler
or
not
making
us
complex?
I
think
this
is
the
communication
challenges
and
also
there's
a
bridge
of
gap,
because
when
you
talk
to
the
you
develop
something
you
are
in
isolation,
you
think
there
are
things
moving
in
a
very
good
direction,
but
you
need
to
coordinate
your
decision
to
the
another
team
as
well.
A
So
I
seen
these
kind
of
the
isolation
isolation
in
the
in
my
current
setup
and
I'm
talk
and
we
are
working
out
for
ways
to
kind
of
have
more
communication,
more
communication
channels
within
the
team,
so
they
can
have
leverage
more
these
kind
of
setup
and
also
tell
us
about
like
what
are
the
deployment
pattern
you
see,
often
in
the
or
in
the
industry.
Right
now
previously,
we
have
tab
staging,
and
that
is
for
the
for
the
whole
projects.
But
when
you
develop
some
of
your
own
micro
services,
what
do
you
think?
A
What
is
the
best
way
to
test
these
micro
services?
Either
you
create,
as
every
micro
service
has
their
own
depth
changing
or
production
or
either
you
have
a
what
are
the
other
other
deployment
strategies
available,
because
that's
really
look
complex.
In
theory,
every
micro
services
has
draft
staging
and
production
because
you
need
to
have
a
cost
with
it
for
every
deployment
model.
What
do
you
see
where
the
industry
is
going
and
what
are
the
different
deployment
strategies
today
exist
in
the
motor
versus
implementation.
B
Yeah,
so
that's
a
good
question:
there's
yeah
there's
no
real
way
around
the
the
cost.
You
know
if
you
do
have
all
these
environments.
I've
been
working
with
a
lot
of
offshore
teams
lately
as
well
and
I've
seen
a
lot
of
the
developers
are
not
really
testing
these
things
on
their
local
computer
anymore
as
well,
which
is
quite
shocking
for
me.
You
know,
I
mean
you
know:
how
can
you
as
a
developer?
How
can
you
test
that
your
code
actually
works?
B
So
I've
seen
a
lot
of,
like
you,
said
the
environment,
a
lot
of
test
environments
being
made.
I
think
sasha's
company
has
like
30
qa
environments
or
something
which
is
you
know,
that's
a
lot,
that's
quite
crazy.
We
put
for
ateliers,
for
example,
you
know
we
had
we
had
the
discussion
as
well.
I
was
like:
do
you
do
mono,
repro
or
polyrepo?
So
are
you
going
to
have
all
of
your
code
for
that
up
and.
A
B
One
code,
or
are
you
going
to
have
it
in
in
many
and
and
these
are
debates
that
people
have
as
well
like
this
way,
is
better.
This
way
is
better,
but
for
ateliers
we
have
charts
repro
as
well,
so
we
have.
We
use
the
helm
releaser.
So
what
that
is,
is
it's
a
github
action
that
will
it
leverages
github
pages
and
then
that
will
index
the
helm
chart,
that
is
on
the
poly
repo
and
then
it
will
update
the
the
helm
chat
repro.
So
then
you
have
in
artifact
type.
B
You
have
a
really
nice
catalog
of
helm,
charts
that
you
can
use
for
italia
so
that
I
feel
like
that,
really
helps
the
environments
to
to
sort
of
bring
that
back
into
the
devs
computer
as
well,
which
I
like
to
see
just
just
having
the
ability
for
them
to
to
run
that
on
the
kubernetes
cluster.
You
know
like
there's
so
many
great
lightweight
distributions,
like
k3s
kind.
You
know,
there's
probably
10
or
15
of
them,
but
yeah.
B
I
I
think
one
key
thing
is
to
to
just
really
standardize
on
what
you're,
what
you're
doing
you
know
for
all
these
teams
and
and
come
up
with
your
home
charts
and,
and
you
know,
for
strategies
deployment
we
use,
get
ops
as
well,
so
that's
its
own
little
yeah.
Well,
it's
his
own
big
challenges
as
well.
Once
you
start
to
go
into
there,
then
you
have
you
know,
secrets
and
but
we're
using
get
ups
as
well
to
to
look
at
these
charts
and
then
deploy
them
to
our
clusters
as
well
to
different
environments.
B
A
A
Where
you
see
how
my
microservices
are
actually
behaving,
it's
some
of
the
microservices
that
goes
down
some
of
the
goes
up.
What
is
current
factor?
Is
it
pending
state?
Is
it
crashed
down?
Is
it
started?
What's
this
bringing
and
you
tell
us,
do
you
have
some
solution
available
today
on
these
kind
of
dasha
dashboard,
then
they
can
tell
us
the
24
hours,
seven
statistics,
statistics
of
our
microservices
deployment
model.
B
Yeah,
I
think
that's
a
good
I
I
guess
a
lot
of
the
stuff
we're
talking
about
as
well.
There's
a
big
gap
in
the
it
market
for
devops
engineers
too.
So
it's
actually
really
difficult
to
get
a
good
one
at
the
moment
and
you
have
to
pay
so
much
money,
so
we're
seeing
a
lot
of
companies
like
one
example
would
be
vmware.
The
the
understanding
that
you
know,
kubernetes
is
probably
just
the
underlying
platform
but
they're
trying
to
put
things
on
top
to
make
all
that
stuff
easier.
B
So
you
know
you
can
use
in
terms
of
observability.
If
we're
talking
free
and
open
source,
we
can
use
prometheus
grafana
loki
and
and
then
what
we're
doing
with
ortelius
as
well.
Is
that
so
you
know
autelius
will
catalog
the
the
microservices,
so
we
can
see
the
sprawl
because
that
that
maybe
we'll
talk
about
that
after
that,
that's
the
whole
secret
problem.
B
But
if
we
look
at
how
we're
deploying
with
ortelius,
then
we
we're
using
kept
in
so
we
have
argo
cd
and
then
that's
going
to
pick
up
the
change
and
then
kitten
will
come
along
and
then
it
will
have
the
quality
gate.
So
we're
going
to
use
the
quality
gates
to
to
make
sure
you
know
with
our
prometheus
metrics
and
the
the
so
we're
doing
progressive
delivery.
So
so
we're
starting
off
you
know
in
and
test
uat
prod
and
the
quality
gate
will
say.
Yes,
this
is
right.
B
A
B
We're
doing
all
that
open
source,
which
is
quite
cool
in
terms
of
what
you
said
about
services
down
with
kipton.
You
can
use
remediation
as
well,
so
one
really
cool
podcast
I've
seen
recently
was
with
crossplane
and
captain
and
they
were
talking
about.
Let's
say
you
have
your
you
know.
As
you
know,
crossplane
is
infrastructure.
As
code,
it's
like
more
of
a
cloud
native,
you
know
born
in
cloud
native
world.
B
You
can
use
git
ops
as
well,
so
they
were
talking
about
using
crossplane
for
infrastructure
in
aws
and
if,
if
you
hook
up
like
prometheus
or
dynatrace
to
captain,
they
can
say:
okay,
there's
a
I'm
sitting
in
a
problem
event,
and
then
the
event
will
say:
okay
aws
is
down.
Then
you
have
a
remediation
sequence.
That
will
say:
okay.
This
is
telling
me
it's
down.
B
B
B
You
know
that's
probably
expensive
as
well,
but
you
just
have
to
balance
out
what
you
think
is
the
right
way
to
do
it
yeah.
So
I
I
think
we
can
see
the
pattern.
That
cost
is
quite
a
problem
here
as
well,
especially
in
I.t
at
the
moment,
because
there's
such
a
shortage
of
of
workers.
So
if
you
have,
you
know,
let's
say
in
the
us
where
they
have
big
salaries
for
kubernetes,
let's
say
if
you're
almost
paying
quarter
of
a
million
dollars
for
one
kubernetes
engineer,
that's
a
million
dollars
for
four
people.
B
B
So
yeah
for
observability
I
mean
yeah,
there's
so
many
great
tools
that
you
can
just
plug
and
play
these
days
as
well.
You
can
use
tools
like
argo
or
flux
or
yeah
we're,
seeing
it's
a
really
fascinating,
prop
project
the
autis
get
ups
project
because
we're
lucky
enough
to
sort
of
play
around
with
that.
So
if
anyone
wants
to
contribute,
you
can
see
on
the
banner
there
please
reach
out,
like
I
think,
working
with
hoteliers
as
well.
B
It's
probably
one
of
the
my
favorite
communities
in
projects
because
everyone's
so
friendly,
like
you
know,
you
have
tracy
steve
yourself
and
it's
a
good
opportunity
to
like
just
jump
in
and
do
what
you
want
and
you
can
the
when
I've
been
to
other
projects.
I
find
it
really
hard
to
you
know.
You
say
cannabis
have
a
good,
a
good
first
issue,
but
there's
so
many
like
enterprise
people
like
red
hat,
ibm,
oracle,
microsoft
and
you
can't
really
get
into
that
project
and
you
know
have
a
passion
for
making
something
big.
B
A
B
B
A
Also,
we
are
really
heavily
investing
with
the
micro
services
based
deployment
model
micro
services,
dashboard,
the
catalog,
and
we
use
some
of
the
good
open
source
tooling
ourselves
as
well.
Like
the
captain
project,
the
august
cd.
We
know
these
are
the
projects
has
a
very
good
benefit
and
we
use
those
benefit
as
a
hoteliers
community
and
that's
a
good
thing.
A
You
have
done
wonderful
project
over
the
last
few
years,
the
tillius
side,
you
integrate
captain
project,
the
argo,
cd
and
other
tools,
other
open
source,
tooling.
It
tells
us
people
who
are
really
have
their
experience
with
their
own
open
source
tooling,
and
they
want
to
integrate
their
open
source
tooling,
with
our
earliest
open
source
project.
So
what
are
the
way
they
can
contribute?
What
is
the
way
they
can
hope
this,
their
integration
with
our
open
source,
tooling,.
B
Yeah,
so
we
we
have
a
a
discord
channel
with
with
a
good
ops
channel
that
you
know
you
can
come
and
say,
hello,
and
I
mean
a
lot
of
there'll
be
a
lot
of
different
use
cases
for
folks
that
want
to
adopt
what
we
have.
It's
almost
finished.
It's
probably,
I
would
say,
80
done
we're
getting
on
to
the
service
mesh
side
of
it
now
as
well.
So
that's
very,
very
interesting.
B
This
project
is
very
interesting
because
we
get
to
play
around
with
all
those
cool
things,
so
we're
starting
to
look
at
argo,
rollouts
and
and
different
deployment
strategies.
So
you
know,
as
you
know,
argo
cd
will
just
pick
up
the
home
chart
and
deploy
it,
but
we're
starting
to
look
at
well,
okay.
Well,
what?
If
we
want
to
do
like
blue
green?
B
So
it's
at
a
very
fun
point
and
we're
we
normally
have
meetings
australian
time
in
the
morning
which
is
not
really
suitable,
for
it
only
works
for
the
us
and
australia.
But
I
think
what
we'll
do
is
we'll
have
it
like
pakistan,
india
time
just
to
mix
it
up,
and
then
we
can
get
some
other
folks
involved
more.
You
know
there's
some
good
talent
from
there
at
the
moment
as
well.
So
I,
I
think,
we'll
start
changing
the
meeting.
So
look
out
for
that.
A
We
have
a
large
system
like
we
could
talked
about
ortillius
like
orgo
cd
linker
day,
and
we
talk
about
so
many
things.
I
think
you
can
find
a
way
to
contribute
some
of
those
projects
in,
and
I
think
you've
definitely
tried
some
of
the
our
example
repository
there
and
I
think
the
utkarsh
is,
if
you
go
to
the
dot
io
and
one
of
the
our
contributor
is
oscar,
he
has
a
wonderful
guide.
How
you
can
raise
your
first
github
issue
on
the
hotelier
side
and
we
have
also
other
podcast
available.
B
B
What
talks
do
I
want
to
see
at
kubecon
yeah?
I
haven't
really
decided
yet
normally.
Normally
I
get
two
topics
that
I
want
to
focus
on,
because
I
remember
the
first
time
I
went
to
kubecon.
I
was
trying
to
learn
everything,
and
then
I
learned
nothing
so
for
the
the
two
talks
this
year,
I'll
probably
focus
in
on
service
mesh
and
probably
a
little
bit
more
yeah.
I
don't
know
yet.
I
haven't
quite
decided,
there's
so
much
stuff
to
focus
in
on
as
well,
but
yeah
I'll
definitely
be
going
this
year.
A
Yes,
absolutely
absolutely
looking
forward
to
it
hope
everything
went
well
and
we
will
definitely
finally
meet
at
the
cube.
Con
is
brother,
everybody
you're
listening
to
a
kubecon
is
happening
in
may,
50
may
16
to
20
at
cubecon,
valencia,
and
also
the
cfb
is
open
for
the
next
cubecon
and
it's,
I
think,
closing
then
closes
after
the
first
coupon
is
ended.
The
next
one
is
kubecon
and
nay.
Is
that
right?
A
If
you
want
to
chat
about
your
experience
of
managing
of
of
running
the
github's
infrastructure
or
github's,
enable
infrastructure
feel
free
to
hit
me
up
on
either
on
the
either
on
the
discord
side
in
the
hoteliers
community
or
either
on
the
github.
We
have
both
listening.
Our
twitter
handle
is
listening
on
the
screen,
so
we're
definitely
looking
forward
to
it
and
if
you
are
interested
in
contributing
the
hoteliers
projects,
the
link
is
available.
Skit
up
dot
com,
slash
hotel,
yes,
yes,
and
we
have
more.
A
We
want
to
have
more
contribute
of
the
more
different
places
in
the
world
who
can
share
their
knowledge
with
us,
and
we
want
to
learn
each
with
each
other
as
well.
So
thank
you.
Everyone
who
would
hang
out
for
this
session
hope
you
have
learned
a
lot
during
the
conversation
I
had
with
bad
brat
mccoy
and
thank
you
very
much
brad
for
spending
time
with
me.