►
From YouTube: Minimise friction in the API lifecycle to maximize fun (coding time!) - London Meetup ft. Quadcorps
Description
🚀 Tech Talk: Minimise friction in the API lifecycle to maximize fun (coding time!)
Following best practise when building APIs shouldn’t be so hard. It’s not fair to always be reading documentation (where it exists) and changing the way you work, or going through multiple rounds of manual approval before your work can go live. We’re now operating at a painful level of scale and complexity with microservices, service mesh, and hybrid deployment environments and the demands on us are greater than ever.
Being efficient and productive, and producing consistent, consumable APIs is not about reducing the complexity, it’s about embracing it through automation, declarative configuration, and APIOps.
😎 Speakers
🙋♀️ Melissa van der Hecht is Field CTO, EMEA at Kong, and her passion is inspiring business change through APIs. Melissa knows the API and microservices space well, having also spent five years at MuleSoft in the Office of the CTO and Solution Consulting teams, and has helped several multinational organisations create and implement their API strategy. She holds an M.Eng in Mathematics and Computer Science from Bristol University in the UK.
🙋♂️ Jeyaram Deivachandran is a Director and Engagement Lead at QuadCorps, a boutique Integration consultancy and valued Kong Partner. Having spent over 10+ years in the integration space at Tibco, MuleSoft and most recently as Head of APIs, Cloud Native and Microservices for Capgemini FS - Digital. Jey has helped organisations across multiple sectors strategise, architect, implement and execute complex integration programmes. He is passionate about enriching the community with the hard-won lesson's learnt and holds an MSc in IT for Business Management from Kingston Business School and BSc (Hons) in Software Engineering from Kinston University.
B
D
D
Thank
you
for
those
I
see
them
already
so
helps
us
be
a
little
bit
more
interactive
right
and
then,
let's
see
raffle,
so
yes
melissa,
you
can
go
to
that
next
slide.
We
are
having
a
raffle
today
for
all
of
you
who
are
attending.
We
appreciate
you
being
here
and
we
have
a
cool
raffle
prize,
which
is
a
set
of
raspberry
pies
and
all
of
the
fixins
to
build
your
own
kubernetes
cluster.
D
C
A
C
C
E
Sure
hi
everybody
I'm
so
excited
for
this
meet-up
wish.
We
were
in
person
that
being
virtual
means.
I'm
sat
here
in
my
slippers.
Not
gonna
lie.
I
am
melissa
vanderheck.
I
am
field
cto
of
emea
at
kong.
I've
been
here
for
a
couple
of
years
and
I've
been
in
the
api
and
integration
space
for
over
seven
years.
So
this
is
a
subject
that
I'm
very
passionate
about
jay.
You.
A
E
Thanks
jay,
the
the
topic
of
today's
meetup
is
how
we
can
become
more
efficient,
more
productive,
enjoy
ourselves
more
when
we
are
building
apis
when
we
are
deploying
apis
managing
apis
and
following
the
api
lifecycle
for
those
of
us
that
have
been
in
this
space
for
quite
a
while.
I'm
sure
we've
seen
the
introduction
of
different
types
of
roles,
culture
change,
people
talking
about
evangelism
design,
first
approaches,
there's
been
an
increasing
focus
on
how
we
need
to
organize
ourselves
as
api
stakeholders
in
order
to
maximize
the
productivity
that
we
have
in
the
api
lifecycle.
E
There
we
go
love,
google,
slides,
so
the
first
approach
that
that
I
saw
and
that
most
of
us
saw
in
the
industry
when
companies
first
adopted
apis
was
to
invest
in
a
global
api
management
platform.
Company
said:
oh,
you
know
we
want
to
achieve
operational
efficiency
and
business
agility
by
enabling
people
to
reuse
apis.
E
So
we'll
put
this
platform
in
place
that
everybody
has
access
to
and
say
right
set
your
apis
in
there
secure
them
using
the
policies
in
there
that
are
out
of
the
box
and
stick
them
in
a
portal
so
that
they're
discoverable
and
at
first
that
sounds
great
right.
You've
got
discoverability,
you've
got
security,
but
what
we're
doing
here
is
a
rather
siloed
approach.
E
We
never
invested
in
the
very
early
days.
We
didn't
really
understand
to
be
honest.
What
api
best
practices
were,
what
it
meant
to
treat
an
api
as
a
product
how
to
enable
different
stakeholders
in
the
organization
to
do
apis
in
the
right
way.
So
what
we
ended
up
doing
was
to
build,
deploy
and
publish
apis
very
rapidly,
but
build
a
big
mess
of
inconsistency
and
a
lack
of
standards
just
as
rapidly,
because
each
of
the
different
engineering
teams
that
was
using
or
producing
or
consuming
apis
thought
about
them
differently.
E
Some
teams
would
have
their
own
standards.
Some
teams
would
understand
api
best
practices,
others
wouldn't
so
you
would
end
up
with
a
complete
mix
of
differing
qualities
of
your
apis
in
a
platform
and
when
you
think
about
the
goals
of
api
adoption
of
reuse,
of
enabling
people
to
adopt
a
discovery-led
mindset
to
consume
apis,
rather
than
build
them
from
scratch.
E
So
then
jay
submits
his
apis.
To
me
I
manually
go
through,
and
I
say:
oh,
this
spec
doesn't
comply
hey
this
linting,
it's
failed
from
linting
or
this
this
api
already
exists.
Why
are
you
building
it
again?
So
I
would
do
all
these
manual
reviews
I'd
push
back
on
jay
and
say
jay
you're
rubbish.
Do
it
again,
not
good
enough?
E
This
is
when
I
mean
it
was
a
daily
conversation
for
me.
A
few
years
ago,
culture
change
design.
First
mindset.
We
did
hackathons
lunch
and
learns
all
these
kinds
of
activities.
I'm
sure
that
many
of
you
have
done
and
don't
get
me
wrong.
These
are
all
still
very
valid
and
very
necessary
activities,
but
these
activities
are
basically
very
high
touch
ways
of
me.
E
Investing
my
time
of
jay
investing
his
time
and
me
saying
here
is
some
written
documentation,
jay
go
read
it
and
manually
change
the
way
that
you're
working
so
that
you
comply
with
what
I'm
telling
you
to
do,
but
because
we
put
it
under
the
badge
of
evangelism,
we
kind
of
think.
Oh
hey,
that's
you
know
it's
good
enough,
but
we
are
finding
as
api
adoption
is
increasing,
as
our
environments
are
becoming
increasingly
decentralized,
as
we
have
more
and
more
and
more
teams
adopting
and
building
apis
in
some
way.
E
This
approach
just
doesn't
scale
anymore.
So
we
see
that
yes,
this
time
around
with
our
centralized
approach,
because
I'm
the
manual
gatekeeper
and
I
check
everything
for
standards,
everything
that
ends
up
being
deployed
follows
standards,
but
we've
ground
to
a
halt.
We've
put
in
roadblocks,
we've
put
in
manual
checkpoints
and
we've
created,
friction
and
that
reduces
productivity
and,
frankly,
that
makes
all
of
us
pretty
miserable
taryn.
I
would
love
it
please
if
we
could
launch
the
first
poll
when
it
comes
to
delivering
and
deploying
apis.
I
am
wondering
those
of
you
here.
E
Are
you
finding
yourselves
having
to
sacrifice
quality
because
you're
having
to
move
so
fast?
Are
you
moving
very
slowly
because
you
do
have
rigorous
checkpoints?
Maybe
it's
more
of
a
regulated
organization
you're
in
or
are
you
figuring
out
a
way
to
actually
deliver
with
both
speed
and
quality
across
all
of
your
apis?
I'm
seeing
quite
a
few
results
coming
now.
This
is
very
interesting.
A
E
It
wonderful
so
this
is
really
interesting.
We're
seeing
just
over
half
of
you
are
having
to
sacrifice
quality
because
you're
deploying
quickly,
not
very
many
of
you-
are
delivering
slowly
and
I'm
so
happy
that
a
good
number
of
you,
not
quite
half,
but
a
good
number
of
you
are
delivering
with
both
speed
and
quality.
E
I
have
run
this
poll
many
times
over
several
months.
I
I
think
across,
like
several
hundred
respondents.
Now
I've
seen
a
very
consistent
result
and
that
is
typically
only
20
of
attendees
are
able
to
deliver
with
both
speed
and
quality.
I
am
seeing
on
the
whole
about
80
of
the
people
that
we
speak
with
at
kong,
are
struggling
and
having
to
trade
off
between
speed
and
quality.
E
E
This
is
providing
stakeholders
with
self-serve
tooling,
so
that
it
just
becomes
easier
to
get
through
these
hurdles
of
making
sure
we
follow
best
practice
and
therefore
we
can
actually
focus
on
the
fun
part,
the
difficult
part,
the
part
that
requires
the
problem,
solving
building
the
apis
working
out.
What
is
it
that
consumers
actually
need
without
having
to
spend
ages
dealing
with
the
fafsa
of
best
practice?
E
So,
let's
walk
through
bit
by
bit
what
the
api
life
cycle
looks
like
with
api
ops,
I'm
not
going
to
explain
what
the
api
life
cycle
is.
I'm
sure
that
most
people
are
familiar
with
it
and
there's
loads
of
easy
stuff
on
the
internet.
If
you'd
like
to
read
more
about
it,
but
with
api
ops,
the
steps
in
the
life
cycle
are
the
same.
What
is
different
are
the
processes
that
we
follow
at
each
step
and
in
between
each
step
so
at
design
time.
This
is
where
best
practice.
E
We
follow
a
design
first
approach
and
we
want
to
use
swagger
or
open
api
to
describe
what
our
api
needs
to
do.
We
should
also
write
tests
for
that
api
so
that
we
can
ensure
that
whatever
is
built
checks
against
those
endpoints,
I'm
going
to
go
away
from
google
slides
now
and
we're
going
to
get
stuck
into
the
technology.
Let
me
show
you
insomnia.
E
Insomnia
is
an
open
source,
api
design,
environment.
You
can
go
to
insomnia.rest
to
download
it.
Insomnia
is
part
of
kong
and
part
of
com
connect.
So
we
have
integration
with
insomnia
across
all
of
the
different
com
components
within
insomnia.
You
can
see
I've
opened
up
the
specification
for
one
api.
This
is
the
open
api
pet
store
1.0.2.
E
This
is
the
default
swagger
or
oas
example.
Api
on
the
left
hand,
side
in
insomnia.
We've
got
a
few
different
options
that
help
me
to
explore
this
api
that
I'm
building.
For
example,
it'll.
Give
me
a
summary
of
the
information
of
the
api
that
I've
embedded
within
the
swagger
it'll
show
me
the
different
servers
that
I've
set
up.
This
is
a
very
useful
one.
This
is
a
fairly
long
spec,
so
this
is
showing
me
a
breakdown
of
all
the
different
methods
on
each
of
the
different
parts
that
I'm
creating
on
the
right
hand,
side.
E
This
is
a
dynamic
explorer
for
this
spec.
As
soon
as
I
make
changes
within
the
swagger,
this
explorer
will
change.
So
this
gives
me
an
interactive
way
to
understand
what
this
api
will
do.
Generally,
that's
a
lot
easier
than
actually
reading
through
the
swagger
and
therefore
translating
that
into
api
functionality
in
your
mind-
and
you
can
also
expand
out
different
requests
in
here-
have
a
look
at
the
example
schemas
and
start
to
try
some
of
them
out.
E
E
At
the
moment
you
can
see
everything
is
being
rendered.
There's
nice
colors,
I'm
not
seeing
any
errors,
so
this
linting
is
always
happening
and
the
linting
is
currently
passing,
but
I
can
type
in
a
whole
load
of
rubbish
and
you
will
see
suddenly
things
have
just
broken.
This
is
the
linting.
This
is
telling
me
that
what
I
am
doing
is
correct
or
incorrect
and
at
design
time
I
can
make
sure
immediately
that
I
don't
actually
move
on
to
the
next
phase
of
the
life
cycle
until
I
fixed
all
of
these
errors.
E
E
E
Perhaps
you
want
to
apply
a
mocking
plug-in,
perhaps
there's
various
types
of
security
plug-ins
that
you
know
you're
going
to
have
to
be
applied,
so
you
specify
them
here
what
we
can
do
when
we've
created
our
spec
insomnia
has
a
debug
mode.
This
means
we
can
make
requests
to
the
api.
We
support
not
just
rest
but
graphql
and
grpc
here,
and
we
can
make
tests
for
our
api.
We
can
create
whole
suites
for
our
api.
E
We
can
construct
our
tests
through
this
nice
gui
select,
whatever
request,
we
want
to
make
a
test
against
and
then
change
the
the
code
that
we've
got
in
here
then,
once
we've
written
our
tests
once
we're
satisfied
that
our
api
meets
best
practice,
I
have
I'm
going
to
move
my
zoom
there
we
go.
I
can
commit
this
into
my
git
repo,
put
a
commit
message
and
I
can
push
this
into
git
and
I
can
do
all
of
this
without
having
left
the
insomnia
environment.
E
So
let
me
go
back
and
talk
through
what
happens
next
and
then
I'm
going
to
hand
over
to
jay.
So
before
we
get
on
to
the
build
phase.
We
don't
necessarily
know
that
this
api
meets
all
of
the
best
practices
that
the
organization
has
specified.
Maybe
jay
has
actually
just
been
creating
this
api
in
insomnia.
E
I
sit
within
a
centralized
platform
team
and
I
haven't
seen
that
he's
passed
all
of
these
checks
within
the
ide,
because
it's
all
on
his
computer.
I
want
a
programmatic
way
to
ensure
that
every
single
api
that
he
submits
to
me
that
chris
submits
to
me
that
taryn
submits
to
me
that
every
team
submits
to
me.
I
want
a
programmatic
way
to
ensure
that
everything
is
checked
for
best
practice.
So
I
have
this
automated
governance
checkpoint
in
my
pipeline.
A
Thanks
melissa,
I've
got
to
say
I've.
I've
been
in
many
many
of
those
review
sessions,
as
both
you
know,
as
a
as
a
developer,
if
you
like,
as
well
as
an
architect,
reviewing
the
spec,
and
you
know
I
find
them
time
consuming
when
I
was
a
developer.
What
I
wanted
to
do
was,
you
know,
spend
time
more
time,
kind
of
building
the
api
etc.
So
you
know
any
time
where
you
can
automate
it
and
get
essentially
instant
feedback
on
you
know
it's
a
plus
one
from
me.
A
If
you
like
right
so,
hopefully
people
can
see
my
screen.
I
just
want
to
give
a
little
bit
of
context
before
I
kind
of
do
the
demo,
so
we
we
are
essentially
in
a
kubernetes
environment.
You
know
we're
using
a
a
d2
iq
cluster
to
run
the
demo.
You
know,
and
we've
got
kong
deployed
essentially
as
an
ingress
resource
in
kubernetes,
so
it's
acting
as
an
ingress
point
as
well
as
a
gateway
kind
of
simplifying.
A
A
A
One
of
the
first
things,
you'll
notice,
is
that
we
are
we're
doing
the
linting
that
we
we've
talked
about.
The
linting
is
is
kind
of
out
of
the
box
and
there
are,
you
know,
there's
actually
about
158
different
checks
that
that
are
happening
as
part
of
this.
I
just
want
to
walk
through
a
few
examples
here,
so
you
know
you
can
see.
There's
22
warnings
that
have
been
picked
up.
A
lot
of
these
are
around
operations,
not
having
a
200
response.
A
So
you
know
that's
a
fairly
simple
check.
You
know
where
you're
checking
is
there
a
200
response
and
if
there's
a
200
response,
you
know
you
know
that's
a
successful
operation.
If
there
isn't
a
200
response,
then
you
have
to
think
about
well.
What
is
this
operation
doing
so
this
is.
This
is
really
a
good
mechanism
for
doing
that.
A
I'm
not
I'm
not
going
to
spend
too
long
on
walking
through.
You
know
each
of
the
the
rules,
but
you
could.
You
can
see
a
good
number
of
rules
here
and
you
can
see
what
a
good
example
and
a
bad
example
of
some
of
these
are,
as
you
can
tell,
there's,
there's
quite
a
number
of
rules
that
are
being
run
in
an
automated
fashion.
A
I
find
this
really
useful
because
I
don't
have
to
wait
around
for
somebody
to
review
this
and
kind
of
you
know,
especially
when
you're
kind
of
mid-sprint
and
you're
trying
to
rush
through
right
at
the
end,
all
the
reviews
etc.
It
can
be
quite
a
intense
experience
so
having
this
means
that
you
get
instant
feedback
and
you
can
kind
of
spend
more
time
doing
doing
the
api
development
and
getting
that
right.
So
that's
an
interesting.
A
E
E
So
we've
automated
governance,
checkpoints
that
jay
just
showed
us
all
of
the
linting
capabilities
that
we
get
in
insomnia.
We
get
in
a
cli
around
insomnia,
that's
called
info.
You
can
also
download
that
from
insomnia.rest
it's
open
source
and
this
means
through
inso
through
the
spectral
linting.
That
jay
also
showed
us.
You
can
programmatically
invoke
lots
of
checking
of
that
spec.
If
anything
fails,
it
can
be
immediately
rejected.
E
If
we're
doing
this
through
git,
for
example,
you
can
say:
oh
I've
got
a
new
spec
to
submit
I'm
creating
a
pull
request,
a
pr
and
as
part
of
that
creation
of
the
pull
request
you
can
have
these
tests
automatically
executed
and
if
any
of
those
tests
fail,
you
can
push
straight
back
to
the
person
creating
the
swagger
and
say
no.
This
bit
needs
to
change.
It's
not
complying
with
best
practice
from
a
platform
team
point
of
view,
there's
no
manual
involvement.
E
We
are
saving
a
huge
amount
of
time
not
having
to
do
these
manual
checks
and,
from
jay's
point
of
view,
designing
the
spec.
He
gets
instant
feedback
and
he
gets
this
automated
feedback.
So
it's
a
lot
easier
to
actually
ensure
that
you're
doing
the
right
thing
at
design
time
before
you
move
on
to
build
and
then
ultimately,
if
you
click
again
jay,
please
ultimately
you'll
pass
the
automated
governance.
E
E
We
want
to
build
this
in
whatever
tool,
whatever
language,
whatever
platform
is
best
for
the
use
case,
maybe
that's
custom
code,
maybe
that's
java
or
net.
Maybe
it's
no
js.
Maybe
it's
an
integration
platform
or
an
ipad
doesn't
matter
within
kong.
We
support
all
of
them,
but
you
need
to
be
able
to
build
your
api
based
on
what's
in
that
spec
and
then
the
tests
that
we
created
at
design
time
they're,
actually
our
unit
tests.
E
A
A
You
know,
if
there's
a
regression
test,
I
might
not
run
through
all
the
regression
pack.
I
might
just
test
the
few
things
that
I've
changed
commit
my
code
and
then
I
know
this
pipeline
is
going
to
run
the
regression
pack
which
may
contain
you
know
a
more
a
significant
number
of
tests
and
again
we
are
essentially
using
inso
and
inso
is
the
cli
version
of
insomnia
and
just
to
show
an
example
with
an
insomnia
here.
A
You
know
these
are
some
of
the
tests
that
militia
showed
us
earlier
and
they
are
built
at
the
same
time
as
we're
designing
the
spec.
So
again,
you
can
kind
of
take
some
of
the
test.
Driven
development
philosophies
here
so
at
design
time
you're,
building
the
tests
and
you're
then
building
the
api
to
pass
these
tests.
So
this
is.
This
is
really
a
a
good
mechanism
to
do
that.
Again,
if
you
wanted
to
run
different
tests
kind
of
ad
hoc,
you
could
also
do
this.
A
I
know
a
lot
of
people
use
things
like
postman,
etc,
or
even
things
like
j
meter
to
do
do
some
of
these
tests.
So
again,
this
is
kind
of
all
built
in
into
a
single
environment
and
it's
kind
of
version
control
built
in,
and
so
it
makes
that
really
simple
to
do.
If
you
like,
so
you
can
see
I'm
getting
responses
back
200
you
can
see
some
of
the
headers
are
coming
back.
A
You
can
see
that
rate
limiting
has
been
applied
and
you
know
I've
got
if
I
go
back
to
the
design
specification
here.
At
the
end,
I've
actually
applied
two
separate
plugins.
One
is
a
rate
limiting
plug-in
with
you
know,
1000,
requests
per
minute
and
also
course
plugin.
So
we
can
have
requests
coming
from
many
different
domains,
not
just
the
domain
that's
deployed
on
and
what
what
we're
essentially
doing
in
in
the
pipeline
is
running
these
unit
tests
through
a
cli
in
an
automated
fashion
and
these
steps
here.
A
The
thing
to
mention
about
these
steps
is
that
I've
seen
so
many
different
variations
of
automated
pipelines
right.
The
key
thing
is
that
about
these
pipelines
is
that
they
should
follow,
get
ups
philosophies
and
they
should
follow
kind
of
devops
philosophies
as
long
as
you're
kind
of
following
those
two
philosophies.
A
There's
a
lot
of
variations
in
the
pipeline
and
how
that's
going
to
happen
so
essentially,
what
we're
doing
is
we're
kind
of
deploying
into
an
environment
where
it's
purely
just
for
automated
tests,
we're
deploying
and
we're
we're,
then
kind
of
testing
it
before
we
move
in
and
deploy
into
a
real
environment.
If
you
like,
I
am
going
to
cover
more
of
how
we
do
the
deployments
etc.
A
I'm
actually
so
let
me
quickly
go
through
that,
so
that
we're
doing
a
number
of
different
things
here
in
terms
of
build.
What
we've
done
is
we've
we're
essentially
building
a
stub
if
you
like,
so
we've,
we've
built
a
stub
in
in
spring
boot,
and
so
you
can
see
the
maven
command
here
where,
when
it
loads
up,
where
we're
doing
that
build.
A
A
A
E
E
E
E
Declarative
is
ignoring
all
of
those
steps
and
just
saying
what
outcome
you
want
and
the
technology
that
you're
deploying
to
takes
care
of
the
steps
in
order
to
get
there.
So
in
the
context
of
deployments,
for
example,
if
we
were
to
deploy
to
kong
imperatively,
you
would
write
a
script
that
says:
call
this
admin
api.
Get
this
token
use
the
token
to
make
a
call
to
this
api
apply
the
plugin
configuration
using
this
api
call,
and
thus
you
would
continue.
This
is
great
you've
written
a
script.
You
can
therefore
automate
it.
E
The
admin
api
changes
you've
got
to
update
your
script.
If
you're,
trying
to
troubleshoot
you've
got
a
longer
script
to
try
and
step
through
to
figure
out
where
the
problem
is.
Compare
that
to
declarative,
we
would
just
say:
hey
com
gateway.
This
is
what
you
need
to
look
like
after
this
api
has
been
deployed,
including
the
configuration
of
all
these
plugins,
like
the
rate
limiting
plugin,
you
don't
have
to
specify
calling
the
admin
api
getting
any
of
the
authentication
tokens.
It
just
takes
care
of
that
for
you.
So
one
more
slide,
please.
E
A
So
I
can
certainly
believe
that
one
percent
claim,
if
you
like
in
terms
of
the
cost,
so
I
do
think
that's
you
know
that's
kind
of
important
and
anybody
who's
been
in
a
p1
or
s1
situation
can
can
kind
of
understand
how
much
a
a
simple
bug
or
a
you
know.
A
change.
That's
gone
wrong
can
really
hurt.
So
that's
that's!
That's
key!
A
So
in
terms
of
where
we
are
in
with
our
face
before
I
kind
of
go
into
the
deploy
and
what's
happening
there,
what
I
want
to
do
is
just
show
you
in
insomnia
and
the
ui
tool,
and
you
could
do
this
through
the
inso
cli
as
well.
You
can
generate
declarative
conflict
for
you
know
for
for
the
swagger
spec
that
you've
you've
built
and
what
this
allows
you
to
do
is
configure
the
gateway
with
the
different
rules
and
the
and
the
different
services
that
you
need
as
well
as
the
plug-ins.
A
You
need
to
essentially
proxy
and
manage
that
api,
so
going
straight
from
the
swagger
spec,
you
can
then
have
a
configuration
that
you
can
apply,
and
earlier
I
mentioned
that
we're
kind
of
in
kubernetes
world
so
again,
insole
and
insomnia
allow
you
to
generate
kubernetes
crds.
So
here
you
can
see
ingress
definitions
being
created.
You
could
also
see
what
plugins
are
being
generated
and
applied
in
kubernetes,
and
this
is
really
important
because
once
you've
applied
these
crds
to
kubernetes,
then
this
kubernetes
api
server.
A
A
This
is
really
key
in
terms
of
moving
to
a
declarative,
config
and
what
what
people
tend
to
do
is
either
generate
this
on
the
fly
from
the
swagger
specification
and
apply
that
or
if
people
want
to
make
any
kind
of
additional
tweaks
or
additional
kubernetes
annotations,
and
then
they
generate
to
commit
this
into
git
and
then
use
this
as
the
as
the
manifest
to
do
the
deployment
so
going
from
design.
You
know
you're
able
to
kind
of
generate
kubernetes
as
well
as
kind
of
a
declarative
config
for
kong.
A
If
you're
deploying
kong
in
a
non-kubernetes
environment
or
if
you're,
using
in
the
kubernetes
environment,
then
kong
is
kind
of
very
cloud
native
and
it
works
within
the
kubernetes
ecosystem.
Just
using
you
know,
cube
crds
if
people
are
familiar
with
kubernetes
terminologies
there.
So
what
are
we
doing
in
the
deploy
phase?
A
So
we're
doing
a
number
of
things
so,
first
thing
that
that
we're
doing
is
actually
we're
deploying
the
image
into
a
performance
environment,
and
you
can
see
you
know
some
of
the
commands
for
docker
compose
to
build,
build
that
image.
What
we're
then
using
is
configuring
the
gateway?
Essentially,
so
you
can
see
that
we're
applying
the
different
plugins
we're,
also
configuring
the
ingress
details
and
again
this
is
all
kind
of
applied
through
cube,
ctl
commands,
etc.
A
A
You
know
we
we've
done
something
very
simple
here,
but
essentially,
if
you
wanted,
you
could
run
a
full
salt
test
overnight.
If
that's
something
you
know
your
environment
needed,
etc.
So
this
is.
This
is
interesting.
One
of
the
thick
key
things
about
k6
is
that
we
generated
all
of
these
tests
or
the
skeleton
for
the
test
from
the
swagger
file.
So
essentially
we
co-gen
the
these
set
of
tests
and
we
just
kind
of
put
in
parameters
to
say:
look
what
are
the
tps?
A
A
We
we've
even
got
a
warning
about
a
sql
injection
if
you
like,
and
that's
probably
because
the
the
rate
limiting
clicked
in
so
obviously
we
need
to
make
sure
there's
enough
scope,
in
the
rate
limiting
to
run
all
of
these
tests,
but
you
can
see
the
number
of
tests
that
have
been
run,
etc
and
again.
The
key
thing
that
we're
doing
here
is
essentially,
we
are
passing
in
the
swagger
specification
and
into
the
test.
A
A
But
you
know
I,
I
really
believe
doing
a
check
against
the
actual
implementation,
because,
even
though
your
dependencies
might
be
safe
and
there
are
no
kind
of
vulnerabilities
as
a
developer-
I
might
have
you
know-
unknowingly
introduced
and
it's
a
kind
of
security
vulnerabilities
or
actually
the
way.
The
api
has
been
secured
or
configuration
in
the
gateway
has
been
misconfigured,
etc,
etc.
There
are
a
number
of
things
that
might
lead
to
a
security
forum,
and
this
is
a
good
way
of
picking
this
up
and
again.
A
This
is
something
as
a
platform
team.
You
could
automate
and
say
must
be
part
of
every
pipeline
for
every
api,
so
this
is
for
me.
This
is
this
is
a
critical
part
before
you
really
publish
the
api
for
kind
of
vital
consumption
and
use.
So
I'm
gonna
pause
here
for
any
more
questions
before
I
kind
of
hang
back
to
melissa.
D
B
E
Thanks
there,
I
I'm
not
going
to
ask
anybody
to
put
their
hands
up
to
this,
but
I
have
seen
a
scarily
large
number
of
organizations
go
live
having
forgotten
to
secure
their
apis.
Now
this
is
absolutely
critical.
What
just
showed
us
we
do
not
want
to
make
our
apis
discoverable.
We
do
not
want
to
publish
them
until
we've
made
sure
that
we've
passed
all
of
those
security
checks,
so
all
of
our
api
authentication
has
been
applied.
E
That
performance
is
adequate
because
an
api
endpoint
that
we
expose,
whether
that's
internally
or
externally,
it
is
a
product
right.
We
will
suffer
reputational
damage
if
our
apis
don't
work
if
they're
not
reliable,
if
they're
not
secured,
if
they
don't
do
what
they
say,
they're
going
to
do
so
all
of
these
checks
are
making
sure
that
by
the
point
we
get
to
publishing
it,
they
are
consumable
jay.
If
you
skip
forward,
please
oh
you're
done
already
thanks.
So
when
it
comes
to
publishing,
we
have
to
make
sure
for
an
api
to
be
consumable.
E
E
A
But
we're
only
doing
that
once
we're
happy
that
all
of
these
other
checks,
you
know
we're
comfortable
with
those
and
and
they
have
passed,
and
what
we
can
then
do
is
essentially
promote
this
api
into
a
new
environment
and
make
that
available.
So
what
does
what
does
that
look
like?
So
I'm
going
to
show
you.
So
this
is
the
kong
portal,
and
this
is,
if
you
like,
the.
A
So
again,
this
makes
it
really
simple
to
make
your
apis
discoverable,
you
don't
have
to
go
in
and
manually,
publish
this
and
if
you've
got
additional
documentation,
you
can
document
that
as
marked
down
and
it
gets
automatically
pushed
into
a
portal
like
this,
which,
which
is
really
important.
What
I
also
want
to
show
you
is
kong
manager,
and
here
you
can
see
the
different
config
that
we've
we've
sort
of
applied.
A
A
We've
we've
got
the
plug-in
a
thousand
per
minute,
which
is
what
we've
configured
in
the
swagger
spec.
So
you
can
now
see
that
being
applied
in
the
cog
manager
ui,
and
you
could
also
see
those
being
applied
to
the
if
you
like
different
ingress
points
being
applied,
and
what
you
can
see
here
is
that
this
is
now
being
managed
by
a
ingress
controller.
A
A
E
E
The
automation
that
we
showed
you
so
part
so
far
also
supports
automated
operations.
For
example,
if
there
is,
if
you're
a
retailer
and
it's
black
friday,
you
are
going
to
need
to
scale
out
your
deployments.
Most
probably
you
don't
want
to
have
to
spend
ages
writing
a
whole
load
of
build
scripts.
You
want
to
instantly
be
alerted.
Oh
our.
Our
throughput
is
going
up.
Let's
automatically
deploy
new
instances
of
kong,
deploy
new
instances
of
this
api
and
scale
out
horizontally
the
declarative
configuration
file.
E
Maybe
you
want
to
change
some
of
the
plug-in
configuration
three.
I
think
you
asked
this
earlier
on
in
the
chat.
You
can
either
do
that
through
the
specification,
if
you
are
making
changes
in
the
spec
you're,
adding
a
new
resource
or
if
you're,
changing
plug-in
configuration
within
there
easy
to
do
you
change
it
in
the
spec,
you
generate
the
declarative,
config.
You
go
through
the
deployment
with
all
the
testing,
of
course
in
between
or
if
you
just
want
to
change
the
configuration
of
a
plugin.
E
A
Yeah,
absolutely
thanks
melissa
one.
What
I'll
also
say
in
terms
of
the
security
is,
if
you
so
choose
to
where
to
do
so,
you
could
add
that,
as
a
linting
step
to
say
you
know,
they
must
be
one
of
these
different
security
mechanisms.
You
know
whether
that's
kind
of
a
an
oidc
job
token
based
security
or
you
know,
opaque
tokens
or
any
other
mechanisms-
that's
kind
of
okay
by
your
security
team.
So
again,
this
pipeline
can
help
you
ensure
that
you
are
kind
of
meeting
those
security
requirements.
A
Essentially,
this
diagram
shows
you
kind
of
a
zoomed
out
view
of
the
pipeline
and
the
different
flows
that
are
happening
and
the
different
components
that
are
being
used
and
the
fact
that
you
know
some
of
the
testing
is
happening
in
different
environments
or
different
clusters.
So
we're
running
the
unit
tests
locally
within
the
ci
environment.
A
You
could
also
have
right
at
the
end,
you
could
promote
your
api
into
the
next
kind
of
staging
environment
or
you
know
uat
environment
to
do
those.
So
it's
it's
kind
of
an
interesting
setup
like
I
said,
I've
seen
many
many
different
variations
of
of
these
pipelines
and
as
long
as
you're
kind
of
following
the
get
ops
as
well
as
kind
of
the
devops
philosophies,
I
think
you
you
stand
in
good
standing
just
before
I
kind
of
hand
things
back
to
the
host.
A
What
I
also
wanted
to
do
very
quickly
was
just
answer.
Three's
question
a
little
bit,
so
this
is
kong's
kind
of
plug-in
hub
if
you
like,
and
you
can
see
the
different
mechanisms
available
to
secure
your
apis.
So
there's
you
know,
there's
a
lot
of
plugins
here,
everything
from
kind
of
basic
oauth
to
oidc,
which
you
know
open
id
connect,
and
that
tends
to
be
the
the
most
popular
mechanism
I
find
in
securing
your
apis
mtls
octa.
A
Also,
that's
a
really
good
question
yeah.
So
again,
that's
something
you
could
add
what
you'll
probably
need
to
think
about
is.
If
you've
got
different
programming
languages,
then
you'll
probably
need
a
variation
for
each
kind
of
programming
language.
So
if
you're
using
a
lot
of
node.js,
then
you
need
to
have
a
cold
coverage
checker
for
node.js
for
java,
etc.
So,
that's
again,
something
very
specific
to
I
think
the
environment
that
you're
working
in
and
the
tooling
that
you're
going
to
be
using.
A
B
A
I
know
so,
for
example,
you
can
use
something
like
check
marks
and
what
was
the
other
tool
in
java.
So
you
can
sonar
tube,
for
example.
So
you
can
use
those
types
of
components
to
get
code
coverage
code,
quality
tool
and-
and
if
you
know
you,
you
could
fail
the
test
if
you're
not
meeting
a
certain
threshold.
A
A
F
F
Sorry
very
interesting
to
find
out
this
one
jay
and
melissa
one
question
from
me:
jay
so
yeah
melissa
explained
about
the
auto
scaling
and
auto
that
capability.
Obviously,
that
is
that
is
supported
out
of
the
box
by
kubernetes
right.
So
what
about
the
monitoring
side,
because,
obviously,
when
you
build
and
deploy
that
doesn't
end
the
world
right,
so
it's
the
support
is
the
longer
period
of
time.
So
what
kind
of
monitoring
is
available
and
what
kind
of
support
functionalities
are
available
over.
A
Yeah
I
I
can.
I
can
take
that
answer
so
in
terms
of
actually
I'm
going
to
show
my
screen
again,
because
I
think
it's
easier
to
see
it
visually
in
terms
of
monitoring
what
we
tend
to
see
because,
again,
kong
being
kind
of
very
cloud
native
you
we
have
lots
of
plugins
where
we
can
do
node
exporting
to
prometheus
grafana
et
cetera.
You
can
see
datadog
zipkin
if
you
want
to
do
kind
of
distributed
tracing,
there's
things
plugins
to
inject
correlation
id,
etc.
D
Yes,
I
was
going
to
say
just
in
case
there's
someone
who
had
to
head
on
to
their
next
meeting
at
the
top
of
the
hour.
I
would
love
to
announce
a
raffle
winner,
and
this
is
where
our
build
your
own
kong
kubernetes
kubernetes.
Excuse
me,
I
guess
you
could
call
it
that
this
is
a
calm
meetup,
your
own
kubernetes
cluster,
with
raspberry
pi's.
So
jay,
would
you
do
many
honors
in
picking
a
number
between
1
and
36?
Please.
D
D
D
A
Yeah
before
we
go
into
the
next
questions,
I
think
because
we've
got
julian
on
the
call
with
d2iq.
Maybe
julian,
you
can
speak
a
little
bit
about
what
the
the
monitoring
capabilities
are
out
of
the
box
in
in
your
kubernetes
cluster,
because
I
think
that
might
help
kind
of
enrich
the
answer
for
harsha.
B
G
A
So
this
is
this
is
where
your
git
ops
philosophies
really
come
into
play
because
with
good
ops,
your
configuration
is
essentially
held
in
git,
so
they're
version
controlled.
You
might
have
different
branching
strategies
for
different
environments,
so
each
branch
is
a
environment
essentially
and
you
handle
that
through
pull
requests
so
before
it
goes
into
a
particular
environment.
And
if
you
want
to
change
the
config,
you
could
say
create
a
pull
request
and
once
the
pull
request
is
kind
of
merged
into
manifest.
That's
when
it's
deployed.
A
So
really
it's
it's
it's
down
to
that.
What
what
I
showed
you
here
is
kind
of
an
automated
promotion
where,
in
the
background
what's
happening,
is
tacton
is
essentially
pushing
to
docker
hub
and
flux
cd.
Is
you
know,
detecting
the
new
image
and
going
in
to
update
you,
know
the
manifest
and
get
to
to
promote
it,
and
so
essentially
we're
kind
of
automating
that
pull
request?
A
E
I
think
I've
got
a
bit
of
a
delay
between
my
audio
and
my
videos.
I'm
very
sorry
if
I
just
really
yeah,
I've
got
my
audio's
flaky
and
I've
got
a
delay.
So
I'm
sorry,
if
I'm
rudely
interrupting
everybody,
we
have
a
30-day
free
trial
of
the
entire
kong
platform
available.
I
will
put
that
a
link
to
it
in
the
chat.
We've
also
got
a
few
tutorials
that
you
can
follow
to
actually
set
up
an
api
ops
approach
through
github
actions.
E
E
If
there's
also,
you
can
contact
myself
contact
karen.
If
you
want
to
have
any
kind
of
deeper
dive
conversations,
we
can
pass
you
on
to
the
sales
team
if
you're
interested
in
evaluating
more
of
enterprise
or
there's
a
lot
of
the
open
source
community
and
resources
on
our
website
as
well,
so
I'll
share
a
whole
bunch,
a
bunch
of
links
in
a
second.
A
I
was
just
gonna:
do
a
quick
screen
share
as
well
to
kind
of
further
answer,
mike's
questions,
so
here
you
can
kind
of
see
the
commit
history
where
you
can
kind
of
see,
flux,
cd
block,
making
commit
changes
to
essentially
the
manifest
that
says,
deploy
this
version
of
of
the
api
implementation,
etc.
So
you
can
see
that
we've
kind
of
gone
from
version
6
to
version
7,
etc,
and
that's
kind
of
done
by
the
pipeline.
A
A
F
A
A
D
D
B
B
A
A
A
A
B
D
A
So
it
looks
like
people
are
very
much
interested
in
kubernetes,
cluster
and
cloud
native,
as
well
as
the
kong
api
portal.
So
I
think
you
know,
one
of
the
things
we
were
talking
about
internally
is
whether
we
should
do
a
focused
session
just
on
the
kubernetes
cluster
and
how
how
all
of
that
works
together.
A
I
think
kung
pothole
is
definitely
an
interesting
one
and
kong
ingress
resource
kind
of
fits
into
that
and
the
automated
performance
and
security
testing
yeah.
I
I
think
we
can.
We
can
do
something
about
the
kong
api,
pro
tour
and
the
kubernetes
cluster.
So
that's
good
to
know.
That's
what
people
are
interested
in.
B
Jay
one
question
from
my
side
would
be
like
you
showed
the
portal
where
the
plugins
are
all
been
shown
right.
You
show
the
portal
where
the
plugins
are
being
like,
for
example,
the
kafka
plugin
correct.
So
how
are
these
plugins
being
inbuilt
onto
a
clue,
go
on
to
your
id?
Do
we
have
an
id
or
something
like
where
the
developers
use
it?
Is
it
a
drag
and
drop
feature
or
something
like
that
or
is
it
based
on
the
id
you
link
it?
How
is
it
actually.
E
E
Firstly,
you
can
write
plugins
in
lua.
Kong
is
built
on
nginx
in
lua
and
lewijit,
and
this
is
one
reason
why
it
is
super
super
super
fast,
but
not
everybody
knows
lua
or
would
like
to
build
in
lua.
There
is
much
more
familiarity
with
go
and
with
javascript,
so
we
also
have
pdks
in
that
support.
Go
and
javascript.
E
We
do
not
have
a
graphical
drag-and-drop
way
of
building
these
plugins
we're
going
for
the
kind
of
the
almost
like
considering
the
kind
of
person
that's
building
the
plugin.
They
would
probably
find
it
easier
to
write
it
in
code
rather
than
through
a
drag
and
drop
interface,
because
this
is
writing
capabilities
that
you
want
to
push
into
the
api
gateway
to
add
custom
functionality
to
your
apis,
so
we're
making
sure
that
we
support
engineers
in
a
variety
of
languages
to
do
that.
I'll
share
a
link-
oh
michael
heath's,
already
done
it.
Thank
you,
michael.
A
Once
I
I'll
probably
add
once
you've
built
that
plug-in,
then
there's
a
number
of
ways
to
apply
it.
You
know
you
can
apply
that
through
the
admin
api
declarative
config
through
the
ui
manager,
you
know
through
automated
pipelines,
as
we've
just
seen,
so
it's
it's
kind
of
very
flexible
to
do
that,
and
I
guess
the
key
thing
is
because
it's
built
in
such
a
way
to
be
very
fast
that
just
by
you
adding
in
different
plugins,
you
don't
end
up
slowing
down
the
actual
instance.
A
So
it's
not
a
a
jvm
based
mechanism,
if
you
like,
so
that's
that's
what
keeps
it
lightweight
and
and
only
the
plug-ins
that
you
need
are
loaded
it
it
doesn't.
You
know
it's
not
like
in
java,
where
all
the
jaws
are
loaded,
etc.
It's
it's
it's
very
lightweight
from
that
sense.
So
it's
it's
built
for
speed
and
low
latency.
E
D
Seems
like
there
are
no
more
questions,
just
a
lot
of
praise
for
jay
and
melissa,
so
thank
you
so
much
to
to
jay
and
melissa
and
chris
and
for
quad
core
for
being
here.
We
appreciate
you
all
joining
we'll
help
you
we
hope
you
will
join
us
for
our
next
meetup.
We
have
not
a
clung
london,
specific
meetup,
but
a
larger
emea
virtual
meetup
happening
next
week
on
the
17th
that
melissa
is
presenting
at
as
well
featuring
conch.