►
From YouTube: Why API Contracts Are Important (The Podlets, Ep 3)
Description
The focus today is on the importance of contracts and how API's help us and fit into the cloud native space.
For the show notes and transcript: https://thepodlets.io/episodes/003-why-api-contracts-are-important/
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Hosts
https://twitter.com/carlisia
https://twitter.com/joshrosso
https://twitter.com/mauilion
https://twitter.com/pbarkerco
B
C
A
It's
it's
critical
to
build
API
centric
when
you
don't
build
API,
centric,
most
commonly
you'll,
see
across
the
ecosystem,
people
building
UI
centric.
It's
very
tempting
to
do
this
sort
of
thing,
because
you
eyes
are
visually
enticing
and
they're
kind
of
eye
candy.
But
when
you
don't
build,
API
is
a
jerk
and
you
go
that
direction.
You
kind
of
miss
the
majority
of
use
cases
down
the
line
which
are
often
around
an
SDK.
A
Who's
ended
up
being
more
often
than
not
the
flows
that
are
the
most
useful
to
people
but
kind
of
hardest
to
see
at
the
beginning,
so
I
think
going
and
saying
you
know
we're
building
a
product.
Api
first
is
really
saying
you
know.
We
understand
that
this
is
going
to
happen
in
the
future
and
we're
making
this
a
principle
early.
We're
going
to
enforce
these
patterns
early
so
that
we
develop
a
complete
product
that
can
be
used
in
MIDI,
fashions.
B
Definitely
I've
seen
some
of
that
in
the
past,
as
well.
Working
for
a
company
called
Neisseria,
which
is
a
network
virtualization
company.
We
were
really
focused
on
providing
a
an
API
that
would
be
between
you
and
your
network
infrastructure
and
I.
Remember
that
being
really
critical
that
we
define
effectively
what
would
be
in
the
entire
public
API
for
that
product
out
in
front
and
then
later
on,
we
figured
out.
You
know
what
obviously,
to
learn
the
semantics
of
this
or
to
be
able
to
like
build
a
mental
model
around
what
that
API
might
be.
C
Yeah
I
think
so
I'll
jump
back
here
now
I
had
to
warm
up
my
brain
I
think
about.
Why
do
we
build
api's
to
begin
with
before
I
was
think
we
could
think
why
API
first
is
is
of
any
benefit
and
what
the
benefits
are
and
I
actually
looked
up
something
today
and
it's
this
Jeff
Bezos
mandate
I
had
seen
this
before
right
and
so
I
mean.
Why
do
we
build
api's?
Mainly
we
want
to
automate
API.
What
were
you
talking
about?
Is
data
transfer
right?
C
Is
it
get
taking
data
from
over
here
and
sending
it
over
there
or
you're
making
that
available
for
such
a
sabbatical
fat
chance?
And
so
it's
communication,
and
why
don't
we
be
the
API
to
make
it
easier
to
do
that,
so
you
can
automate,
you
can
expose
it.
You
can
add
some
security,
you,
you
can
get
it
with
some
security
rights
authentication
all
of
those
things
and
with
the
increasing
ever-increasing
amount
of
data,
this
becomes
more
and
more
relevant
and
I.
C
Take
when
like
Patrick
was
saying
when
you
do
it,
if
you
have
firsts,
you
absolutely
focus
in
on
I'll,
make
it
all
of
those
characteristics
and
priority
making
that
work
well
and
then,
if
you
want
to
make
it
pretty
ok,
you
can
take
that
data
in
turning
transforming
some
other
way.
To
make
your
presentation
pretty
you
to
display
on
the
mobile
device
or
whatever.
D
Yeah
I
think
another
thing
with
kind
of
inserting
the
API
design
up
front
and
the
software
development
lifecycle,
at
least
in
my
experience,
has
been.
It
allows
you
to
sort
of
gather
feedback
from
who
your
consumers
will
be
early
on
before
you
worry
about
the
intricacies
of
all
the
implementation
details
right
so
kind
of
like
I
guess,
with
nice
eras,
instant,
stuff,
yeah
I
wondered
when
you
all
made
that
contract
were
you
kind
of
pushing
out
a
swagger,
UI
or
just
general?
D
B
Say
it
was
an
API
first,
it
was
absolutely
there
was
something
we
didn't
build
out,
the
UI
and
until
after
the
fact,
so
even
to
the
point
where
we
would
define
a
new
object
in
that
API
is
like
distributed
logical
router,
for
example.
Before
we
could,
we
would
actually
define
that
API
first
and
we
would
have
test
plans
for
it
and
all
that
stuff,
and
then
we
would
surface
it
in
the
UI
part
of
it.
And
that's
a
great
point
like
is.
It
is
certainly
easier.
I,
don't
know,
I,
wouldn't
say
easier.
B
I
will
say
that
it
is
probably
to
your
benefit
in
the
long
run,
to
define
what
all
of
the
things
that
you're
going
to
be
concerned
with
are
out
front,
and
if
you
do
that
in
in
a
contractual
basis,
whether
that
contract
is
represented
by
an
API
or
whether
that
contact
is
represented
by
a
data
model.
It's
it's
critical
that
you
have.
You
have
some
way
of
actually
defining
exactly
what
that
is,
so
that
you
can
also
support
things
like
you
know,
versioning
and
being
able
to
actually
modify
that
contract.
A
Another
important
piece
here
too,
is
when
you,
when
you
just
look
at
the
data
model
and
the
concepts
you
focus
on
those
first,
you
have
a
tendency
to
more
decompose
the
problem
right.
You
start
to
look
at
things
and
you
break
it
down
better
into
individual
pieces
that
combine
better
and
you
end
up
with
more
use
cases,
and
you
end
up
with
a
more
usable
idea.
B
That's
a
good
point:
okay,
I
think
one
of
the
one
of
the
key
parts
of
this
contract.
This
contract
conversation
is
kind
of
like
what
you're
what
you're
trying
to
solve.
It's
always
important.
You
know
and
I
think
that
when,
when
I
talk
about
API
first
development,
it
is
totally
kind
of
in
line
with
that.
You
know
we
have.
You
have
to
kind
of
think
about
what
all
the
use
cases
are
and
if
you're
trying
to
develop
a
contract
that
might
satisfy
multiple
use
cases,
then
you
get
this
great
benefit
of
thinking
of
it.
B
C
B
Think
we
probably
all
seen
you
guys
that
get
stuck
in
exactly
that
pattern
to
Patrick's
point,
like
I
mean
they
try
to
solve
the
user
story
for
the
UI
and
then
on
the
on
the
back
end.
You're
like.
Why
do
we
have
two
different
data
models,
for
the
same
object
doesn't
make
sense
like
we've.
Definitely
seen
that
before
yeah
I've.
A
Seen
it
more
times
than
not
I
figured,
it
takes
a
lot
of
discipline
to
really
like
build
a
UI
or
an
API.
You
know
first
and
to
focus
on
those
pieces.
First,
it's
it's
so
tempting
to
go
right
to
the
UI,
because
you
get
the
immediate
results
and
everyone's
like
oh
yeah,
and
you
really
kind
of
need
it
to
bring
that
back
and
it
just
just.
It
takes
discipline
to
focus
on
the
concepts
first,
but
it's
it's
just
so
important
to
do.
I
guess.
C
It
depends
on
what
you
are
doing
to
I
can
see
all
kinds
of
benefits
for
any
kind
of
approach,
but
I
guess
one
thing
to
highlight
is
that
you
different
ways
of
doing
it.
You
can
do
a
UI
first
presentation.
First,
you
can
do
it
API
first
and
you
can
do
a
model
first,
which
is
so.
Those
are
three
different
ways
to
approach
the
design
and
then
you
have
to
think
well
saying:
is
you
shouldn't
do
one
just
because
you
don't
know
how
to
do
the
other?
B
D
Yes,
so
with
a
lot
of
this
talk
about
api's
and
contracts,
obviously
in
software
there's
kind
of
many
levels
of
contracts,
we
potentially
work
on
right,
there's
the
higher
level
potential
UI
stuff
and
sometimes
there's
a
lower
level
pieces
with
code.
So
perhaps,
if
you
all
think
it's
a
good
idea,
we
could
start
with
talking
about
what
we
consider
to
be
an
API
in
the
cloud
native
space
and
and
what
we're
referring
to
so.
B
D
B
Yeah,
that's
actually
means
that
that
is
an
interesting
point
to
bring
up
so
I'm
I'm,
definitely
describing
kind
of
the
consumption
model
of
a
particular
service
I'm.
Referring
to
that
contract,
as
you
know,
as
a
you
know,
as
an
infrastructure
guy
I
want
to
be
able
to
work,
I
want
to
be
able
to
consume
an
API
that
will
allow
me
to
model
or
create
infrastructure
and
so
I'm
thinking
of
it.
B
From
that
perspective,
I'm
very
much
I
mean
if
AWS
didn't
have
an
API,
I,
probably
wouldn't
be
I,
probably
wouldn't
have
adopted
it
like
the
UI.
Is
that
there's
not
enough
to
do
this
job?
You
know
I
mean
like
I
need
something
that
I
can
tie
to
better
abstractions
and
like
terraform
and
stuff
like
that,
so
I'm
definitely
kind
of
picturing
it
from
that
perspective.
B
But
I
will
add
one
other
interesting
point
to
this,
which
is
that
you
know
in
some
cases
to
Josh's
point
like
these
things
are
broken
up
into
public
and
private
api's
and
that
by
that
might
be
kind
of
interesting
to
dig
into
like
why
why
you
would
model
it
that
way,
because
I
mean
there
are
different.
There
are
certainly
different
interactions
between
composed
services
that
you're
that
you're
going
to
have
to
solve
for,
and
so
this
is
an
interesting
point.
Let's.
C
Hold
that
down
for
a
second,
so
we're
talking,
we,
we
are
acknowledging
that
there
are
public
and
private
API
s,
and
we
can
talk
about
why?
Why
don't
we?
Whether
services,
provides
that
wider
services
working?
That
and
other
layers
are
the
flavors
of
API.
So
also
you
can
have,
for
example,
a
web
service
type
of
API
and
you
can
have
a
command
line
API
right
and
they
each
you
might.
You
can
have
a
CLI
on
top
of
it
of
us
web
service
API,
which
is
the
crease
like
comes
to
mind.
Kubernetes.
B
C
But
they
have
different
shapes
and
different
flavors,
even
though
they
are
accessing
pretty
much
the
same
functionality.
They
know,
of
course
they
have
different
purposes
and
you
have
the
CLI
and
another
one.
Yet
is
the
library
that
the
city,
so
they
see
a
like
in
this
case
the
CLI
cause
the
library
which
caused
the
web
service
API,
but,
like
Tuffy,
is
saying
it's
critical,
sometimes
to
be
able
to
have
to
access
to
have
these
different
entry
points,
because
each
one
has
its
different
advantages
like
a
lot
of
times.
C
A
Interesting
about
kubernetes
2
and
what
I
think
they
can't
introduce,
and
someone
could
correct
me
if
I'm
wrong,
but
is
this
kind
of
concept
of
a
core
generative
type
and
inin
kubernetes,
that
that
ends
up
being
these
ghost
trucks
and
from
the
ghost
truck
you're
generating
out
the
Web
API
and
the
CLI
and
the
SDK,
and
they
all
just
come
from
from
this
one
place.
It's
all
code,
Jen
out
of
that
and
tabrets.
It's
really
the
first
place.
I've
seen
do
that.
A
But
it's
a
really
impressive
model,
because
you
end
up
with
this
nice
congruence
across
all
your
interfaces,
and
it
just
makes
the
product
really
craw
Keable.
If
you
will
that
you
can,
you
can
understand
the
concepts
better,
because
everywhere
you
go,
you
end
up
with
the
same
thing,
so
you're
interacting
with
them
in
the
same
way,.
B
A
I
mean
obviously
Cabernets
is
incredibly
declarative
and
we
could
talk
a
bit
about
declarative
or
suppurative.
Kubernetes
is
almost
entirely,
you
know
declarative.
So
you
end
up
with
kind
of
a
nice
neat
declarative
model
which
you
know
goes
out
to
ya
mole
and
you
end
up
with
a
pretty
clean
interface
and
yeah.
B
I
also
think
we
should
back
up
just
just
for
a
second
and
kind
of
talk
about
like
so.
If
we're
going
to
talk
about
just
the
API
as
it
could
be
consumed
by
other
things
like
this,
then
we're
kind
of
I
mean
I
think
we're
kind
of
talking
a
little
bit
about
kind
of
a
forward-facing
API.
This
is
definitely.
This
is
one
of
those
things
that
I
think
kubernetes
does
differently
than
pretty
much
any
other
model
that
I've
seen
in
in
kubernetes.
There
are
no
hidden
make
the
eyes.
There's
no
private
API.
B
Everything
is
exposed
all
the
time,
which
is
fascinating,
because
it
means
that
the
contract
has
to
be
has
to
be
solid
for
for
every
consumer,
not
just
the
ones
that
are
public,
but
also
any
private.
You
know
anything.
That's
built
on
the
back
end
of
community
is
the
cubelet
controller
manager.
All
of
these
pieces
are
going
to
be
accessing
the
very
same
API
as
the
user
does
and
I've
never
seen.
B
Another
application
built
this
way
in
most
applications
when
I
see
is
actually
that
they
might
define
an
API
between
particular
services
and
you
might
have
a
contract
between
those
particular
services,
because
this
is
literally
I
mean
into
kaliesha's
point
in
most
of
the
models
that
I've
seen
api's
or
contracts
written.
This
is
about
how
I
get
data
or
consume
data
or
interact
with
data
between
two
services,
and
so
there
might
be
a
contract
between
that
service
and
all
of
its
consumers,
rather
than
between.
A
It's
an
interesting
point:
yeah
I
am
like
you
said:
Kerberos
is
the
first
thing
I've
seen
that
does
that
I'm
building
API
right
now,
there's
a
strong
push
to
have
internal
internal
api's
for
it,
but
we're
building
on
top
of
a
kubernetes
product,
and
it's
it's
so
interesting.
How
they've
been
able
to
do
that?
We're
literally
every
API
is
public
eye
and
it
works
well.
There
really
aren't
issues
with
it
and
I
think
it
actually
creates
a
better
understanding
of
the
underlying
system
and
more
people
can
probably
contribute
because
of
that.
So
really
interesting
and.
D
On
that
front,
I
hope
this
is
a
good
segue,
but
I
think
would
be
really
interesting
to
talk
about
that
point.
You
made
Patrick
around
declarative
versus
imperative
and
how
the
API
we're
discussing
right
now,
with
kubernetes
in
particular,
is
almost
entirely
declarative.
So
could
you
maybe
expand
on
that
a
bit
and
and
compare
the
two
yeah.
A
I
think
it's
it's
the
thing
that
kubernetes
is
really
brought
to
the
forefront.
I,
don't
know
if
they'd
be
the
first
one.
You
know
another
notable
declarative,
API
I'd
be
terraform
right,
but
this
notion
of
you
just
declare
state
within
a
file
and
in
some
capacity,
and
you
just
apply
that
up
to
up
to
a
server
and
then
that
state
is
acted
on
by
a
controller
and
it
you
know,
brings
that
state
to
fruition.
A
Yeah
I
mean
that's
almost
indicative
of
kubernetes
at
this
point,
I
think
like
it's,
it's
so
engrained
into
the
product,
and
it's
one
of
the
first
things
to
kind
of
do
that
that
it's
it's
almost
what
you
think
of
when
you
think
of
kubernetes
and
with
the
advent
of
c
or
DS
and
whatnot,
that's
now
been
able
to
be
extended
out
to
really
any
use
case.
You
would
have
that
that
would
fit.
This
declared
a
pattern
of
just
declaring
today,
which
it
turns
out.
A
There's
a
ton
of
use
cases
and
that's
incredibly
useful,
but
now
kind
of
looking
at
you
know
in
quirky
brunette
ease.
Could
we
add
imperative
functionality
on
top
of
the
declarative
resources,
which
is
interesting
too
so
gonna
look
at
that
for
v2
now,
because
there
are
limitations
right
like
there
are
some
things
that
just
don't
fit
into
a
declarative
pattern
perfectly.
That
would
fit
just
the
standard.
You
know
rest
verbs
and
you
end
up
some
weird
edges
there.
A
C
A
The
two
yeah
you
so
like
say
you
have
an
object
that
just
represents
something
we'll
call
it
foo
and
you
have
a
yeah
mole
file
and
you're
declaring
food
to
be
some
sort
of
thing
all
right.
You
could
apply
that
file
and
now
that
state
exists
within
the
system
and
things
notice
that
that
state
of
change
and
they're
acting
on
that
state
I.
We
there
are
times
when
you
you
might
want
that
food
to
have
another
action
right.
Besides
just
applying
say
you
may
want
it
to
have
some
sort
of
capability
on
top
of
applying.
A
That
say,
there
are
quite
a
few
use
cases
that
come
in
where
that
turns
into
a
thing.
So
it's
something
explore
it's
a
bit
of
a
you
know,
Pandora's
box.
If
you
will,
because
you
know
where
does
that
end,
kubernetes
is
kind
of
nice
that
it
does
enforce
constraints
at
this
core
level
and
it
produces
these
really
kind
of
deep
patterns
within
the
system
that
people
find
kind
of
easy
to
understand,
at
least
at
a
high
level.
Granted
you
could
keep
into
it.
It
gets
highly
complex,
but
you
know
enforcing,
like
namespaces.
A
You
know,
as
this
concept
of
just
a
flat
name,
space
with
declarative
resources
within
its
and
then
declarative
resources
themselves,
just
being
confined
to
the
standard.
Rest
verbs
is
a
model
that
people
I
think
understand
well
and
I
think
this
is
part
of
the
the
success
that
kubernetes
is
just
that
people
could
get
their
heads
around
that
model
and
it's
also
just
incredibly
useful
right.
I.
Think.
B
That's
right,
another
to
add
a
little
more
color
to
this
I.
Think
another
way
to
think
about
this
is,
like
you
probably
see
articles
out
there,
that
kind
of
described
sort
of
the
breast
bone
model
and
talking
about
whether
rest
can
be
transactional.
So
let's
talk
about
a
little
bit
about
what
that
means.
B
So,
like
a
naive,
intimate
and
a
naive
implementation
of
an
of
an
API
like
pattern
or
an
interface
pattern
might
be
that
the
client
sends
information
to
the
server
and
if
the
server
locks
that
client
connection
until
it
is
able
to
return
the
the
results
whatever
that
result
is
think
of
this
in
some
ways
this
is
very
much
like
a
database
right.
If
I,
if
as
a
client
of
a
database,
I
want
to
insert
a
row
into
a
database,
the
database
will
lock
that
row.
It
will
lock
my
connection.
It
will
insert
that
datum.
B
It
will
insert
that
row
and
it
will
return
success
and
in
this
way
it's
a
synchronous
right.
It's
not
it's
not
trying
to
it's
not
trying
to
just
accept
the
change
it
wants
to
make
sure
that
it
returns
to
me.
I
have
I
have
persisted
that
change
to
the
database
before
letting
go
of
the
connection.
This.
B
This
pattern
is
probably
one
of
the
most
common
patterns
in
interfaces
in
the
world
like
it
is
way
super
common,
but
it's
very
different
than
the
restful
pattern,
or
a
fourth
or
some
of
the
implementations
of
a
restaurant
pattern
in
which
what
we
say,
especially
in
this
declarative
model
right
and
a
declarative
model,
the
contract
is
basically
I'm
going
to
describe
a
thing
and
you're
gonna.
Tell
me
when
you
understand
the
thing
I
want
to
describe,
and
it's
asynchronous
so,
for
example,
if
I
were
interacting
with
kubernetes
and
I
said
cubic
it'll
create
a
pod.
B
I
would
provide
the
the
information
necessary
to
define
that
pod,
declaratively
and
I
would
get
back
from
the
confirm.
The
API
server
200,
okay,
pod
has
been
accepted,
doesn't
mean
it's
been
created.
It
means
it's
been
accepted
as
an
object
and
persisted
to
disk
now
to
understand
from
a
declarative
perspective
where
I
am
in
the
lifecycle
of
managing
that
pod
objects.
I
have
to
query
that
API
again,
hey
this
pod.
That
I
asked
you
to
make.
B
Are
you
done
making
it
or
is
an,
and
how
does
this
work
between
like
and
and
where
are
you
in
that
cycle
of
creating
that
thing
right,
and
this
is
where
you're
like
with
including
this.
We
have
the
idea
of
a
spec
which
defines
all
of
the
bits
that
are
declaratively
described
and
we
have
the
idea
of
a
status
which
describes
what
we've
been
up
to
around
that
declarative
object
and
whether
we've
actually
successfully
created
it
or
not.
B
I
I
would
argue
fundamentally
that,
from
a
cloud
native
perspective
that
declarative
model
is
critical
to
our
success.
Because
of
this
it
allows
us
to
scale.
It
allows
us
to
provide
an
asynchronous
API
around
those
objects
that
we're
trying
to
interact
with,
and
it
really
changes
the
game
as
far
as
like
how
we
go
about
implementing
those
inputs
right
like
and
it's
pretty
interesting
stuff
yeah.
C
This
is
so
interesting.
It
was
right.
Definitely
a
man
Mindbender
for
me
when
I
started
developing
against
coburn
a
shift
because
he
was
like
what
do
you
mean
you
returned
to
200,
ok
and
the
thing
is
not
created
yet
I
mean
it's
not
hard
to
understand,
I'm
not
used
to
that
model,
but
I
think
it
gives
us
a
lot
of
control.
C
So
it's
very
interesting
in
that
way
and
if
my
and
I
think
you
might
be
right
of
it
might
be
critical
to
the
success
of
cognitive,
perhaps
because
it's
almost
like
the
way
I'm
thinking
about
it
right
now,
just
having
hurt
you,
it's
almost
like,
with
with
other
models
you
let's
say
you
are
working
over
the
database
in
a
tree.
You
in
the
transactional
system
you're
sending
the
data
that
there
has
to
be
inserted
in
that
system
decides
to
retry
or
not,
and
what
wants
the
processor
there's
actually
is
complete?
C
B
You
know,
first
bus,
the
threads
are
first-class
right
like
that
you
can
build
a
channel
but
handle
each
individual
request
that
you're
not
that
you're
not
in
this
world,
where
all
of
it
you
know
all
transactions
have
to
stop
until
this
one
is
complete
and
then
we'll
take
the
next
one
other
to
you
and
do
that
one
we're
no
longer
in
that
kind
of
a
queue
model.
You
can
actually
handle
these
things
in
parallel,
quite
a
bit
more
and
it
it
makes
you
think
differently
when
you're
developing
software
system
degrees,
yeah.
A
I
think
it's,
you
know,
it's
very
that
you
can
check
this
stuff
into
a
repo
today
and
the
advent
of
get
ops,
you
know,
is
almost
parallels.
You
know
the
advent
of
kubernetes
and
terraform
and
that
you
can
now
have
this
state.
That's
you
know,
source
controlled,
and
then
you
just
apply
it
to
this
system
and
it
kind
of
understands
what
to
do
with
it
now
to
put
all
the
pieces
together
that
you
gave
it,
which
is
a
super
powerful
model.
There's.
B
Another
there's
another
point
to
that
whole
asynchronous
model.
It's
like
the
idea
of
the
API,
that
is,
that
has
a
declarative
or
an
imperative
model,
and
this
is
an
idea
in
distributed
systems
that
is
referred
to
it's
like
edge,
triggering
or
level
triggering.
It
definitely
recommend.
Looking
up
this
idea,
there's
a
great
article
on
it,
I
know,
and
what
in
what
they
hide,
and
what
they
highlight
is
that
you
know
from
the
pure
abstract
perspective,
there's
probably
no
difference
between
the
edge
and
level
triggering.
B
What
happens
if
the
process
itself
dies?
What
happens
if
you
know
any
of
the
interruptions
that
we
talked
about
happened
rightly
another
good
example
of
this
is
sort
of
like
that
kind
of
the
Kafka
model
versus
something
like
a
like
a
watch
on
a
CD
right
in
Kafka.
You
have
these
events
that
you're
watching
for
and
if
you
weren't
paying
attention
when
that
event
went
by
you
didn't
get
that
event.
It's
not
it's
not
still
there.
B
It's
gone
now,
whereas,
like
with
HUD
and
models
like
that,
what
you're
saying
is
I
need
to
reconcile
my
expected
state
of
the
world
with
what
the
desired
state
is,
and
so
I'm
no
longer
looking
for
events
I'm
looking
for
a
list
of
work
that
has
to
be
that
I
have
to
that.
I
have
to
reconcile,
which
is
a
very
different
model
for
these
sorts
of
things.
Yeah.
A
B
D
B
In
particular,
okay,
so
I
guess
you
kind
of
get
into
like
what
some
of
the
forms
of
these
api's
talk
about
like
we
can
talk
about
restful
days,
api's,
which
is
cheer
pc-based
api's,
or
maybe
even
just
interfaces
back
and
forth
between
modular
code.
And
you
know
it's
like
how
and
how
that
kind
of
help.
B
That
is
that
will
surpass
what
the
entire
model
is
can
handle
as
long
as
you're
really
clear
about
the
contract
that
you're
defining
between
those
functions
then
later
on,
when
it
comes
to
a
time
to
externalize
those
functions
and
kind
of
embrace
Marva
micro-services
model,
mainly
due
to
traffic
or
load
or
any
of
the
other
concerns
that
kind
of
drive
you
toward
a
cloud
native
architecture,
I
think
you're
in
a
better
spot,
and
this
is
definitely
one
of
the
points
of
that
contract
piece
that
I
wanted
to
raise
up.
There.
C
C
You
have
to
break
these
into
microservices
because
you
have
bottlenecks
in
your
monolith
and
maybe
you
have
to
redo
the
whole
thing.
Once
you
have
the
micro-services
you,
you
have
gone
through
the
exercise
of
deciding.
You
know
this
goes
here.
This
goes
there
and
once
you
once
you
have
those
separate
I,
don't
know
say
they
were
containing
those
modules.
The
separate
modules
you
it's
clear
what
they
should
go,
but
when
you
have
a
model
that
is
so
easy
to,
you
know
put
these
in
the
different
units
replace
in
a
place
where
they
shouldn't
be.
C
B
C
B
It
is
easy
to
when
writing
when
quickly,
even
quickly,
rapidly
prototyping,
an
application
that
has
multiple
functions,
to
be
careful
about
those
interfaces
that
you're
writing
like
go
because
there's
a
strongly
typed,
like
which
kind
of
forces
you
into
this
right
like
there
are
some
other
things,
there's
some
other
languages
that
are
out
there
that
are
kind
of
like
really
that
make
it
difficult,
be
sloppy
about
those
interfaces
and
I.
Think
that's
that's.
B
You
know
inherently
a
good
thing,
but
but
to
your
point,
like
you
know,
you
look
at
some
of
the
larger
model
lists
that
are
out
there.
It
is
very
easy
to
fall
into
these
patterns
where,
instead
of
a
asynchronous
API
or
an
asynchronous
interface,
you
have
just
a
you
know,
an
A
to
B
interface
and
your
a
synchronous
interface
in
which
you
expect
that
I
will
be
able
to
call
this
function
open
it
something
in
there.
I'll
get
the
result
back,
and
that
is
a
pattern
for
monoliths
like
that's
how
we
do
it
in
monolith.
B
C
C
B
Conway's
law
as
an
overview,
is
it's
basically
that
an
organization
will
build
software
laid
out
similar
to
the
way
that
the
organization
itself
is
architected.
So
if
everything,
so,
if
everybody
is
everybody
in
the
entire
company
is
working
on
one
thing
and
they're
really
focused
on
doing
that.
One
thing:
you
were
to
build
a
model
list.
If
you
have
these
groups
that
are
disparate
and
it
really
focused
on
some
subset
of
work
and
need
to
communicate
with
each
other.
B
This
yeah
I
think
it's
totally
because
that's
a
great
point
like
so
actually
one
of
the
things
that
about
about
a
heftier
that
I
found
so
fascinating
was
that
we
were
a
hundred
people
and
we
were
everywhere
and
there
was
and,
and
so
communication
became
a
problem
that
absolutely
had
to
be
solved
or
we
wouldn't
be
able
to
move
forward
as
a
team,
and
so
it
was
really
yeah.
That's
a
very
good
point.
D
An
observation
that
I
had
in
my
past
life
helping
folks
break
apart,
Java
monoliths,
sorry,
there's
a
dog
barking.
Hopefully
you
can't
hear
it
breaking
apart.
Java
Mon
Alice
was
but,
like
you
said,
Duffy
like
it
seemed
they
had
really
good
interfaces
and
contracts
right,
and
that
made
it
a
lot
easier
to
find.
The
breaking
points
for
their
API
is
to
pull
those
api's
out
into
a
different
type
of
API
right.
D
They
went
from
this
programmatic
API,
that
was
in
the
JVM,
where
things
were
just
dinner,
communicating
it
to
an
API
that
was
based
on
a
web
service
in
an
interesting
observation.
I
often
times
found
was
that
people
didn't
realize
that
they
were
moving
complexity
from
within
the
app
to
the
network
space
and
that
oftentimes
caused
a
lot
of
issues,
so
no
I'm
not
trying
to
down
api's,
because
obviously
we're
talking
we're
trying
to
talk
about
the
benefits
of
them.
But
it's
an
interesting
balancing
act
oftentimes
when
you're
working
with.
How
did
you
couple
a
monolith?
D
B
It
means
that
you
have
to
just
be
really
super
careful
about
how
you're
modeling
that
and
because,
if
you,
if
you
get
to
the
point
where
this,
why
this
software
that
you
built
that
as
a
monolith
is
wildly
successful
and
all
of
its
consumers
are
network
based,
you're
gonna
have
to
kind
of
come
around.
You
don't
like,
and
so
yeah
yeah
I
think
that's
I!
Think
that's
pretty
critical!
No
I
mean
on
that
point
of
how
contracts
I
think.
Another
thing
that
we
haven't
really
talked
on
so
much
is
like.
B
We
all
agree
that
maybe
like
an
API
for
the
consumer
model
is
important.
We've
talked
a
little
bit
about
like
whether
a
private
API
is
or
publicly,
if
you
guys
make
sense,
we've
kind
of
described
some
differences
between
or
you
know
what
are
the
weird
one,
but
the
wacky
things
that
kubernetes
does,
which
is
that
there
are
no
private
API.
B
One
of
the
other
things
that
we
should
talk
about
is
when
you're
starting
to
think
about
these
contracts.
One
of
the
biggest
key
or
one
of
the
biggest
most
important
bits
is
how
you
handle
the
lifecycle
ability
API.
So
as
they
change
right,
like
as
I,
add
new
features
or
functionality
or
as
I
deprecated
old
features
of
functionality
like
what
are
my
concerns
as
it
released
in
this
contract,
tell.
B
A
I
spend
a
lot
time
in
this
space
recently
and
I
researched
it
for
like
a
month
or
so
and
honestly,
like
you're,
saying
there
are
no
perfect
dancers
to
try
to
version
an
API.
Every
single
one
of
them
has
horrible
potential
consequences
to
it.
The
protic
you
burn
a
took
is
api
evolution
we're
basically
all
versions
of
the
API
I
have
to
be
backwards
compatible
and
they
basically
all
translate
to
what
is
in
an
internal
type
in
kubernetes,
and
everything
has
to
be
translatable
back
to
that.
A
It
is
also
very
difficult
to
deal
with
the
times,
because,
if
you
add
things
to
API,
you
can't
really
ever
remove
them
I
without
some
sort
of
a
massive
amount
of
deprecation
effort,
basically
monitoring
the
usage
of
that
API
specifically
and
then
somehow
deprecating.
It's
it's
incredibly
challenging
so
yeah.
B
I'm
actually
really
I've
got
my
popcorn
ready
for,
like
it's
like
116,
in
which
we
actually
finally
turned
off
a
lot
of
the
deprecated
API
s
that
that
could
be
need
is
had
so
a
lot
of
stuff
that
has
been
mike
has
been
moved
for
some
number
of
versions
off
to
different
spaces,
for
example,
deployments
used
to
be
in
extensions
and
other
apps.
You
have
a
lot
of
these
things.
Some
of
the
older
aps
are
going
to
be
turned
off
by
default
in
in
116
and
I'm,
like
really
interested
to
see
how
this
plays
out.
B
You
know
from
kind
of
a
chaos
level
perspective,
but
yeah
you're
right.
It's
tough.
You
know
like
having
that
backwards.
Compatibility
definitely
means
that
the
contract
is
still
viable
for
your
customers,
regardless
of
how
old's
their
client
how
that
client
side
looks
like,
but
I
mean
this
is
kind
of
a
fingernail
problem
right,
you're,
going
to
be
in
a
situation
where
you're
beholding
those
translations
to
to
that
stored
object
for
how
many
generations,
before
you're
able
to
finally
get
rid
of
some
of
those
old
api's.
That
were
that
you
have
obviously
moved
on
from
yeah.
C
Deprecated
an
end
point
is,
there
is
no
is
not
review
at
all,
and
ideally,
like
Patrick
was
saying
you
would.
You
would
be
able
to
monitor
the
usage
of
time
point
and
see,
as
you
intend
to
defecate
if
the
usage
is
going
lower
and
if
there
is
anything
you
can
do
to
accelerate
that
so
which
actually
made
me
think
of
a
question
I
have
for
you
guys
because
I
don't
know
the
answers.
Do
we
have
access
to
the
endpoints
uses
the
consumption
rate
of
kubernetes
endpoints
by
any
other
cloud
service
providers?
Okay,
you'll,
be
nice.
C
B
C
B
C
D
Regarding
versioning,
taking
out
of
kubernetes
for
a
second
I,
also
think
this
is
one
of
the
challenges
with
micro
service
architectures
right,
because
now
you
have
the
ability
to
independently
deploy
a
service
outside
of
the
whole
monolith.
And
if
you
happen
to
break
something
that
perhaps
contractually
you
said,
you
would
and
people
just
didn't
pay
attention
or
you
accidentally
broke,
not
knowing
it
can
cause.
D
C
B
Instead
of
actually
trying
to
define
an
API
between
in
front
of
a
service,
you
can
make
that
ap.
You
can
make
that
service
a
consumer
of
a
centralized
API,
and
now
you
have
one
contract
to
write
and
one
contract
to
standby,
and
all
of
those
things
that
are
going
to
do.
Work
are
going
to
pull
down
from
that
central
API
and
do
the
work
and
put
back
into
that
central
API.
B
The
results
right,
meaning
that
you're
kind
of
you're
flipping
this
model
on
its
head,
you're,
no
longer
and
locking
to
service
B
until
service
B
can
return
a
result
to
you,
you're
saying
service,
B,
here's,
a
here's,
here's
a
Q
or
maybe
a
declarative
state
that
I
want
you
to
accomplish
and
when
you're
done
accomplishing
it.
Let
me
know,
and
I
will
come
back
for
the
results
right
and
you
could,
let
me
know
an
event
stream.
You
can.
B
Let
me
know
by
updating
a
status
object
that
I'm
monitoring,
there's
lots
of
different
ways
for
you
to.
Let
me
know
that
service
B
is
done
doing
the
work,
but
it
really
makes
you
think
about
kind
of
the
architecture
of
these
distributed
systems,
and
it's
really
one
of
the
big
highlights
for
me
from
personally
when
I
look
at
the
way
that
that
kubernetes
was
architected,
because
there
are
no
private
API
s.
Everything
talks
to
the
API
server
everything
that's
doing
work
regardless
of
what
day.