►
Description
This event is hosted by https://www.meetup.com/cloud-computing-san-antonio/
Sean Whitesell, Microsoft MVP and Cloud Architect, will discuss how to leverage Microservices in when engaging in Cloud software development.
Sean Whitesell
Sean is a Microsoft MVP, cloud architect, and President of the Tulsa .NET User Group.
https://www.meetup.com/TulsaDevelopers-net/
https://twitch.tv/codewithsean
A
A
Hello
and
welcome
everybody.
Thank
you
for
coming
to
the
san
antonio
cloud
computing
group
meetup
for
may
10
2021,
I'd
like
to
welcome
everybody
from
the.net
virtual
group
as
well.
I'd
like
to
thank
the.net
foundation
for
hosting
this
event
and
I'd
like
to
appreciate
them
for
the
work
they
do
in
bringing
assistance,
help
and
education
to
developers.
A
A
We
got
one
event
before
we
hand
it
over
to
sean
and
that's
the
announcement
for
next
week.
We're
gonna
have
mark
brown,
the
principal
pro
product
manager
for
azure
cosmos
db,
he'll,
be
with
us
to
discuss,
modeling
and
partition
partitioning
in
cosmos
db,
and
it
should
be
a
great
introduction
to
developing
using
a
distributed
nosql
database.
I'm
going
to
put
that
link
in
the
chat
here
go
ahead
and
put
that
in
there.
A
A
I've
had
a
chance
to
code
along
with
sean
and
do
listen
to
some
talks
with
him
and,
and
you
got
everybody's
in
for
a
treat,
I
think,
he's
honestly
fantastic
I'll,
go
ahead
and
link
the
tulsa
user
group
in
the
chat,
and
I
will
link
code
with
sean
which
is
shawn's
twitch
channel
in
the
chat
as
well,
where
I
myself
am
a
subscriber
and
follower
and
he
does
lots
of
great
stuff
over
there
as
well.
So
without
any
further
ado,
I'm
handing
it
over
to
sean.
B
B
So
we're
going
to
talk
about
first,
getting
started
with
the
goals
of
talking
about
a
microservices
architecture
that
it
takes
a
lot
more
consideration
than
you
would
expect,
meaning
that
there
is
quite
a
bit
more
to
just
doing
microservices
than
the
than
the
hype
right.
Then
the
buzzword,
so
there's
just
quite
a
bit
more
to
it.
B
So
a
quick
agenda
is
we're
going
to
talk
about
what
microservices
are.
Why
should
you
use
them,
and
when,
should
you
not
use
them
as
well
as
a
lot
of
the
challenges
that
you
will
come
across
when
developing
microservices
we'll
also
do
a
quick
and
high
level
talk
about
a
decomposition
using
domain
driven
design,
but
it's
gonna
have
to
be
really
high
level.
We
have
to
skim
the
surface
a
little
bit,
because
that
topic
in
itself
is
so
deep.
B
So
normally,
when
I'm
in
front
of
an
audience
pre-covered,
I
would
ask
so
what
are
microservices
and
I'd
get
a
few
answers
from
the
audience,
and
that
was
kind
of
the
point
and
also
highlighting
the
problem
is
that
there
is
not
just
one
good
answer
as
to
what
microservices
are
now
at
least
at
the
time.
I
really
also
did
not
have
one
to
provide,
but
I'm
going
to
try
to
do
my
best
of
a
version
of
an
answer,
and
that
is
that
a
microservice
is
simply
a
tiny
monolith
with
a
tight
focus
on
a
domain.
B
It's
not
about
the
size
of
the
code,
it's
not
about
how
many
lines
of
code
or
things
like
that.
It's
about
the
focus,
meaning
that
a
microservice
is
meant
to
do
one
thing
and
do
that
one
thing:
well,
it's
kind
of
like
a
monolith
where
it's
going
to
have
its
code.
It'll
have
a
database
back
in
if
it
needs
to
persist
data.
B
They
need
all
the
love
and
attention
as
any
other
application
that
we
develop
and
instead
of
just
being
something
that
we
instantiate
in
memory,
microservices
communicate
over
a
network.
Now
that
might
be
direct
connection
using
rest
or
it
might
be
using
messaging.
But
the
idea
is
that
it's
not
simply
an
in-memory
call
and
microservices
have
a
single
responsibility,
they're
a
service,
and
they
need
to
provide
one
service.
Well.
What
is
that
one
thing?
B
It
does
well
simply
meaning
that
if
you
have
a
microservice
to
process
invoices,
it
should
not
also
be
handling
forms
for
human
resources.
Those
are
two
separate
domains
entirely,
so
have
a
microservice
that
is
sized
and
scaled
to
what
it
needs
for
that
business
domain.
That
focus-
and
you
may
even
see
later
that
if
you
have
a
microservice
that
is
just
doing
so
much
with
accounts
payable
versus
accounts
receivable,
let
alone
other
accounting
functions.
B
You
might
even
split
those
apart
into
their
own
microservices
and
you'll
see
those
pain
points
as
they
grow,
and
you
have
to
decide
when
it's
time
to
split
that
out
and
microservices
are
owned
by
one
team
of
developers.
You
should
never
have
a
microservice
that
is
owned
and
developed
and
maintained
by
more
than
one
team.
B
You'll
have
so
much
contention
on
the
way
to
do
the
development
deadlines,
the
whole
growth
of
that
microservice,
etc.
Now
a
migrant
aid
team
can
have
multiple
microservices,
but
as
long
as
they're
not
shared
across
multiple
teams
and
microservices
should
be
individually
deployable,
meaning
that
there
should
not
be
a
tight
coupling
between
one
microservice
to
another.
B
Now
they
might
communicate
with
each
other
because
of
business
features,
but
that's
more
of
a
loose
coupling.
If
you
require
every
change
to
of
of
a
microservice
to
also
have
the
other
microservice
to
go
right
along
with
it.
That's
getting
very
tightly
coupled
you've
got
to
be
staying
away
from
that
and,
moreover,
microservices
is
an
architecture
style.
B
That's
okay,
monoliths
are
not
bad
in
and
of
themselves
and
we're
going
to
we'll
talk
a
little
bit
more
about
this
later,
but
the
when
that
monolith
becomes
a
big
problem.
That's
when
you
might
decide
to
go
ahead
and
pull
a
a
collection
of
business
functionality
right.
So
maybe
that's
accounting,
and
maybe
we
extract
that
out
to
its
own
microservice.
B
Now
it
has
been
done,
it's
been
done
several
times,
but
not
without
its
pains
and
not
without
its
and
we'll
be
talking
a
lot
about
that
here
in
just
a
little
bit
and
another
big
reason
for
microservices
is
that
they
are
there
to
share
and
distribute
that
computational
needs
across
other
systems
across
other
servers,
and
the
picture
here
is
just
to
depict.
Maybe
I've
got
five
different
microservices
with
multiple
instances
of
them,
depending
on
the
needs
and
then
calling
each
other.
B
So
why
should
you
ever
use
a
microservice
coming
back
to
that
monolith?
What
if
that
monolith
has
grown
as
they
all
do
year
after
year?
There's
always
those
code
changes
that
occur
and
after
those
code
changes
have
occurred,
maybe
bug
fixes
whatever
patching
that
had
to
be
done.
You
end
up
in
what's
called
that
big
ball
of
mud
or
spaghetti
code
where
it
becomes
more
and
more
fragile
to
make
code
changes
now,
if
you're,
not
in
that
position,
you'll
probably
still
be
better
off
to
use
monoliths.
B
They
that
crunch
time,
where
the
you
know
the
bosses
are
coming
to
you
and
saying
that
we've
got
this
new
feature.
We've
got
to
get
this
integrated
and
you're
like
well,
it's
going
to
be
at
least
six
months
to
adapt
it
into
the
monolith
and
fix
the
fragility.
That's
already
there
then
you're,
not
ready
for
that.
You
need
to
consider
microservices.
B
B
Although
c
sharp
can
do,
data
analytics
python
is
just
better
suited
for
that.
So
it
allowed
the
team
to
use
the
best
programming
language
for
the
job
at
hand
as
well.
That
team
of
developers
was
able
to
focus
on
those
pieces
of
what
was
needed
to
be
developed
in
python,
with
a
little
bit
of
caring
as
what
the
communication
was
between
the
c-sharp
program
and
how
it
was
getting
data
to
and
controlling
the
actions
of
the
data
analytics
microservices.
B
B
And
microservices
provides
service
autonomy.
This
goes
back
to
that
single
responsibility
I
mentioned
earlier.
It
allows
that
microservice
to
be
focused
on
one
domain.
If
it's
to
process
a
paycheck
or
or
accounts
receivable
accounts
payable
things
like
that.
It
can
be
just
enough
size
to
focus
on
that
domain,
but
it
should
not
also
handle
many
other
domains
and
because
you're
going
to
end
up
with
a
lot
of
contention,
and
it
should
there's.
Hence
the
the
next
item
is
that
deployable
without
other
services.
B
So
if
we
have
too
much
going
on
and
we've
got
a
microservice
that
is
sharing
code
and
is
tightly
connected
to
another
microservice,
then
every
time
you
have
to
when
you
deploy
one,
you
have
to
require
the
other
service
to
be
deployed
as
well.
What,
if
that
other
service
is
managed
by
another
team
of
developers?
B
B
And
microservices
can
scale
independent
of
other
applications.
The
idea
here
is
that,
if,
depending
on
the
type
of
workload
that
it's
going
to
do,
maybe
I
need
more
instances
of
one
microservice
versus
another
microservice
as
well.
What
kind
of
servers
are
you
going
to
put
them
on?
Maybe
it's
kubernetes,
but
even
if
it
is
how
much
ram
do
you
devote
how
much
a
cpu
do
you
help
allocate
for
that,
and
are
you
going
to
put
this
in
azure
you're,
going
to
put
aws
etc
right?
B
The
idea
here
is
that
if
you
take
the
example
of
amazon
and
you
go
up
to
pull
up
an
item
on
amazon,
you
see
the
part-
the
pictures,
the
description,
you're
able
to
pick
out
the
item
that
you
want.
You
put
it
in
your
cart
and
you
purchase
it
fantastic,
that's
great!
What,
if
a
microservice?
That's
providing
the
the
reviews
is
unavailable
for
whatever
reason.
Maybe
there
was
a
bug
in
the
code
and
it
wasn't
there
in
that
business
flow.
B
They
started
out
with
giant
monoliths
grown
over
time.
Then
they
went
to
microservices,
but
not
without
their
pains.
They
had
a.
They
spent
a
lot
of
time
and
money
learning
a
a
massive
amount
about
the
issues
they
were
facing
and
several
times
they
would
put
something
out.
Try
something
have
to
pull
it
back
in
adjust
put
out
a
next
microservice
things
like
that,
so
they
their
development
time
was
a
lot
longer
than
they
usually
had
with
the
monoliths.
B
B
Doing
things
well
still
is
extremely
hard
to
do,
and
there's
a
lot
to
focus
on
so
other
reasons
that
you
should
not
do
microservices
if
the
monolith
that
is
you're
thinking
about
not
adapting
for
that
new
business
functionality,
if
the
code
base
is
just
too
small,
you
probably
don't
need
to
do
that.
It
might
actually
be
easier
to
have
multiple
monolith
instances
and
using
feature
flags
to
help
govern
the
activities
of
each
of
those
instances.
B
It's
a
perfectly
fine
way
of
getting
things
deployed
and
running
as
well
as
it
is
a
lot
quicker
to
handling
things
in
production
than
microservices
or
developing
and
getting
your
changes
into
microservices
as
well.
If
your
code
requires
to
it
has
too
much
coupling,
and
it
requires
a
lot
of
refactoring
you're
going
to
spend
a
lot
of
time,
refactoring
your
code
just
to
clean
things
up,
regardless
of
how
it
works
with
a
microservice
and
when
it's
time
to
split
a
microservice
from
a
monolith.
B
You
may
do
a
lot
of
refactoring
just
to
clean
up
and
clean
up
the
the
lines
and
bring
in
better
uses
of
dependency
injection,
for
example,
and
if
the
development
team
is
unwilling
or
not
ready.
Yet
you're
gonna
face
even
more
battles
at
the
team
level
itself,
because
one
of
the
things
you
will
need
to
do,
depending
on
the
size
of
your
teams,
is
to
actually
have
devoted
teams
for
the
different
microservices
and
they
need
to
be
willing
to
do
what
it
takes
to
to
build
and
support
microservices,
including
all
the
learning
such
as
this.
B
If
there's
a
bug
out
there,
they
need
to
have
a
support
system.
That
is
there
to
help
get
them
the
information
they
need
for
troubleshooting
to
get
the
bugs
fixed
and
get
that
next
version
out
and
you've
got
to
be
willing
to
handle
the
high
cost
of
time
and
money
needed
to
develop
and
learn
about
microservices.
B
So,
let's
go
through
some
challenges
as
well.
Regarding
this,
we've
got
several
examples
after
this
that
we're
going
to
touch
on
so
the
first
expectation,
if
you
will,
is
that
it's
going
to
be
rather
cheap
to
do
microservices.
In
fact,
it's
just
the
opposite,
like
I
mentioned
you're,
going
to
spend
a
lot
of
time
and
money
just
learning
how
to
do
things.
What
are
the
other
communication?
Styles
that
you
need?
B
B
Should
you
do
synchronous
or
asynchronous
type
messaging,
maybe
publish
publication,
subscription
type
messaging
model
and
try
to
not
think
about
copying
files
over
to
a
server
for
microservices.
Instead,
you
want
to
set
up
a
continuous
integration,
continuous
deployment
pipeline
per
microservice.
This
goes
back
to
that.
The
fact
that
in
microservices
are
independent
applications
and
because
they
are
independent
applications,
they
need
to
have
a
single
repository
to
house.
All
of
that
code
that
is
specific
to
that
application
and
for
longest
time
networking
is
not
really
a
job
of
a
developer.
B
That's
changing!
Because
microservices
communicate
over
a
network.
We
need
to
understand
different
networking
pieces,
for
example
the
osi
model,
specifically
layers
four
and
seven
we're
going
to
touch
base
on
that
in
just
a
moment
and
as
they
communicate.
We
need
to
worry
about
the
security
of
that
communication.
B
It
would
be
nice
to
have
all
of
the
communications
secured
by
using
something
like
tls,
so
that
the
network
cannot
be
sniffed
and
have
that
information
stolen,
and
you
may
think.
Well,
it's
a
private
network
and
we
don't
need
to
do
that.
But
at
the
same
time
you
you're
using
a
third-party
nuget
package
that
you
did
not
look
at
their
source
code.
B
How
do
you
know
that
a
third-party
code
base
is
not
sniffing
the
network
and
trying
to
send
information
back
out?
Take
the
steps
necessary
to
protect
that
information,
and
now
that
you
have
that
microservice
out
there
and
you're
protecting
it,
because,
after
all
processing
your
paycheck
as
well,
it
would
be
nice
to
control.
Who
is
able
to
call
that
microservice
so
using
something
like
oauth,
some
other
permission
model
to
help
govern.
B
Who
can
call
that
microservice
and
we've
all
grown
up
with
the
do
not
repeat
yourself
right
the
if
you're
copying
your
code
and
you
see
duplicate
functionality
written
over
and
over.
You
want
to
kind
of
streamline
that
a
little
bit
well
now
having
common
code
at
the
microservices
architecture
can
actually
cause
your
microservices
to
be
tightly
coupled
and
we'll.
Have.
I
have
a
scenario
on
that.
So
we'll
talk
through
that.
B
So
touching
on
networking
for
just
a
moment,
the
osi
model
that
open
systems
interconnection
model
is
the
main
one
used
regarding
networking
physical
being
excuse
me
like
coax
fiber,
the
copper
and
when
we
plug
our
routers
into
maybe
a
cable,
modem,
etc.
It's
that
physical
layer
of
how
bits
are
getting
from
one
device
to
another
as
they
go
up
the
line.
B
B
B
But
it's
the
data.
That's
on
layer,
4
that
is
actually
getting
in
there
and
getting
processed
load
balancers
will
be
used.
For
example,
the
azure
load.
Balancers
are
layer,
4
type
still
help
spread
that
load,
so
that
will
you
don't
have
one
instance
of
a
microservice
getting
all
of
the
load
but
to
help
spread
that
across
and
then
you
can
decide
well
of
all
the
instances
of
the
microservices
that
I
have
even
with
spreading.
They
are
still
getting
overloaded.
B
So
layer,
seven,
why
do
we
need
to
care
about
that?
One
example
of
this
is
looking
at
the
nvc
pattern.
The
model
view
controller
pattern.
The
one
letter
that
they
leave
off
is
r
for
routing
because,
as
the
request
comes
in
and
it's
coming
to
an
http
endpoint,
it
gets
routed
to
the
mvc
controller
that
controller
that
receives
that
data.
B
B
B
So
how
do
we
handle
this?
Well?
The
idea
here
is
that
the
common
code,
that
is,
allowing
one
team
to
make
changes
and
can
hurt
another
one,
but
yet
we're
trying
to
stick
to
this
drive
principle.
This
is
where
that
breaks
down
here.
It
is
okay
to
copy
code
and
split
them
out
to
the
microservices
that
need
them
independently.
B
So,
just
to
recap
on
this
pull
out
the
code
that
needs
to
change
and
evolve
independent
of
another
microservice,
and
if
you
still
have
common
code
that
just
hasn't
been
touched.
Yet
that's
fine!
You
probably
will
at
some
point
in
time,
but
it
is
okay
to
duplicate
code
to
the
service
that
needs
it,
because
it's
not
going
to
be
identical
for
very
long.
B
Okay,
so
you
decide
to
go
ahead
and
do
this
and
you've
pulled
out
some
functionality
out
of
a
monolith
and
bring
it
into
a
microservice,
and
then
you
realize
well,
it
has
a
dependency
on
other
code.
So
you
pull
it
over
too.
Then
you
have
this
other
stuff
that
you
find
that
it's
also
tied
and
it
has
to
be
pulled
over
you
just
go
on
and
on
about
you
realize
you,
you
actually
don't
have
a
microservice.
B
Now,
this
is
definitely
something
to
avoid
and
where
you
might
be,
okay
with
this
and
I'll
explain
that
just
a
second,
but
you
might
also
look
at
this
and
go
wait.
This
is
we're
heading
in
the
wrong
direction.
Maybe
we
need
to
back
out
not
do
this
or
maybe
even
adapt
and
use
feature
flags
like
I
mentioned
earlier,
use
a
feature
flags
in
the
monolith
so
that
the
instances
of
that
code
base
is
processing
different
things
for
different
reasons.
B
If,
however,
you
are
something
like
the
ebay
and
netflix
and
amazon
did
where
they
pulled
their
monolith
apart
now,
they've
got
two
monoliths
and
that's
a
problem.
If
that's
your
end
of
state,
if
this
is
simply
a
hop
on
that
development
road,
so
to
speak,
where
you're
here
for
now
and
then
you're
going
to
break
this
up
even
further
do
more
refactoring
and
they
themselves
turn
into
other
microservices.
B
Then
this
is
fine.
It's
you
should
avoid
it.
If
this
is
your
end
of
state
okay,
so
one
of
the
things
that
tripped
me
up
about
microservices
when
I
learned
about
decentralizing
data-
and
I
did
not
like
this-
having
grown
up
with
a
sql
server
for
all
of
my
development
career
as
well
as
other
databases,
but
primarily
sql
server,
it's
a
centralized
data
store.
I
I
why
break
it
up?
Just
have
your
other
microservices
call
it
as
need
be.
B
When
it
finally
clicked
for
me
as
to
why
that's
actually
a
problem,
this
is
when
I
come
up
with
a
slide
in
the
scenario.
So
hopefully
this
helps
sell
and
share
the
the
why
you
want
to
be
very
careful
of
this
and
go
ahead
and
decentralize
your
data,
and
I
don't
know
who,
but
somebody
said
that
there's
this
rule
that
says
that
microservice
should
have
its
own
data
store.
Well,
I'm
going
to
tweak
that
just
slightly
and
say
that
a
microservice
that
persists
any
data
should
have
its
own
data
source.
B
B
So,
let's
start
with
the
scenario
where
I've
got
a
centralized
system
and
it
has
a
table
for
accounts,
customers,
orders
order,
history,
parts,
parts,
one,
shipping,
history
and
logging
and,
oh
sorry,
oh
yeah,
part
parts,
one
yeah!
Well,
okay,
so
here's
the
deal
right
so
over
time
the
monolith
changes.
The
parts
table
also
changes
the
schema
of
that
table
changes,
and
now
we
got
to
a
port
at
some
point
in
some
change
that
it
just
didn't
make
sense
that
we
were
going
to
break
things.
B
So
what
we
did
instead
is
we
made
another
table
for
parts
to
handle
the
differences
and
well
naming
is
hard.
Surely
I'm
not
the
only
one?
That's
ever
done
that.
So
now
we
have
parts
one
table,
that's
bringing
up
the
point
that
schema
changes
on
the
tables
they
have
to
change,
because
the
business
logic
is
changing
for
the
business
needs.
B
B
And
how
does
transaction
work
across
multiple
tables
we're
going
to
get
to
that?
You
you're
just
a
couple
of
slides
ahead
of
me,
we're
going
to
get
to
that.
I
appreciate
these
are
great
questions,
so
here
we're
saying
that
a
microservice
has
everything
to
do
with
shipping
and
orders
and
parts,
but
they
need
information
from
other
microservices
find
okay,
so
a
micro
service
can
make
it
do
a
network
call
it'll,
just
call
the
other
microservice
and
say
hey.
I
need
this
information.
B
B
B
B
Let's,
let's
go
through
this
for
just
a
second,
so
the
parts
data
data
store
here
has
everything
to
do
with
parts.
It
has
all
this
information
about
from
the
ied
to
the
color,
the
container,
the
manufacturer.
What
part
number
it
replaces
when
was
it
discontinued,
etc
right?
This
is
all
that
schema
levels,
level
stuff
about
a
part.
B
B
B
So
the
idea
is
that
I
have
a
little
bit
of
the
data
that
is
copied
between
the
data
stores,
but
only
enough
to
fulfill
those
business
requirements
and
now
somebody's
about
ready
to
type
this
up
and
send
this
in.
So
hopefully
I
can
jump
ahead
of
this
well
now
that
I've
got
cop
data
duplicated
across
my
multiple
systems.
How
do
I
keep
them
in
sync
and
how
do
we
handle
transactions?
B
B
So
let's
go
through
a
scenario:
we
have
a
monolith,
that's
hosting
a
website.
The
administrator
goes
in
and
adds
a
brand
new
part
to
the
system.
She
fills
out.
The
information
on
the
form
hits
enter
right,
submits
that
change
and
a
message,
then,
is
sent
directly
to
the
parts
microservice,
and
it
adds
that
information
to
that
single
source
of
truth,
datastore
and
then
let's
say
that
somebody
notices
well,
there's
a
I'll.
B
B
Oh
by
the
way
there
was
a
typo
in
in
the
part
name,
it's
actually
there's
a
small
typo
in
that
okay,
so
the
administrator
logs
into
the
system
finds
that
part
fixes
the
typo
notice
that
the
activity
is
different.
This
is
not
a
new
part
message.
This
is
an
update,
part
information
message,
so
that
type
of
message
is
then
sent
out
and
both
the
parts
micro
service
picks
up.
That
message
reacts
to
it.
Finds
that
part
item
in
the
data
store
and
updates
then
fixes
the
typo,
but
also
the
order.
B
B
B
B
So
now
what
tends
to
happen
from
time
to
time
is
because
I'll
I'll
forget
to
put
some
money
in
there's
I'll
go
buy
an
item.
Let's
let's
say
I
bought
a
150
dollar
item
whatever
now
I'm
down
to
50
bucks
in
balance
and
then
I
go
and
buy
something
for
75
dollars
all
right.
So,
let's
think
of
that
scenario,
so
I
go
to
this
website
on
the
hosted
by
the
monolith,
and
I
find
what
I
want.
My
cart
is
full
and
it's
75
and
let's
think
about
what
amazon
does
in
this
case.
B
So
an
order
is
created.
I
get
an
order
number
I
get
an
email
saying,
thank
you
for
the
order
right
and
information
in
this
saga.
Type
message
is
also
sent
to
the
payment
microservice
and
it
says:
wait
a
minute.
The
payment
failed
insufficient
funds.
Oh
okay,
what
happens
then?
Is
I
get
an
email,
a
few
minutes
later
notice
that
the
order
was
created
but
because
the
payment
failed,
the
saga
information
changes,
the
order,
microservice
picks
up
on
that
says.
B
Okay,
then
we're
going
to
change
the
status
of
this
order,
notice
that
we're
not
going
to
delete
data
we're
going
to
change
the
status
on
this
order,
we're
going
to
change
it
to
maybe
payment
pending
or
get
some
flag
right.
That
says
this
is
why
we
cannot
fulfill
the
order
and
also
an
email
is
sent
to
me
saying
by
the
way
the
payment
failed,
not
enough,
not
enough
funds.
B
Okay,
sure
enough,
I
go.
I
go
move
some
money
over
there
go
back
to
the
website.
Let's
say
reprocess
that
again,
for
me,
saga
is
updated.
Payment
microservice
reacts
sends
the
payment
information
out
processes
says
it's
all
good,
fantastic
updates.
The
saga
for
this
order,
shipping
can
now
react
to
that
pick
the
item
and
get
it
sent
out
so
different
message
type
depending
on
the
needs
of
what
I
need,
this
system,
the
architecture
to
communicate
with.
B
So
back
briefly
touching
on
transactions,
you
can
use
sagas
to
help
across
multiple
tables.
Now,
I'm
saying
just
because
this
is
a
very
quick
demo
is
that
a
micro
service
has
a
data
store.
There
are
some
people
a
lot
smarter
than
me
that
will
suggest
you
can
still
have
that
centralized
data
system
that
data
store,
but
you
will
find
schema
contentions
at
some
point
with
your
microservices
sharing
and
pulling
information
out
of
that
one
data
store
at
some
point.
You
want
to
break
that
up.
B
B
If
you're
familiar
with
dbo
and
sql
server,
you
can
create
other
schemas
meanings
that
you
can
change
the
permissions
at
the
schema
level
or
even
at
tables
at
the
table
level,
so
that
this
system
cannot
talk
to
that
table
or
stored
procedures
or
functions,
except
for
this
other
microservice.
That
is
logging
into
that
system
by
a
different
account
and
has
different
permissions.
B
That's
going
to
be
between
you
and
your
dbas
to
work
out
and
database.
Dbas
are
not
fans
of
more
work.
To
do
so,
they're
not
likely
to
go
and
add
more
databases,
but
at
the
same
time,
think
of
it.
This
way.
What?
If
that
monolith
database
has
tons
and
tons
of
data
in
it,
but
the
shipping
database,
you
may
have
a
fraction
of
what
size
of
another
one
again
goes
back
to
the
what
your
business
needs
are.
I'm
pointing
out
that
you
have
different
type
of
communication
options.
B
You
can
do
rpc
the
direct
make
an
http
rest
based
call
to
an
endpoint
through
a
load
balancer.
You
do
that
and
or
depending
on
your
needs,
use
messaging,
something
like
mass
transit
sitting
on
top
of
rabbit
mq,
for
example,
okay,
we're
going
to
switch
gears
and
let's
talk
about
decomposing,
a
monolith
to
microservices.
B
B
This
is
going
to
be
really
quick
because
again,
this
is
one
of
those
things
where
there's
so
much
to
this.
When
we
talk
a
little
bit
about
domain
driven
design,
we
could
do
a
workshop
we'd,
be
here
all
week,
there's
just
so
much
great
stuff
to
handle
through
that.
So
it's
gonna
be
really
hard
to
do
in
just
this
one
session,
so
that
would
be
high
level.
B
So
the
idea
is
that
when
decomposing
a
monolith
to
a
microservice
you're
going
to
extract
functionality
out
of
a
monolith
and
bring
it
into
its
own
microservice,
now
I
don't
know
about
you,
but
I
have
never
worked
on
a
monolith
with
code,
so
cleanly
separated
from
everything
else.
It's
been
usually
things
like
this
blurred
lines
lacking
good
dependency
injection.
You
can't
just
replace
classes
as
needed
very
easily,
so
you're
gonna
have
to
clear
those
boundaries
you're
going
to
have
to
spend
time.
B
Refactoring
need
to
find
good
ways,
good
places
to
use
dependency
injection
so
to
help
make
objects,
interchangeable
and
become
loosely
coupled
instead
of
tightly
coupled
all
right.
So
I'm
going
to
cover
a
question
that
I
get
all
the
time.
How
should
I
get
started
all
right
start
small?
What
does
that
mean?
Start
small
find
a
smallest
piece
of
code
that
you
can
pull
out.
It
may
not
even
be
the
code
base
that
you
really
want
to
move
over
for
your
first
production
microservice.
B
B
A
Got
a
quick
question
for
you:
sean
yes,
go
ahead,
would
you
be
able
to
have
a
cloud
provider?
You
know
maybe
like
azure
or
something
help
you
with
some
of
that
is
there?
I
imagine
you
know
that
there's
money
to
be
made
there,
so
I'd.
Imagine
that
a
cloud
provider
would
be
able
to
help
with
some
of
the
infrastructure
you
just
mentioned.
B
Of
what
it's
really
doing,
then
you
might
be
able
to
consider
that
a
microservice,
it's
communicatable
over
a
a
network
technically
and
you
can
control
the
permissions
with
that
in
azure.
You
do
azure
functions,
certainly
as
well.
You
know
with
sql
server,
azure,
sql,
cosmos,
db,
etc.
So
absolutely
and
then,
if
you
need
to
spin
up
virtual
machines.
B
For
example,
I
have
the
access
to
create
virtual
machines.
I
do
not
have
access
to
access
them.
That's
somebody
else's
job,
but
it's
also
because
of
data
protection,
so
as
well
as
the
governing
the
network
who
has
access
to
beyond
that
network,
etc.
So
absolutely
cloud
absolutely
easily
be
able
to
do
it.
B
So
hopefully
that
answered
the
question,
but
that
was
also
one
of
the
reasons
why
I
mentioned
azure
load
balancer
earlier
super
easy
to
spin
up
an
azure
load
balancer
and
they
work
on
a
layer
4..
If
you're
in
aws
you've
got
the
elastic
load
balancer
in
application
load,
balancer
a
network
load
balancer
is
tcp
versus
an
application
load
balancer.
That
is
http
only
so
you
want
to
look
at
what
are
what
are
you?
What
are
your
restrictions
for?
What
you
need,
given?
B
How
you
expect
these
to
communicate,
and
just
because
you
have
a
microservice
sitting
on
an
instance
anywhere
does
not
mean
it
has
to
be
port.
80
does
not
mean
it
has
to
be
that
at
all.
So
it
definitely
opens
things
up.
I
I
would
also
highly
suggest
looking
at
for
internal
communications,
maybe
microservices
microservice,
using
grpc,
depending
on
your
latency
and
and
what
problems
you
may
be
trying
to
fix
with
that
look
into
grpc
help
speed
up
some
of
that
communication.
B
B
So
there's
also
that
learning
curve
there
and
being
good
stewards
as
we
are.
We
need
to
make
sure
that
we're
not
the
only
ones
that
know
how
to
do
things,
so
you
also
have
to
have
a
team
that
is
knowledgeable
of
kubernetes
and
be
able
to
understand
the
differences
between
the
the
load
balancer
options
that
you
have,
the
pros,
the
cons,
etc.
B
You
know,
should
you
use
helm,
for
example,
using
lambdas
or
are
actually
a
lot
easier?
There's!
No
there's!
No
virtual
machines
that
you
have
to
to
worry
about
there.
You
don't
have
to
node
count,
so
it
just
depends
so
on
on
what
you
need.
If
you
need
a
heavier
code
base,
that's
more
than
a
single
entry
point
that
lambda
provides.
B
You
might
look
at
something
like
kubernetes,
so
there's
several
options
out
there,
and
I
can
tell
you
one
of
the
things
that
I've
done
is.
I
went
down
a
list
of
items
and
spun
up
different
ways,
try
to
solve
a
problem
in
different
ways
and
see
which
one
was
really
going
to
benefit
us,
the
most,
which
one
was
easiest
for
us
to
to
work
on,
build
up
and
maintain.
B
B
It's
just
the
way
that
I'm
kind
of
working
with
in
this
example,
but
there's
several
other
ways
out
there
so,
like
I
said
with
william
bam,
they're
they're,
a
production
company
and
their
main
domain
is
that
production.
Now
they
have
secondary
domains
for
purchasing
and
shipping,
because
they
also
need
to
be
able
to
purchase
raw
material
and
give
that
to
the
production
area
for
them
to
assemble
the
various
parts
together
to
come
up
with
a
final
product
to
give
to
shipping
to
get
it
out
the
door
and
then
there's
also
the
other
domains.
B
The
third,
the
the
generic
domains,
for
maybe
third-party
integration
inventory,
account
handling
invoicing
returns.
The
generic
domains
are
more
for
something
like
you
would
replace
with
a
off-the-shelf
application.
If
you
can
meaning
that
this
is
a
production
company,
it's
not
a
it's,
not
a
hospital.
It's
not
a
care,
it's
not
a
insurance
type
processing
type
of
system,
so
that
main
domain
is
really
dependent
on
the
purpose
of
that
application.
B
Now,
to
help
better
understand
where
your
domains
are
something
that
I
highly
suggest
is
looking
at
a
thing
called
event
storming
now.
This
is
different
than
event
sourcing
entirely
different
but
event,
storming
is
a
workshop
based
activity
developed
by
arbelto
brandolini,
and
you
can
go
to
eventstorming.com
to
get
a
lot
more
information
on
this.
B
But
the
idea,
through
this
workshop
so
imagine
that
you're
in
a
hallway
and
you've
got
large
piece
of
paper
very
long
piece
of
paper
going
across
the
wall,
and
you
have
a
lot
of
sticky
notes,
but
there's
very
they're,
color
coordinated,
so
you've
got
five
or
six
different
colors
for
for
the
different
pieces
of
event,
storming
activities,
so
you
may
have
you're.
Gonna
have
a
color
for
your
domain
events.
B
This
is
a
workshop
for
us
developers
to
get
with
the
subject
matter:
experts,
the
or
the
domain
experts,
so
that
we
can
start
putting
things
on
the
wall
and
highlight
things
using
the
the
sticky
notes
as
to
how
is
an
invoice
processed
or
how
is
an
insurance
claim
handled,
and
in
our
case,
how
is
purchasing
done?
How
does
that
purchase
product?
A
part
b
go
into
production?
How
is
that
assembled?
B
So
you
go
through
that
workshop
and
you're
able
to
see
that
on
the
board
with
all
this
activity-
and
you
see
the
like
the
like
functionality,
the
things
that
are
very
common
to
each
other,
and
you
can
see
the
different
areas
now
I
say
areas.
So
if
we
look
at
different
functionality
as
to
what's
going
on
in
the
system,
we
can
see
that
well,
we
we've
got
code
that
handles
handles
vendors.
B
So
what
you
notice,
then,
is
you
can
draw
these
circles
around
the
common
areas
and
go
okay.
These
are
our
bounded
contexts
over
here
is
purchasing
bounded
context
because
it's
vendors
and
the
raw
material
that
they
are
buying,
that
the
purchasing
department
is
buying
versus
the
functionality
over
here
for
taking
that
part
turning
it
into
pre,
taking
it
to
other
assembled
parts,
putting
them
together
to
become
a
final
product
and
fulfilling
that
order.
B
B
One
of
the
things
you
notice
is
that
we
have
parts
and
parts
but
they're
not
exactly
the
same
thing.
They're,
it's
not
the
same
code
and
it's
just
happens
to
be
the
same
name
applied
in
two
different
areas
in
domain
driven
design,
one
of
the
main
tenets
of
domain-driven
design
is
a
thing
called
ubiquitous
language.
B
B
B
So
now
inside
the
production
bounded
context,
I
have
things
called
aggregates
now
we're
talking
about
class
names
and
one
of
the
things
that
I
see
is.
I
have
a
class
for
order
and
an
order
is
created
of
multiple
order
lines
and
there's
functionality
there,
but
as
well.
A
product
has
assembly
parts,
so
there's
a
class
for
handling
the
functionality
of
handling
and
maintaining
the
data
for
a
product
as
well
as
the
functionality
in
the
assembly
parts.
B
So
we
have
an
order,
aggregate
and
a
product
aggregate.
We
can
go
one
more
step
further
and
we
point
out
that
the
order,
which
is
the
top
level
class
and
the
product
being
a
top
level
class.
Those
are
the
aggregate
roots
with
domain
driven
design.
The
rule
is
that
any
code
in
an
aggregate
can
call
another
aggregate
as
long
as
it
calls
functionality
at
the
aggregate
root.
B
B
If
I've
got
code
in
order
line
that
executes
code
over
in
the
assembly
parts
class
and
it
changes
data,
you
risk
the
data
integrity,
then
the
product
and
the
other.
You
know
the
that
instance
of
that
class
may
not
be
aware
of
what's
going
on
by
exposing
that
functionality
at
the
root
it
can
help,
keep
things
and
keep
that
data
integrity
all
the
way
down.
Obviously,
in
my
example,
it's
a
very
simple.
It's
overly
simplistic.
I
got
one
class
of
order.
One
class
of
order
line-
there's
always
a
lot
more
to
it.
B
So
now
that
I've
got
functionality
exposed
at
the
aggregate
roots
for
order
and
product,
maybe
we're
at
this
white
board
in
the
virtual
whiteboard
and
we
decide
you
know
what
we
could
because
of
so
much
common
functionality
going
here.
We
could
go
ahead
and
put
that
into
a
microservice,
and
that
microservice
is
then
exposing
the
functionality
of
the
aggregate
roots.
B
So
the
idea
here
is
this
is
again
it's
a
very
high
level
and
a
contrived
example,
but
you
can
have
a
microservice
that
is
now
with
that
bounded
context
as
well.
A
microservice
can
have
more
than
one
bounded
context
in
it,
depending
what
your
business
needs
are.
As
long
as
the
focus
is
tightly
controlled,
so
be
careful
about
adding
additional
bounded
context,
unless
it's
absolutely
needed.
B
B
B
B
They're
gonna
take
time.
They
do
provide
that
team
autonomy
allows
that
team
to
choose
the
right
programming
language
for
the
job,
to
help
better
support
that
microservice
and
microservices
can
be
autonomous
from
each
other.
So
the
human
resources
type
microservice
can
be
deployed
independently
and
evolve
independently
of
another
microservice.
B
It
also
provides
scalability
allows
you
to
choose
different
types
of
servers,
different
size
servers
depending
on
your
needs.
It
also
helps
helps
to
provide
that
fault
isolation.
So
if
you
do
have
a
microservice
that
is
failing,
other
business
processes
can
still
continue,
but
they
are
very
costly
in
time
and
money,
while
you're
learning
and
investing
on
how
to
get
this
developed
and
how
to
get
that
code
moved
over
and
to
grow
from
there.
You
do
need
to
decide
because
it's
over
a
network.
What
is
your
communication
like?
Are
you
going
to
use
messaging?
B
B
So
we
also
touched
on
domain
driven
design
again,
not
the
only
way
to
do
it,
but
a
good
way
to
do.
It
lends
itself
really
well
for
this
in
the
development
of
microservices,
because
when
I
say
a
tight
domain,
it's
referring
to
domain-driven
design
and
helps
to
understand
what
what
your
domain
is
and
as
you
go
through
that
and
you're
realizing,
there's
so
much
more
functionality
here
than
we
were
planning.
B
They
have
a
lot
more
examples
that
really
help
solidify
some
things.
For
me
all
right
last
little
bit
about
me,
my
name
is
sean
weissel,
president
of
the
dot
net
user
group
in
tulsa,
and
I
am
a
microsoft
mvp,
I'm
also
a
cloud
architect
and
on
occasion
I
am
on
twitch,
not
as
often
as
I
would
like
to
be.
A
A
So
I
always
always
love
to
see
that
when
I'm
working
with
people
so
I'll
I'll
just
make
a
quick
announcement
here,
I'll
we'll
be
having
kind
of
an
after
hangout
I'll
I'll
post
a
link
here
in
the
chat
as
the
music
plays
us
out
and
everything
and
then
also
post
it
on
the
meetup
event.
Page
that
way
we
can
anybody
from
the
san
antonio
group
or
the.net
virtual
group.
We
can.
We
can
hang
out
and
meet
each
other
for
a
little
bit
kind
of
in
a
unformal
capacity.