►
Description
Building any good structure requires starting at the foundation, and architecting for engineering success is no different. Cargill’s Sr. Architecting Engineer, Jason Walker and Lead API Engineer, Colin Schaub discuss how to build a model for engineering success from the ground up. This Kong Summti 2019 session covers the goals for building a strong engineering culture, incorporating lean concepts into engineering processes, establishing core principles that empower decision making, generating self-service oriented delivery patterns, and more.
Learn more about Kong: https://konghq.com/
B
B
It's
allowed
alright,
so
everyone
thanks
for
thanks
for
attending
just
hip.
We've
got
a
few
slides
here
that
we're
going
to
go
through
and
talk
a
little
bit
about
some
of
the
things
that
we're
doing
at
Cargill,
as
well
as
just
in
general,
over
the
course
of
some
life
life
experience
and
working
in
IT
and
go
through
and
talk
about
the
building
up,
an
engineering
culture,
how
we
each
have
a
clicker.
So
it's
gonna
be
interesting
as
we
go
through
to
be
like
hey
now
it's
time
for
next
and
then
we
double
click.
B
B
A
B
Is
awesome
so
a
little
bit
about
Cargill,
we've
been
around
for
over
150
years,
I
think
we're
about
at
155
years.
We
know
that
we're
not
going
to
be
able
to
achieve
our
purpose
and
our
mission
around
helping
the
world
thrive
and
nourishing
the
world
without
the
use
of
technology.
We
have
a
lot
of
traditional
foundations
in
place.
B
So
one
of
the
things
around
building
this
engineering
culture-
you
know
we
we
had
some
conversations
early
on
with
some
folks
that
Kong
about
content
that
we
wanted
to
be
able
to
to
present
and
to
talk
about,
and
one
of
the
things
that
that
Mike,
one
of
the
people
that
we
work
with
at
Kong
said.
Hey,
you
know
be
great,
is
talk
a
little
bit
about
behind
the
scenes.
B
Well
Kohana.
This
is
just
a
quote
that
you
know
when
going
through
and
kind
of
thinking
about
the
theme,
the
weaker
the
desire
to
change
the
further
away
from
now
is
the
moment
from
which
we
plan
on
changing
and
one
of
the
things
at
a
company
like
Cargill
or
in
places.
Whether
you're,
just
steeped
in
the
in
legacy,
is
that
the
desire
to
change
is
sometimes
not
as
strong
as
what
you
feel
is.
B
That's
remember,
the
the
insurmountable
obstacles
or
object
objects
that
are
in
the
in
the
path,
and
so
one
of
the
things
when
we
look
at
when
we
go
to
start
small
iterate,
often
learn
from
our
mistakes.
Is
it's
a
bit
like
building
with
Legos
and
identify
what
those
building
blocks
are
to
be
able
to
create
to
show
those
those
small
successes.
A
So
we
intend
to
hit
on
basically
these
four
topics
over
all
throughout
the
next
half
an
hour.
Ish
talk
talk
a
bit
about
attributes
of
the
engineering
culture
that
we're
trying
to
foster
at
Cargill.
We're
gonna
talk
a
little
bit
about
incorporating
the
lean
concepts
and
principles.
How
we're
bringing
that
into
the
organization
the
primitives
and
the
building
blocks
that
we're
using
to
foster
the
engineering
engineering
culture
and
then
wrapping
it
up
with
some
of
the
self
service
and
usage
patterns
that
we've
built
up
for
our
DevOps
teams
to
consume.
B
B
We
we
outline
the
leadership
aspect
in
three
different
areas,
focused
pace
and
message
with
focus
it
really
comes
down
to
and
we
what
we
would
like
to
be
able
to
make
sure
that
our
leaders
are
aware
of
is
landing
on
what
the
what
the
idea
of
a
North
Star
is
Sophia.
If
you
think
of
at
a
large-scale
corporation
Cargill
has
about
150
thousand
one
hundred
sixty
thousand
employees,
we
do
business
in
70,
different
countries
or
across
we
might
be
have
something
in
every
continent.
B
The
focus
and
what
leadership
is
able
to
bring,
is
to
be
able
to
to
reduce
the
noise
in
the
signal
around.
What
are
the
really
big,
important
things
that
the
company
needs
to
do
and
filters
down
into
the
technologists?
That
then
turns
into
a
conversation
around
pace
we
like
to
put
pace
in
the
context
of
what
are
the
type
of
investments
that
we're
willing
to
put
forth.
So
all
the
different
areas,
whether
you
are
in
maybe
that
mode,
1
mode
2
to
have
a
conversation
or,
if
you're
working
in
plant
operations.
B
What
is
the
type
of
investment
that
leadership
is
willing
to
make
to
move
something
into
a
modern
state?
In
some
cases
that
might
mean
bringing
more
people
along
or
be
adding
more
people
into
an
environment.
It
might
mean
actually
more
fiscal
type
of
contribution
to
be
able
to
to
invest
in
in
physical
type,
things
for
us.
It
might
be
in
a
plant,
if
you
think
of
things
like
IOT
and
then
for
message
in
tone.
B
There
we
go
work
space,
this
actually
kind
of
flows
into
some
of
the
developer.
/
engineering
experience
one
of
the
things
that
we
we,
the
three
areas
in
work,
space,
talk
about
collaboration
and
the
idea
of
any
time
and
then
anywhere
and
with
collaboration.
This
flows
definitely
into
club,
not
only
collaboration
but
experiencial
learning
to
understand
that
within
the
ecosystem.
B
Not
only
is
it
things
like
your
workspace
and
the
physical
tools
that
you
might
have
that
hand
like
the
difference
between
a
Windows,
workstation
and
a
Mac,
but
also
understanding
that
as
a
whole,
there's
a
there's,
an
opportunity
for
there
to
be
optimizations
across
the
board
for
everyone
to
essentially
have
a
winning
outcome
anytime.
This
kind
of
flows
right
into
inspiration
at
any
given
time
somebody
might
have
an
idea
that
is
just
going
to
potentially
be
an
amazing
example
of
being
able
to
execute.
B
At
the
same
time,
it
could
be
a
great
way
to
be
able
to
identify
a
way
to
not
do
something.
I
don't
know.
If
folks
are
familiar
with
some
of
the
examples
from
like
Spotify
and
they're
engineering,
they
have
an
engineering
blog
and
when
they
talk
about
their
engineering
culture,
one
of
the
things
they
talk
about
is
somebody
during
a
hackathon
made
use
of
a
rotary
dial
phone.
B
One
of
the
key
things
that
we
we
go
after
at
Cargill
and
as
we're
looking
to
improve
the
overall
experience
for
developers.
Engineers
are
data.
Scientists
is
the
idea
that
identity
is
more
important
than
device
and
a
lot
of
times
a
lot
of
our
process
and
workspace
is
derived
around.
You
are
physically
located
inside
of
a
particular
location,
thereby
you
get
access
to
certain
internal
services.
B
Well,
what
if
we
pivoted
that
and
said
you
know
like
let's
continue
to
shrink
our
network
and
make
it
to
where
it's
zero
trust
and
make
it
to
where
the
fact
that
you're
logged
in
at
a
conference
view,
for
example,
sir,
that
you're
on
a
Mac
and
you're
logged
in
your
identity
gets
you
access
into
the
things
you
need
at
that
particular
time.
So
you
could
collaborate
with
the
right
people
at
the
right
time.
Then
the
last
leadership,
peace
process
and
operations,
kind
of
think
of
this
as
internal
IT
for
IT,
guys,
n.
B
B
All
right
lean
concepts
and
we're
gonna
go
through
this
ready,
alright,
so
becoming
a
learning
organization.
We've
got
a
couple
of
quotes
here,
but
one
for
from
Fred
Rogers.
The
most
important
learning
is
the
ability
to
accept
and
expect
mistakes
and
deal
with
the
disappointments
that
they
bring
this
when
it
comes
to.
B
When
we
look
at
the
way
that
we
want
to
build
up
an
engineering
culture,
we
have
to
make
sure
that
everyone
is
aware
that
this
is
a
safe
place
and
if
people
are
not
in
a
position
or
they
don't
feel
like,
they
can
share
the
things
that
they
learned,
they're
not
going
to
go
down
a
path
of
making
themselves
vulnerable
and
that's
just
sort
of
human
nature.
So
it's
a
bit
of
having
to
go
against
some
of
that.
B
A
You
know
kind
of
the
higher-ups
like
are
we
sure
we're
still
on
still
on
the
linemen
here,
like
projects
can
fail?
So
it's
been
like
an
interesting
journey
with
a
large
organization
that
is
used
to
bringing
in
outside
consultancies
that
drip
that
deliver
projects
on
time
under
budget
or
on
budget,
and
you
know
with
certain
functionalities
and
what
we're
trying
to
foster
is
more
of
a
creative
environment
where
people
can
try
new
things
and
excel
and
or
just
bomb
out.
In
that
regard,
we
have
tried
different
things
as
capi
as
our
API
platform.
A
As
simple
example,
is
we
deploy
everything
to
kubernetes
cluster,
so
all
of
our
new
IT
deployments,
all
of
our
new
projects
go
through
a
CI
CD
platform
see
the
pipeline
that
it
eventually
deploys
them
to
any
kiyose
kubernetes
cluster
and
our
original
idea
that
we
thought
would
be
really
cool
would
be
to
like
get
people
going.
We
would
create
our
own
namespace
in
the
cluster
and
we
would
be
the
owners
of
this
namespace
and
be
the
single
points
of
contact
and
would
help
people
may
be
on
board
to
the
kubernetes
environment
a
little
faster.
A
It
turns
out.
That's
a
horrible
idea
when
you
have
450
api's
and
maybe
one
of
those
api's
has
like
a
security
incident
or
something
like
that,
and
then
jason
and
I
become
the
single
point
of
contact
for
all.
Those
api
is
in
our
namespace
that
we
have
to
contact
and
reach
out
to
and
touch
base
with
and
make
sure
everything's.
Ok
in.
A
In
20
countries,
different
languages,
different
time
zones,
etc,
etc.
It's
another
another
good
example.
The
other
thing
we
did
is
about
a
year
ago,
and
this
was
before
that
database
lists
song
config
came
out.
We
decided
it
would
be
a
phenomenal
idea
to
like
to
find
a
yeah
mole
document
that
would
be
like
here.
I
want
to
deploy
an
API,
and
if
you
just
have
the
minimums
like
your
upstream
and
your
URI,
you
can
pretty
much
deploy
it,
and
so
we
spent
some
time
and
we
came
up
with
this
length.
A
You
know
policy
Hamel
definition,
we're
not
going
to
try
and
event
the
whole
deployment
of
an
API
policy
definition
into
Kong.
We're
gonna,
spend
some
time
understand
the
customers
a
lot
better
and
build
out
some
small
tools
to
help
us
manage
the
platform
and
then
spend
that
time
and
understand
that
the
customers
better.
So
one
of
the
things
we
did
and
I
think
the
Australia
National
Bank
did
something
very
similar.
We
created
a
CLI
tool
that
allows
us
to
manage
all
of
our
con
gateways
in
whichever
environment
push
policies
into
the
con
gateway
check
on.
A
You
know
read
the
stats
out
of
each
Kong
instance
all
from
a
CLI,
and
that
allows
essentially
me
to
manage
450
api's
across
all
of
our
environments,
and
we
don't
need
a
huge
team
of
people
and
we
don't
need
to
spend
a
lot
of
time
and
engineer
a
big
pipeline
to
do
it.
We
can
manage
it
via
one
CLI
push
to
push
the
JSON
files
into
Kong
and
kind
of
we're
done
during
that
time.
A
While
we
were
using
the
CLI
like
I
said,
we
spent
a
lot
of
time
and
understood
what
the
customers
are
asking,
what
they're
not
asking
for,
so
that
again,
we
don't
need
to
engineer,
don't
need
to
spend
so
much
time
engineering
capabilities
that
are
not
needed
by
the
customers.
Another
thing
that
we
did
that
really
allowed
us
to
simplify
the
deployment
of
policies
to
Kong
was
I.
Think
you
guys
did
something
very
similar.
We
created
a
little
policy
validator
so
right
before
the
CLI
pushes
a
Kong
or
a
policy
into
Kong.
A
B
His
column
was
talking
about
as
far
as
the
different
types
of
things
that
we
were
working
on.
We
get
really
caught
up
a
couple
of
times
in
trying
to
identify
and
build
out
features
that
we
were
pretty
sure.
Customers
didn't
know
they
needed
until
they
were
gonna,
ask
for
it
and
eventually
they're
gonna.
Ask
for
it,
because
your
experience,
like
eventually
people
are
gonna,
ask
for
certain
things
and
an
example
of
that
would
be
building
out
a
cash
content
environment
behind
our
gateways
so
that
we
can
stop
hitting
backends
for
commonly
requested
pieces.
B
We
worked
on
a
set
of
patterns
and
got
things
squared
away,
but
at
the
same
time
that
our
customers
weren't
even
realizing
the
number
of
times
that
we
were
making
a
request
to
the
backend,
because
then
in
the
scope
of
like
back-to-basics,
they
weren't
doing
anything
around
metrics
for
their
own
api's.
So
it
was
a
bit
of
before
we
get
to
the
point
of
adding
all
these
features
that
nobody's
ready
to
actually
consume.
A
A
Have
it
coexist
in
a
multi-tenant
at
API
gateway
and
then
and
took
about
a
year
for
them
to
start
asking
more
complicated
questions,
and
so
now
we're
thinking
about
a
year
after
we've
started
we're
ready
to
do
kind
of
some
more
awesome
things
we're
gonna
start
to
build
out
the
automation
process.
Event
event
the
deployment
of
the
policies
out
to
Kong
based
off
of
like
PRS
and
commits
out
of
github.
A
We
are
defining
more
of
the
standards
like
you
are
a
URI
naming
standards,
we're
gonna
start
implementing
more
self-service.
The
ability
to
query
the
Gateway
and
say
is
my
URI:
unique.
Can
I
deploy
this
API
to
the
Gateway
and
well
it
can
it
coexist
with
450
other
api's
I
think
Jason
alluded
to
it.
We've
started
to
introduce
the
proxy
cache
which,
as
the
API
teams
started,
deploying
their
api's.
A
We
can
and
I'm
glad
we
didn't
like,
try
and
implement
it
a
year
ago,
because
that
would
have
just
burned
much
a
bunch
of
time
and
so
then,
a
month
or
a
month
or
two
ago,
that's
when
we
started
building
out
in
the
the
Redis
cache
infrastructure
behind
the
proxy
cache
plugin,
and
so
now
we
have
teams
slowly
starting
to
consume
the
proxy
cache.
Like
that.
We
started
to
build
a
website.
A
We
call
it
Cappy
Docs,
so
anytime,
an
API
development
team
needs
information
about
best
practices
on
how
to
build
an
API
naming
conventions,
the
name
of
the
repository
and
github.
How
to
like,
after
I,
deploy
my
API,
how
do
I
find
the
logs
basic
how
to's
on
everything
are
surrounding
the
API
developers,
life
we're
putting
in
like
a
website
that
you
can
go
to
search
through
content
and
figure
out
how
to
self
service
their
own
API
and
then
better
customer
delivery?
A
We
started
using
github
we've
loaded
to
that
github
for
all
of
the
customer
interaction
and
so
we're
using
that
as
the
primary
mechanism
for
tracking
any
changes
to
policies
and
the
deployments
of
those
policies
to
the
con
gateways
and
again,
more
learning
like
I
hope.
We
have
another
screw-ups
story
later.
B
One
thing
and
I
mentioned
that
that
Colin
and
I
we
work
in
our
digital
labs
areas.
The
digital
labs
sits
inside
of
our
our
global
IT
function,
which
is
inside
of
inside
a
Cargill.
The
consumable
Docs
piece,
one
of
the
things
that
not
only
was
it
a
matter
of
having
this
website
for
people
to
go
to
across
our
digital
labs
area,
we're
all
using
the
same
type
of
mechanism
to
publish
those
Docs.
B
So
when
it
comes
down
to
our
developers
that
go
from
our
cloud
platform
to
an
API
platform
to
our
data
platform,
etc,
it's
a
common
look
and
feel,
and
we've
made
it
to
where
it's
a.
We
think
a
better
experience,
mapping
that
back
to
some
of
the
dirt
deferred
commitment.
There
was
a
bit
of
one
team
doing
one
thing:
another
team
like
making
use
of
wiki
and
another
team
just
making
use
of
github
reams,
but
making
it
to
where
we've
landed.
B
B
And
identifying
primitives,
yes,
so
one
of
the
things
that
we
want
to
make
sure
that
we're
able
to
do
is
to
get
into
at
that
platform
level
helping
builders
build
so
within
digital
labs.
We've
got
a
couple
of
different
areas
that
are
in
our
foundation
space
and
they
work
on
as
I
talked
about
a
API
platform
cloud
platform
or
data
platform.
B
These
are
the
platforms
that
different
than
projects
or
products
are
therefore
essentially
creating
an
opinionated
way
to
get
stuff
done,
with
the
expectation
that
the
things
that
are
produced
are
reusable
repeatable
patterns
that
coming
back
to
the
the
IT
operations
of
process
that
whole
80/20
rule.
If
80%
of
the
time
our
customers
in
that
platform,
space
are
able
to
use
what
we
are
providing
to
build
customer
facing
digital
applications.
We
feel,
like
that's,
a
really
good
metric
for
us
to
be
able
to
continue
and
make
sure
that
we're
doing
the
right
things.
B
Likewise,
we
talk
about
a
platform.
We
feel
like
there's
every
day,
there's
an
opportunity
with
the
engagement
that
we
have
that's
kind
of
the
purpose.
For
like
this.
This
train
platform
is
everyday.
There's
a
there's:
a
new
set
of
opportunities
for
new
customers,
new
people,
new
experiences
for
us
to
be
able
to
land
on,
understand
and
see.
What
do
we
need
to
do
to
potentially
pivot
much
like
the
like
the
rails?
B
I
think
Kaizen,
big
enough
proponent
of
Kaizen
that
I
actually
have
the
tattoo
in.
It
sits
with
this
that
we
have.
We
have
an
understanding
internally
within
our
space
that
customers,
even
our
internal
facing
customers,
are
the
the
ones
that
are
going
to
be
the
the
there
to
drive
the
right
delivery
of
the
right
things
that
we're
looking
to
build
Kong
being
a
component
of
that
and
a
broader
ecosystem
of.
How
do
we
want
to
be
able
to
express
the
way
that
we
need
these
applications
and
products
to
be
able
to
work
together?
A
So
go
backwards
here,
so
the
next
two
things
we
want
to
touch
on
briefly
is,
and
we've
alluded
to
it:
self-service
orientation
and
opinionated
and
transparent,
essentially
by
providing
like
what
we
call
it.
What
we're
calling
Cappy
as
a
API
platform,
we're
providing
a
I
gotta
think
about
this
a
little
bit
a
tool
like
we're,
building
a
platform
and
the
platform
is
not
an
end
in
and
of
itself.
A
The
platform
needs
to
allow
other
projects
to
build
things,
we're
trying
to
enable
like
a
consistent
user
experience
by
using
the
same
tools
over
and
over
again
and
then
mate,
using
tools
that
are
generally
available
and
consumable
by
that.
You
see
out
it
out
in
the
wild
I
guess
this
diagram
I
thought
was
interesting.
A
This
is
the
source
code.
You're
you're,
losing
a
lot
of
the
historical
narrative
around
the
projects
and
the
knowledge
around
these
projects
by
having
multiple
source
control
systems
and
multiple
chat,
ops
mechanisms
and
multiple
deployment
pipelines.
And
so
that's
why,
like
we've
made,
we
have
strong
opinions
that
we
should
use
the
following
tools,
and
then
we
backed
those
opinions
up
with
best
practices
and
standards
and
pipelines
that
drive
those
tools
and
to
me
the
takeaway,
and
you
know
for
sure,
using
like
github
as
the
source
code
repository
for
all
the
new
projects.
A
Right
now
is
we
have
developers
all
around
the
world
all
collaborating
and
chatting,
and
you
know
commenting
and
PR
Aang
and
it's.
It
creates
much
more
of
a
social
setting
and
more
of
a
collaborative
environment
for
that
for
the
DevOps
team,
which
I
don't
think
Cargill
had
before
we
started
using
a
tool
like
like
github,
so.
B
There's
one
important
thing,
I
think
with
with
this,
and
that
is
well.
The
the
tools
themselves
are
essentially
commodities.
We
like
the
ability
to
be
able
to
say
we
can
swap
these
things
out,
but
by
making
sure
that
we've
got
appropriate
patterns
and
that
the
development
community
as
whole
as
a
whole
is
consuming
those
patterns.
It
becomes
really
clear
where
the
gaps
are
so
that
we
can
prioritize
where
we
would
actually
look
to
make
changes
to
either
underlying
tooling
or
even
update
our
patterns
and.
B
We
want
to
thank
Cong
summit
for
for
having
us
out
here.
I
think
we're
pretty
much
coming
up
on
time,
make
again
they're
like
join
the
conversation,
we're
big
fans
of
getting
out
there
and
combination
and
so
forth.
I,
don't
know
if
we
actually
like
this
isn't
quite
the
format
for
like
any
questions
but
we'd
love
to
know
if
anyone
has
any
questions.
Otherwise,
we
thank
you
and
we
are
all
set.