►
Description
DevOps Friendly Doc Publishing for APIs & Microservices - Amanda Whaley, Cisco DevNet
Microservices create an explosion of internal and external APIs. These APIs need great docs. Many organizations end up with a jungle of wiki pages, swagger docs and API consoles. Keeping docs updated and in sync with code can be a challenge. We’ve been working on a project to help solve this problem for engineering teams internally across Cisco. The goal is to create a forward looking developer and API doc publishing pipeline that:
- Has a developer friendly editing flow
- Accepts many API spec formats (Swagger, RAML, etc)
- Supports long form documentation in markdown
- Is CI/CD pipeline friendly so that code and docs stay in sync
- Is flexible enough to be used by a wide scope of teams and technologies
This session will share many lessons learned about tooling and attendees will learn how to solve documentation challenges for internal and external facing APIs. We have found that solving this doc publishing flow is a key component of a building modern infrastructure.
About Amanda Whaley
Amanda Whaley is Director of Developer Experience & Developer Evangelism for Cisco DevNet. She spends most of her time thinking about how developers use Cisco APIs, and about how to make their job easier. She also leads a team of developer evangelists who work with Cisco partners and developers in many technology areas including IoT, Collaboration, and Software Defined Networking. Amanda has a background in application development and engineering, and she is interested in all things that help developers build cool stuff – tools, APIs, docs, frameworks. She also a mom of two little boys, novice drummer, and you can often find her on the mountain biking trails in her hometown of Austin, TX.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
So,
first
a
little
bit
about
me,
I'm
from
Austin,
it's
so
fun
to
have
this
here
in
our
city
and
get
to
share
it
with
all
of
you.
Sorry
about
the
weather.
My
background
is
software.
Development
I
worked
as
a
developer
for
many
years
and
then
I've
also
done
a
lot
of
developer
enablement,
so
educating
developers
getting
developers
ramped
up
on
different
platforms
and
spend
a
lot
of
time
working
on
developer
experience,
an
API
experience
and
I
think
this
sign
is
just
the
epitome
of
Austin
boots
flip-flops
and
an
Airstream
trailer
this
way.
A
So
you
can
keep
a
lookout
for
that.
It's
downtown
all
right!
So
many
of
us
at
this
conference.
Maybe
everyone
at
this
conference
is
somehow
involved
in
in
this
picture,
going
from
building
monolithic
applications
to
cloud
native
micro
services
or
maybe
you're
just
starting
with
the
cloud
native
micro
services,
and
this
is
really
great
there's,
so
many
benefits
that
you
can
hear
about
in
oodles
of
other
sessions.
So
I'm
not
gonna
go
through
them,
but
these
are
some
of
the
reasons
why
you
would
go
down
this
path.
A
But,
however,
you
define
a
micro
service
which
there's
lots
of
different
ways
to
define
it,
and
this
is
one
I
think
from
Microsoft
that
I
just
picked,
but
they
all
have
the
idea
of
services
that
communicate
with
each
other
over
standard
protocols
with
defined
interfaces
and
when
I
read
that
last
part,
you
say
standard
protocols
with
defined
interfaces.
This
typically
means
an
API,
and
that
starts
me
down.
A
My
I
worry
about
developer
experience
path,
which
is
what
I
do
for
Cisco
and
what
I've
done
for
a
lot
of
companies,
and
so
why
do
we
worry
about
it
and
what
is
developer
experience?
It's
really.
What
is
a
the
experience
for
a
developer
using
an
API,
and
this
is
really
important,
because
developers
are
users
and
what
I
want
to
talk
about
in
this
section
is
also
your
internal
developers
are
even
users
right
if
you're
building
micro
services
and
you're
wanting
people
across
organizations
or
in
partner
organizations
to
use
some
of
your
api's.
A
Do
you
have
to
think
about
the
experience?
It
doesn't
just
happen
by
itself,
so
this
is
taking
some
thoughts
from
worrying
about
external
developer
experience
and
try
to
put
it
your
head
around
using
that
to
applied
here
internal
developers,
so
bad
experience
means
you're,
making
me
use
it.
I
don't
want
to
use
it,
I
have
a
low
barrier
for
leaving
and
it
doesn't
spur
growth
right.
A
Good
experience
I
like
to
use
this
I'm
going
to
tell
other
people
about
it,
maybe
within
my
company
within
my
organization,
outside
of
it
and
I'm,
going
to
find
innovative
ways
to
use
it.
So
this
is
really
the
goal
that
we're
striving
for
in
the
API
and
developer
experience
like
industry
thought,
there's
so
much
good
work.
A
The
writers,
the
developers,
the
engineers
who
come
together
to
create
that
developer
experience,
and
it's
it's
a
hard
thing
to
do
right.
You
and
when
you
think
about
prioritizing
that
for
internal
projects,
it's
even
harder
because
you're
running
fast
you're
moving
quickly
and
that's
you're
not
going
to
get
together
and
all
those
people
and
put
that
same
level
of
emphasis
around
it.
Like
you
would
for
your
for
your
external
audience.
A
How
will
the
team's
prioritize
the
time
to
curry
these
internal
docks?
How
will
they
keep
them
updated
when
you're
really
changing
quickly
and
the
think
about
that?
These
good
API
Doc's
are
really
the
key
to
bridging
organizational
boundaries
and
there's
been
a
lot
of
really
interesting
today,
there's
more
and
more
coming
out
about
how
these
patterns
and
when
you
can
bridge
those
organizational
boundaries
easier,
you
really
accelerate
the
innovation
that
happens
inside
enterprises
and
its
really
fueling,
like
sort
of
this
rebirth
of
IT
with
the
composable
enterprise.
A
So
some
of
the
things
that
you
need
just
to
start
thinking
and
and
some
of
the
things
that
we
tackled
in
this
project,
you
absolutely
need
API
reference.
Docs,
that's
your
first
thing,
that's
the
easiest
one
everyone
thinks
about.
You
also
need
probably
some
long-form
documentation
like
authentic
authentication
guides.
How
do
you
get
started
with
it?
You
need
some
the
error,
codes
and
versioning.
A
So
we
started
looking
at
like
how
are
people
doing
this
and
it's
interesting
because
I
work
at
Cisco
and
I
the
definite
organization
that
I
work
and
we
work
with
engineering
teams
all
across
this-
go
from
IOT
to
data
center,
to
networking
to
cloud
to
collaboration
like
all
these
different
technologies,
and
then
we
work
with
a
lot
of
our
customers
and
partners
and
then
we're
at
conferences
and
Industry
places
like
this.
So
we've
been
talking
to
a
lot
of
people
about
how
are
you
doing
this?
A
What's
the
story,
how
are
you
actually
doing
this
for
your
internal
and
external?
Are
you
taking
your
external
practices
and
applying
them
internally?
Is
that
too?
Heavy
is
it
just
happening
informally,
you
know
what
what
are?
What
are
you
finding
out,
and
these
are.
This
is
a
fictional
summary
of
the
conversation
that
I've
had.
It
goes
something
like
this:
how
are
you
documenting
your
internal?
You
guys
Oh
ease,
swagger
awesome,
that's
great!
That's
cool!
What
about
you
know
additional
information
like
how
to
authenticate.
Oh
yeah
we've
got
some
how
to
use
in
a
wiki
somewhere.
A
Okay,
that's
pretty
good,
so
swagger
and
a
wiki,
and
you
probably
link
back
and
forth
okay.
Anything
else.
I
know!
That's
it!
That's
all!
Okay,
great!
Oh
yeah!
There
are
a
few
teams
that
also
use
ramble
because
they
started
down
that
path
and
sort
of
swagger
and
they
haven't
changed
over
and
maybe
they're
gonna
convert.
But
right
now
there's
some
teams
that
are
using
Ramlal
as
well.
But
that's
that's.
That
is
totally
it
like.
That's
that's
everything!
Okay,
really!
A
Are
you
sure,
oh
yeah
and
there's
some
stuff
and
read
the
docs,
because
we
did
like
an
internal
experiment
with
that
with
one
team
and
really
yep,
then
some
teams
use
markdown
and
we've
got
code
samples
in
github
and
then
the
person
having
this
conversation
with
is
me
ends
up
like
facepalm
like
how
do
you
do?
How?
How
are
you
managing
all
that
these
are
all
really
great
tools
right,
like
they're,
all
very
good
for
their
fit
purpose
and
they
fit
together?
But
when
you
think
about
that
overall
experience,
it's
got
some
problems.
A
First
of
all,
how
do
you
keep
them
in
sync,
with
what's
going
on
with
all
your
micro
services?
How
do
you
connect
them
to
your
CI
CD
pipeline?
That's
a
bit
wildering
jungle
of
user
experience
to
find
right.
It
leads
to
a
lot
of
feeling
of
where's.
That
link.
Is
it
in
that
slack
channel
over
here
and
where
did
it
go
and
then
where's
the
magic
wiki
page?
That
ties
all
this
together
for
me
and
and
what
do
I
do
and
so
then
sometimes
teams
will
give
up.
They
won't
reach
out.
A
They
won't
have
the
conversation.
They're
lost
and
then,
if
a
lot
of
times,
if
you're
building
an
internal
API,
it's
really
great.
If
you
can
think
about,
maybe
someday
that
might
get
opened
up
externally
right,
maybe
it
progresses.
It
grows
to
be
something
that
you
would
open
up
as
a
service,
your
customer
or
your
community.
And
if
you
don't
think
about
that
publishing
at
the
beginning,
then
you
have
this
really
big
hurdle
when
you're
ready
to
open
it
up
externally.
A
So
there's
no
easy,
easy
path
to
say
now:
we're
gonna
make
this
API
open
to
the
public
or
to
a
small
view
set
of
people
to
start
doing
some
trials.
It
puts
a
big
barrier
there
and
then
there's
this
issue
that
I
wanted
to
call
special
attention
to
you,
because
it's
something
that
comes
up
in
the
external
work
that
we
do
and
it
also
comes
up
in
the
internal
work
and
that's
this
idea
of
yes,
you
need
an
API
reference.
A
Definitely
that's
pretty
much
easy
swagger
is
you
know,
open,
API,
spec
and
a
lot
of
times.
You
can
auto
generate
it
and
you
can
automate
that
and
it's
easy
to
tie
in
and
people
are
doing
pretty
good
keeping
that
up
to
date,
but
I
always
make
this
analogy
that
an
API
reference
without
some
kind
of
long-form
documentation
is
like
giving
someone
a
box
of
bicycle
parts
that
are
labeled.
This
is
a
handlebar.
This
is
a
gear
crank,
but
how
do
you
put
it
together
like
now?
A
Do
you
just
give
them
that
box
and
then
they're
supposed
to
put
it
together
and
write
off
down
the
street?
It's
not
a
very
good
experience.
You're
like
sorting
through
all
those
pieces
trying
to
fit
how
they
can
fit
together.
So
some
kind
of
long-form
documentation
can
really
ease
that
initial.
Friction
right.
Here's
the
key
code
sample
that
you
need!
Here's
how
you
get
authenticated
and
here's
the
first
thing
that
you're
gonna
do
right.
What's
your
first
hello
world,
but
right
now,
that's
really!
A
You
can't
really
auto
generate
that
and
you
can't
really
automate
it
very
well
and
it's
not
really
there's
nothing
that
really
ties
together.
The
API
reference
in
the
long-form
documentation
in
a
great
format.
So
we
kind
of
came
to
this
for
our
Cisco
needs
and
we
thought
can
we
build
something
that
would
that
can
help
with
this?
That
can
help
the
teams
that
we're
working
with
that
can
help
our
own
team
that
we
could
maybe
look
towards
bridging
that
internal
to
external
path.
A
Could
we
address
some
of
these
issues,
and
so
we
started
working
on
this
and
we
put
out
some
initial
ideas
around.
Yes,
these
are
the
things
we
attributes
we
want
this
to
have,
and
no
we
don't
want
to
do
this
when
we
start
down
the
path
of
building
it
on
the
s
side,
we
wanted
it
to
be
CIC,
D,
friendly,
Publishing
flow.
A
We
wanted
it
to
be
developer,
friendly
authoring
tools
because,
ideally
we're
getting
the
actual
engineers
writing
the
micro
services
to
spend
a
little
bit
of
time
documenting
it,
and
maybe
writing
some
of
that
getting
started
information.
So
we
didn't
want
it
to
be
something
that
a
tech
writer
had
to
get
involved
with.
We
wanted
it
to
feel
like
it
fit
into
your
coding,
toolset
and
workflow.
A
Ideally,
we
would
like
to
have
a
central
place
where
you
could
go
and
maybe
find
out
about
all
of
your
internal
api's
and
then
because
of
the
breadth
of
scope
that
we
were
working
across.
We
really
wanted
to
maintain
some
flexibility
for
each
engineering
team
to
make
some
decisions
that
fit
their
problem
space
very
well.
So
we
wanted
it.
A
We
didn't
want
it
to
be
overly
prescriptive,
but
we
did
want
to
bring
things
together
and
we
wanted
to
have
sample
code
Docs
all
these
things
in
a
way
that
we
can
keep
in
sync,
but
we
did
not
want
to.
We
didn't
want
to
reinvent
the
wheel
if
there
was
an
open-source
tool
that
we
could
use
if
their
specifications-
or
you
know
things
like
open,
API
spec-
definitely
use
reuse.
A
What
we
can
we
didn't
want
to
build
something
proprietary
enclosed
and
we
didn't
want
it
in
strictly
enforced,
only
one
way
of
doing
things,
because
we
knew
that
simply
wouldn't
work
for
the
environment
of
our
company
and
we
didn't
want
to.
We
wanted
to
avoid
dropping
really
key
functionality
that
might
be
available
in
some
of
those
best-in-class
tools,
so
those
were
kind
of
some
of
the
things
that
we
set
out
for
we've
accomplished.
A
So
this
was
the
project's
it's
we
call
it
pub
hub.
It's
just
an
internal
project
right
now
that
we're
using
and
basically
that's
what
it
does.
It
has
a
way
of
front-end
or
you
can
create
projects,
and
you
can
accept
all
these
different
types
of
documentation.
Swagger
markdown
ramble
some
cisco,
specific
ones
that
we
decided
to
grapple
with
and
deal
with,
and
then
you
know
other
things
from
the
industry
and
we
actually
use
some
open
source
tools
for
being
able
to
process
all
those
different
types
and
then
it's
all
based
through
github.
A
So
we
wanted
it
to
be
very
much
driven
as
you
would
code.
So
this
is
taking
documentation
and
treating
it
like
code
because
we
were
doing
it
for
developers
right
and
so
it's
all
managed
through
get.
You
use
very
a
very
standard,
commit
tag,
push
you
know,
kind
of
similar
flow
that
you
would
and
then
you
can
build
it
stage
and
publish
it.
A
B
A
A
really
really
short
video,
it
just
shows
like
the
setup
of
a
project.
It
doesn't
go
super
deep
and
it's
it's
sped
up
and
you
get
to
see
my
bad
typing.
So
that's
good
times,
so,
basically
we,
it
does
have
a
place
where
you
can
initiate
the
project
you
create
it.
You
get
your
project,
you
can
add
contributors
here
or
through
github,
and
then
eventually
you
get
your
actual
repo
URL
and
then
now
you're
kind
of
just
off
to
your
regular
flow.
You
can
work
with
whatever
tools
you
like
to
manage.
A
Your
get
flow,
I'm
just
doing
mine
from
the
command
line,
and
then
you
can
see
it's
very
much.
Driven
off
of
this
is
a
markdown
file
that
I'm
typing
and
it's
driven
off
of
a
JSON
sort
of
table
of
contents
that
glues
everything
together
and
I'm,
just
making
a
quick
change,
and
then
we
go
back
in
and
you
can
actually
see
it
in
the
here
now.
A
It's
got
my
new
project
in
my
supercool
content
and
then
from
there
you
could
go
and
you
know
do
further
things
and
all
that
can
hook
into
your
CI
CD
process
as
needed.
Okay
and
then
this
is
just
some
samples
of
what
some
of
it
looks
like,
so
this
would
be
a
markdown
file
that
has
code
snippets,
inline
and
you
can
use
different
kinds
of
different
languages
and
have
those
show
up.
This
can
do
inline
code
display
or
you
can
do
like
sort
of
the
stripe
three-column
if
you
want
to
have
it
side-by-side.
A
So
it's
some
options
on
that.
This
is
ramble,
so
yeah
I
mean
sorry,
it's
a
swagger,
so
you
can
see
you
get
most
of
your
normal
swagger
field
and
all
the
normal
swagger
documentation
features.
This
is
ramble
and
now
I
want
to
go
into
the
lessons
learned.
This
is
the
most
interesting
part,
so
some
of
the
things
that
we've
been
talking
to
users
about
and
that
we've
gotten
back
as
feedback
one,
is
that
this
long-form
Doc's,
plus
the
API
reference,
really
resonated
as
a
problem
that
everybody
was
having
and
I.
A
This
is
a
across
the
industry,
people
that
I'm
talking
to
everybody
is
coming
up
with
different
ways
to
solve
this
problem,
but
there
there's
nothing,
that's
really
standing
out
quite
yet,
and
it's
it's
really
important
because,
as
people
are
getting
more
specific
about
their
developer
experience
and
they're
really
encouraging
everyone
to
have
those
long-form
Docs
to
make
it
good.
There's
this
question
of
how
do
I
do
it?
How
do
I
keep
in
sync?
How
do
I
tie
it
together
with
my
APA
reference
from
swagger?
A
A
I,
don't
think
I
have
to
think
about
how
I'm
gonna
format
these
Docs,
my
internal,
Docs
and
I'm
very
proud
to
share
them
around
my
organization
or
put
them
out
to
people
and
I
didn't
have
to
spend
time
coming
up
with
a
style
sheet
or
picking
a
framework
or
making
it
match,
whatever
corporate
things
I
want,
and
they
also
know
that
it's
a
recommended
secure
way
to
do
it
that
we've
built
and
fits
all
the
norms.
So
it
saves
them
time,
they
don't
have,
they
can
just
start
coding.
A
They
know
how
they're
going
to
document
it
and
that's
been
very
popular
and
that's
kind
of
the
second
one
to
is
that
having
a
prescribed
way
to
do
this
and
where
they
don't
have
to
change
a
lot
on
their
and
to
fit
into
it?
If
they're
already
using
one
of
these
formats,
we
can
accept
it
and
it
gives
them
a
path
forward,
and
so
that's
been
that's
been
a
big
time
saver
and
then
the
multiple
input
types
has
just
been
key.
A
This
has
been
a
really
interesting
thing,
so
the
the
two
audiences
that
this
hits
is
developers
and
then
writers,
and
when
we
started
it,
we
were
really
just
thinking
about
the
developers,
because
that
was
kind
of
our
initial
audience.
We
were
working
directly
with
the
engineering
teams.
We
knew
writers
would
be
involved
for
external
Docs,
but
we
didn't
know
if
they
would
be
involved
for
some
of
the
internal
documentation,
but
we've
actually
found
that
it
does
the
writers
do
you
get
involved
in
in
certain
places
of
it,
and
certainly
for
the
external
documentation.
A
You
have
these
two,
these
two
audiences
and
they're
really
AM
they're
they're
different,
but
they
are
also
the
same
in
some
ways.
The
main
difference
has
been
around
get
so
the
developers
are
very
happy.
They
have
their
normal
tool
set
some
doc
writers.
Many
of
them
are
really
making
this
journey
to
learn
how
to
and
get
and
markdown
and
manage
docks
that
way,
but
there's
a
lot
of
them
who
that
may
be
really
really
new
to
and
and
so
we've
had
to
spend
quite
a
bit
of
time
with
the
ones
who
want
to
learn
it.
A
We
actually
do
office
hours,
we're
doing
specific
training
for
them
to
kind
of
get
them
moved
over
the
hump
and
that's
good
the
developers
like
that,
because
then
they
feel
like
the
documentation.
Writing
is
coming
more
in
line
with
the
way
they
want
to
manage
their
Docs
and
it's
easier
for
them
to
contribute,
and
so
it's
kind
of
a
virtuous
cycle.
A
Oh
great
I'll
write
it
then,
which
is
great
when
you
can
get
the
actual
engineers
to
feel
like
they
are
empowered
and
make
time
to
to
document
it,
and
so
that
is
something
that
we
are
seeing
more
and
more
of,
and
it
really
makes
the
quality
of
the
information
better
and
it
makes
both
sides
really
happy
because
it
just
speeds
everything
up.
The
other
thing
is
that
we've
seen
with
the
writers
and
certain
teams,
some
teams
may
really
want
continuous
deployment
where
they're
making
changes
and
it's
going
and
it's
getting
deployed
actually
live.
A
There
are
other
teams,
you
want
more
sort
of,
they
want
to
have
an
approval
workflow,
they
want
to
say,
we've
we've
delivered
it
to
this
point,
but
we
want
to
be
able
to
approve
it
before
it
goes
out
and
the
rest
of
the
company
sees
it
or
whatever.
So
we,
those
are
two
different
cases
and
we
found
we
really
need
to
solve
for
both
and
and
then
the
other
one
is
that
the
developers
really
want
to
push.
A
Ok,
and
then
some
thoughts
that
we
are
taking
away
kind
of
into
the
next
step
of
it,
because
we're
continuing
to
involve
this
and
continuing
to
grow
it.
So
one
is
we
found
you
need
good
docs
for
your
doc
tool.
It's
kind
of
obvious,
but
it's
definitely
something
to
think
about
and
seems
a
little
bit.
You
know
it
may
not
be
as
obvious
as
it
should
be.
A
Then
we
found
that
you
should
really
like
having
it
and
having
the
work
flow
around.
It
is
really
great
and
gives
you
tons
of
benefit
and
that
you
should
use
get
for
its
strength,
don't
be
careful
not
to
build
something
and
duplicate,
something
that
you
can
just
get
through
the
native
get
functionality.
A
If
you
had
open
source
community,
writing
Doc's
we're
just
trying
to
do
that
internally
and
and
pull
people
in
from
different
organizations
even
like
sales
engineers
and
people
like
that
who
may
have
really
good
feedback.
They
want
to
add,
but
also
putting
some
process
around
that.
So
they
know
what
to
do
they're
comfortable.
A
They
know
they're
doing
what
they
should
be
doing:
the
internal,
the
external
path
taking
the
docs
and
making
it
so
that
you're,
when
you
are
starting
to
build
your
micro
service,
whether
you
know,
if
it
might
ever
be
externally
exposed
or
not,
if
you
start
off
in
the
right
way,
with
a
good
API
reference
and
good
Doc's
having
that
path
to
external
is
easier,
but
it's
still
bumpy.
So
there's
still
a
lot
of
work
to
do
there.
I
think
and
I
think
that's
a
place
where
there's
still
improvement
we
had.
A
A
So
it's
becoming
very
important,
and
one
of
the
other
things
is
this
kind
of
project.
How
do
you
measure
the
impact
of
this
kind
of
project?
You
could
use
developer
community
metrics
that
you
might
use
for
an
external
developer.
You
could
use
those
kind
of
internally
to
say:
is
this
API
getting
adopted
by
other
groups?
What's
the
usage
that's
happening?
Does
after
we
did
better
documentation
internally?
Did
we
get
better
usage
of
it?
A
Okay.
So,
if
you're
interested
in
all
this
there's
a
couple
of
things
that
I
will
recommend
one
of
our
definite
team
members,
her
name
is
Anne
gentle.
She
wrote
a
new
book
called
Docs
like
code,
and
it
spends
a
lot
of
time
kind
of
just
around
this
idea
of
treating
Docs
like
code.
Why
would
you
start
doing
that?
How
would
you
start
doing
it
there's?
A
What
are
some
of
the
hurdles
from
the
technical
writer
perspective
to
starting
to
treat
Docs
like
code
and
and
then
she
has
a
site
called
just
right-click
comm,
where
she
blogs
about
these
kinds
of
topics?
You
can
actually
read
a
blog
there
about
this
pub
hub
project
that
she
did
recently.
That
has
a
lot
of
the
same
information
you
heard
today
and
some
more
detail
so
definitely
recommend
checking
that
out
and
then
developer
dot,
cisco
comm.
You
can
join
our
community.
You
can
find
me
there.
A
You
just
reserve
your
space
and
and
start
at
it,
and
we
have
learning
labs
and
tutorials
and
sample
code
and
all
kinds
of
Doc's
to
help
you
get
started
so
check
it
out,
and
you
can
find
me
on
twitter
at
mandy,
Whaley
and
Cisco
dev
net
is
my
organization
and
we'd
love
to
hear
from
you
and
we
have
a
booth
down
on
the
floor
with
a
bunch
of
Cisco
experts
in
it.
Talking
about
container
networking
cloud
and
multi
cloud
type
topics
so
come
find
us
and
I
hope
you
have
a
great
conference
thanks.
A
C
A
Yeah,
that's
a
good
question,
and
so
we
I
we
right
now.
I'd
say
it's
happening
in
terms
of
like
how
you
structure
the
sets
of
Docs.
If
it's
something
we
know
is
common,
we'll
put
it
into
a
repo,
that's
got
common
information
and
then
we
can
add
everyone
into
that
and
that's
one
of
our
bigger
challenges.
I
think
honestly,
is
like
how
do
we
want
to
to
handle
that?
Honestly?
We
don't
have
a
ton
of
those
right
now
in
ours.
We
have
some,
but
it's
definitely
a
but
something
to
think
about.
I.
A
B
A
A
that's
a
documentation,
only
repo,
and
then
you
can
add
into
that.
You
know
anything
any
of
those
formats
that
you
want
and
so
that
you
would,
you
would
have
pages
in
there.
That
would
be
from
your
swagger
or
your
Ramlal
or
your
markdown,
and
then
we
have
people
who
use
different
automation
to
take
things
if
they're
generating
it
from
their
code.
You
know,
take
it
from
there,
send
it
to
that
repo
and
then
it
pushes
it
into
the
docks.
B
D
A
We
have
we
were
actually
just
so
Fabio
is
one
of
the
architects
and
developers
on
this
project
and
we're
actually
just
meeting
about
some
of
that
yesterday
and
talking
about
how
you
could
track
sort
of
Aging
content.
The
linting
like
some
of
those
different
quality
metrics
that
could
be
brought
in
so
I
think
it's
definitely
needed
and
it's
been
on
our
horizon,
but
we
haven't
gotten
there
quite
yet
we'd
love
to
hear
more
your
ideas,
yeah.
C
A
The
the
the
tool
itself
that
the
public
tool
has
a
really
nice
local,
previewer
and
web
previewer
that
you
can
use.
So
that's
very
good
for
the
I'm
working
and
I
just
want
to
see
it
I
want
to
see
what
I've
written
and
make
sure
it's
looking
right
and
all
of
that,
and
then
there
is
a
when
you
get
to
a
certain
point.
The
person
can
request,
or
they
can
do
it
automated
as
well
to
say,
send
to
staging.
A
We
have
a
staging
environment
and
send
to
fraud
so
yeah,
but
it's
but
it
when
the
the
individual
teams
are
working
on
the
docks.
They
can
see
a
very,
very
like
true
and
exact
rendering
of
it
in
that
previewer
and
there's
even
there's
also
like
a
mobile
previewer,
and
they
can
see
their
response
and
pieces
of
it
and
all
that.
C
A
A
E
A
So
I
I
can
give
you
my
view
on
it.
I
think
there's
a
lot
of
different
views,
but
I
think
one
way
to
think
about.
It
is
if
it's
information
that
the
team
is
using
to
to
to
build
the
service
right,
like
they're
your
design
documents,
your
architecture,
documents,
the
things
that
your
engineers
are
using
to
build
and
you're
getting
information
there,
that's
great
for,
like
your
team,
wiki
and
sort
of
internal
working
documentation.
A
If
you're
getting
to
the
point
where
you're
saying
this
is
an
API
that
someone
outside
of
our
actual
group
can
use
I,
think
that's
where
you
need
to
have
like
swagger
and
a
real
reference
and
some
more
documentation.
That's
a
little
bit.
Has
that
different
hat
on,
instead
of
being
like
someone
who's
in
the
actual
working
group.
Does
that
make
sense,
and
that's
kind
of
where
you
can
draw
the
line?
A
You
can
do
all
that
documentation
in
a
wiki,
but
a
lot
of
wiki's
don't
handle
some
of
the
file
types
as
well
and-
and
it's
I
think
it's
actually
I-
think
there's
actually
value
in
saying
these
are
the
documents
for
our
external
to
the
development
team.
Another
development
team
who's
going
to
consume
our
service
like
having
a
process
to
get
there.
F
F
A
Depending
on
the
like
scale
of
the
organization
and
who's
using
internally,
you
may
not
want
it.
You,
like
all
of
your
internal
chatter.
That's
in
the
comments
may
not
be
useful
to
someone
in
another
group,
but
it
might
be
so
that's
a
choice
that
you
can.
You
can
make
yeah.
Have
you
do
you
have
a
specific
thought
on
it?
Are
you
just.
A
A
Yeah
I
mean
yeah
I,
think
it's
you
get
to
a
point
of
an
API.
It's
back
to
like
an
API
is
a
contract
and
even
for
your
internal
devs,
an
API
is
a
contract,
and
at
what
point
do
you
put
that
at
stake
in
the
ground
and
say
this?
Is
this?
Is
this
until
we
until
we
change
it
and
and
that
may
change
during
the
maturity
of
your
project
right,
you
may
get
to
different
points.