►
Description
GitOps has a lot to offer – there’s a reason the operational framework for k8s cluster management and app delivery is red hot. Get it right and devs get a single source of truth of the desired state, automated syncs, drift detection and reconciliation, etc. But manifests have remained too complex for everyone to understand and usually describe k8s resources instead of apps. The tools that *do* treat apps as apps (instead of resources) tend to be focused mostly on CLI and UI – often ignoring the need to define everything as code. But can you combine both? Can you have app specs that are easy for devs to understand/write/manage? Can you combine that with GitOps, to focus on pushing changes to Git instead of operating clusters? Can you make everything easy to the point that anyone can use it, no matter if they have a Ph.D. in k8s or are an app developer that just wants their apps to run?
A
Before
we
jump
into
the
into
the
presentation
itself-
and
I
promise
not
to
bore
you
to
death
with
the
slides
at
least
I'll
try
and
we
will
jump
into
them
very
soon.
But
before
we
go
into
that
a
little
bit
about
me.
I'm
bruno
andrade,
one
of
the
founders
I'm
here
at
shipa,
where
we
focus
on
creating
an
application
layer
that
you
can
use
to
standardize
how
you
deploy,
manage
and
secure
applications
across
different
infrastructure
providers,
gke
aks
and
so
on,
using
different
ci,
cd
pipelines
and
github's
pipelines.
A
So
as
as
a
background,
I'm
a
former
software
developer
or
engineer
who
later
turned
into
sysadmin
so
prior
to
having
those
fancy
names
that
you
have
today
or
the
most
of
us
have
today,
such
as
devops,
devsecops,
sres
and
all
these
things.
At
the
time
we
were
all
seized.
Admins.
That's
where
I
come
from,
I
love
pizza
and
music.
A
A
A
It
takes
time-
and
it's
challenging
to
put
this
all
together,
and
this
is
the
common
response
that
many
times
we
get
from
our
developer.
They
hate
it
right
and
and
there's
a
reason
behind
it,
having
the
opportunity
to
talk
to
so
many
developers
about
how
they
see
kubernetes
and
how
they
seek
it.
Ops,
despite
it
being
interesting
as
a
technology
when
you
talk
to
them
about
the
evolution
to
get
ops
it.
A
So
when
you
deploy
using
argo
or
when
you
deploy
using
terraform,
you
are
not
defining
really
an
application,
but
you're
defining
the
underlying
today.
Kubernetes
objects
manifest
and
so
on.
Right,
and,
if
you,
if
you
think
about
it
for
many
times
as
as
devops,
we
we
spend
a
lot
of
time
trying
to
learn
the
infrastructure
components
putting
together.
So
for
us,
it's
it's
not
complicated
and
many
times
we
put
that
in
the
hands
of
the
developer.
Right
saying
you
can
do
it.
A
If
you
think
about
the
kind
of
software
development
life
cycle,
they
just
have
to
go
through
kind
of
build
tasks,
deploy
and
manage
their
applications.
What's
the
complexity,
and
basically
this
is
what
you
and
I
we
have
across
most
organizations
that
we
work
right.
This
stack
is
complex,
it's
complex
for
us
as
devops,
managing
our
clusters
and
and
bringing
evolution
to
our
infrastructure
and
changes
and
githubs
and
all
that
cool
stuff.
A
It
introduces
changes
and,
if
you're
moving
from
terraform
to
polumi
or
from
terraform
to
get
ops,
it
changes
all
over
again
right,
so
infrastructure
is
becoming
very
fragmented
and
that
fragmentation
brings
a
lot
of
challenges
for
us.
The
devops,
as
well
as
for
the
developers
and
bringing
git
ops
into
the
picture,
now
is
another
challenge
that
we're
introducing
has
changed.
There
are
the
clear
benefits
and
that's
not.
The
purpose
of
the
call
today
on
discussing
is
get
ops,
a
good
approach
or
not,
but
it
introduces
changes
and
introduces
challenges.
A
A
So
it's
a
lot
of
effort
on
us
as
devops,
and
it's
a
lot
of
effort
on
the
developer
side
to
basically
re-adapt
and
relearn
all
these
things
and
as
we
keep
moving
the
stack
and
our
infrastructure
as
code
stack,
has
changed
from
terraform
to
github's.
Now
argo
cd,
for
example,
which
is
the
topic
of
this
talk,
it
changes
all
over
again
and
as
kubernetes
changes
the
apis.
Basically,
our
templates
have
to
change
and
if
you're
starting,
if
you
have
just
a
few
services
you
may
get
around,
you
can
template
with
helm.
A
For
example,
you
have
just
a
few
services
to
deploy.
That's
fine
but,
as
you
start
deploying
across
many
different
clusters-
and
you
have
different
development
teams
and
you
have
different
applications
and
requirements,
then
it
starts
to
get
super
tricky
right
and
you
want
to
be
able
to
keep
on
evolving
your
infrastructure,
but
without
having
to
deal
with
a
lot
of
that
complexity
and
without
having
to
have
the
developers
depend
on
you
every
time
to
manage
those
templates,
help
them
troubleshoot
their
applications
and
get
their
applications
up
and
running
right.
A
So,
if
we
think
about
it
as
kind
of
separating
those
two
steps
and
in
the
middle,
we
actually
bring
an
application
layer
and
that
can
actually
implement
a
standard
way
that
you
can
define
and
deploy
your
applications,
no
matter
if
you're,
using
terraform
or,
if
you're,
using
argo
cd.
In
this
case,
and
no
matter
if
you're,
using
on-premises,
kubernetes,
ranger
kubernetes
or
if
you're,
using
gke120,
for
example,
the
definition
of
the
application
is
still
the
same,
that
would
allow
you
then
to
actually
break
apart
and
detach
the
application
from
the
underlying
infrastructure.
A
And
when
you
do
that,
you
can
keep
on
evolving
cluster.
Let's
say
tomorrow
you
want
to
bring
up
a
new
cluster
with
version
121,
for
example,
or
you
want
to
create
a
new
cluster
in
a
new
cloud
provider,
or
you
want
to
create
a
new
cluster
using
ranger,
for
example,
and
others.
You
can
do
that,
because
your
templates
and
your
application
definition
is
not
tied
to
that
and
the
same
way
on
the
other
side
on
your
pipeline
in
your
delivery
and
infrastructure
is
cool.
A
If
you
have
projects
where
developers
they
want
to
use
terraform,
that's
fine!
You
can
give
them
that
standard
definition,
but,
as
you
start
introducing
git
ops
in
the
organization,
if
you
keep
that
same
application
definition,
that's
where
you're
going
to
make
the
developer's
life
easier
and
that's
where
you
are
going
to
be
able
to
actually
evolve
your
infrastructure.
A
lot
faster
right
because
the
experience
is
the
same
so
now
you're
choosing
the
tools
but
keeping
the
same
experience.
A
So
it
doesn't
impact
you
anymore
and
doesn't
impact
the
development
team
as
well
so
you're,
basically
moving
away
from
this
thing
right
where
your
developer
is
basically
going.
What
the
hell
is
happening
here.
I
know
lame,
joke
lame
joke,
but
they're
going
away
from
this
right
again
as
as
a
devops
engineer
this.
This
might
be
easy
for
you,
because
that's
where
you
spend
most
of
your
time,
understanding,
infrastructure,
understanding,
complex
components
and
and
how
they
come
together.
A
A
I
mean
to
each
its
own
right,
so
you're
moving
your
developer
away
from
having
to
understand
all
of
this
and
you're
having
you're
moving
yourself
from
having
to
create
and
manage
all
of
these
components
and
changing
them
all
every
time.
There
is
a
change
to
basically
something
like
this,
where
it's
easy
and
focus
on
the
application.
A
A
This
definition
deploys
exactly
the
same
that
actually
this
helm
chart
deploys,
but
this
is
focused
on
the
application
and
it
leverages
catch
on
the
background.
So
catch
puts
together
all
the
components
that
kubernetes
needs
to
run,
that
application
service
ingress
and
all
that
together
and
we're
gonna
show
on
a
demo
pretty
soon
and
as
mentioned,
if,
if
you're
using
something
like
catch
and
you're
using
polomi,
for
example-
and
you
want
to
use
crossplane
as
infrastructure
as
code,
you
can
see
that
the
application
definition
is
exactly
the
same.
A
I
mean
other
than
the
boilerplate
that
yamo
or
javascript
introduces,
for
example.
Application
definition
is
the
same.
Your
developer
doesn't
need
to
know
if
you're
running
gke,
if
it's
helm,
if
it's
customized,
they
can
pick
the
tool
or
you
can
pick
the
tool
that
makes
sense
for
you
to
help
the
developer
or
have
help
those
applications
get
deployed
right.
A
So
we're
going
to
jump
into
the
demo,
but
before
we
jump
into
the
demo,
just
a
quick
highlight
of
what
we're
going
to
be
using.
This
is
me
on
my
left
side.
I
think
I
can
kind
of
move
myself
out
of
here
there
you
go
so
that's
me,
but
actually
that
picture
here,
it's
probably
from
five
years
ago,
when
I
actually
had
real
more
hair.
Today,
it's
not
going
too
well,
but
this
is
me
and
I'm
pushing
my
cold
to
get
I'm
keeping
true
to
the
git
ops
principles.
A
A
I
think
and
we're
going
to
be
delivering
an
application
or
applications
across
multiple
namespaces.
So
it's
all
open
source
stack.
You
can
get
started
for
free.
So
let's
see
what
it
looks
like
all
right.
So
now,
if,
if
I
check
on
my
terminal,
I
can
see
that
I
already
have
my
gke
cluster
available
and
and
running
and
my
cube
ctl
cube
cuddle
cube
control
whatever
you
want
to
call
it.
Whatever
makes
you
happy,
it
is
already
configured
and
I
can
access
that
cluster.
A
If
I
do
get
namespace,
for
example,
I
can
see
I
already
have
a
few
things
installed,
so
I
already
have
argo
installed.
I
have
istio
installed,
I
have
crossplane
installed
and
I
have
catch
installed.
So
basically
I
have
the
components
that
we
listed
on
the
deck
before
right,
crossplane,
catch
with
and
arbo
cd
right
and
I'm
using
instill
here,
because
that's
the
ingress
controller
that
I
had
installed
awesome.
A
So
now,
if
I
go
here,
I
have
a
simple
repo
that
we're
gonna
be
using
today
and
in
that
simple
repo,
you
can
see
that
I've
broken
it
down
into
two
different
folders
one
for
apps
and
another
one
for
namespaces
regarding
catch
right.
Catch
is
already
installed
in
my
cluster,
but
if
you
need
to
get
started
with
catch,
you
don't
have
it
installed
in
your
cluster,
yet
you
can
go
to
learn
dot
the
catch
dot,
io
again,
learn.the
catch.io!
A
You
can
see
a
getting
started
part
here.
It's
super
simple!
You
can
install
the
cache,
cli
install
assert
manager
and
you
can
choose
the
ingress
controller,
for
example,
that
you
want
to
use
a
traffic
or
istio.
I
chose
istio
for
my
example,
because
that's
what
most
people
use
these
days,
I
install
a
cluster
issuer
and
they
click
the
catch
controller.
A
A
You
can
find
information
here
on
how
to
install
both
crossplane
installing
crossplane
is
quite
easy
and
installing
the
cache
provider
for
us
to
run
this
example
great.
So
we
know
how
to
install
catch.
We
know
where
to
find
information
to
install
crossplane
and
the
cache
provider
for
crossplane,
and
installing
argo
was
super
easy.
So
let's
go
into
the
namespace
definitions
and
the
application
definitions.
So
we
see
what
actually
looks
like
right.
A
If
you
go
first
to
our
namespaces,
I
have
two
here:
dev
and
production.
Catch
calls
namespaces
frameworks
a
little
bit
of
background.
Catch
is
an
open
source
project
that
was
created
by
shipa,
so
shipa
uses
catch
internally
to
deploy
the
applications,
so
catch
is
the
application
layer
or
the
deployment
engine
that
chipa
uses
to
create
that
application
later
and
chipa
calls
it
framework,
so
cache
also
carry
that
for
now,
at
least
so,
when
you
think
framework
just
associate
namespace.
So
when
we
create
a
framework,
we're
creating
a
namespace.
A
So
here
what
we're
doing
is
we're
saying:
hey
the
kind
is
framework,
and
this
is
the
name
of
the
framework
or
the
name
of
the
namespace,
that
catch
should
create,
and
one
additional
point
that
we're
passing
here
is
the
service
endpoint.
So
it's
a
service
endpoint
used
by
istio
or
created
by
istio
right.
A
Why
are
we
passing
that
here?
It's
because
every
time
an
application
deploys
an
application
to
this
namespace
slash
framework
catch
will
automatically
create
an
endpoint
where
your
application
is
going
to
be
exposed,
so
developers
can
access
the
application
right,
so
they
don't
need
to
go
through
like
how
do
I
create
a
service?
How
do
I
create?
How
do
I
expose
apps
and
all
that
stuff?
A
A
A
A
A
A
A
So
now,
if
I
go
to
my
app
folder
right,
I
have
two
applications
in
here.
I
have
dav
app1
and
dav
production1
apps.
If
I
go
into
this
definition,
I
have
here
the
provider
and
it's
a
type
app
and
the
only
thing
I'm
passing
as
as
a
developer,
and
you
can
break
it
down
right.
The
namespace
repo
can
be
owned
or
should
be
owned
by
the
devops
team.
A
Here
I
have
a
little
bit
more.
So
I'm
saying
yeah.
This
is
the
framework
or
namespace
that
I
wanted
to
be
deployed,
but
here's
the
port
or
ports
that
I
want
to
expose
when
this
application
is
deployed-
and
here
is
the
number
of
units
that
it
should
have
by
default,
you
can
find
more
information
around
application
definition
options,
for
example,
directly
from
here,
where
you
can
expose
ports,
units
processes,
route,
settings
and
all
that
stuff,
as
well
as
from
a
framework
management
if
you're,
deploying
or
if
you're,
deploying
jobs,
for
example.
A
So
you
can
find
further
definitions
in
the
documentation,
learn
dot
the
catch
dot
io.
But
here
in
our
example,
I
have
those
two
things.
One
application
basic
bulletin
board
just
get.
It
deployed.
Second,
one
pod
info
deploying
this
app
but
exposes
on
port
9898
and
deploys
with
with
the
different
units
right.
A
A
A
A
I
can
see
my
pod
info
application
deployed
as
well,
so
now
as
a
developer,
I
can
finally
understand
the
application
definition
in
an
easy
way
right
and
I
can
get
my
applications
deployed.
I
can
use
argo,
I
can
use
kubernetes
and
if
tomorrow
I
want
to
move
from
argo
and
may
not
move
but
use
on
some
projects
use
pollumi.
A
For
example,
you
can
see
it's
exactly
the
same
definition
so
now:
you're
free
to
detach
the
application
from
the
infrastructure,
use
and
experiment
with
different
infrastructure,
escort
githubs,
different
pipelines,
and
you
can
bind
catch
to
any
pipeline.
You
have
and
help
you
deliver
applications
to
kubernetes
with
a
good
developer
experience.
A
Alright.
So
just
to
close,
I
really
appreciate
you
taking
the
time
to
go
through
this.
I
hope
that
was
useful
as
mentioned.
Catch
is
an
open
source
project
and
you
can
find
it
under
github.com.
Slash,
chipa,
corp
dash,
corp,
slash
catch,
I'd,
love
your
support,
I'd
love
to
see
what
you
think
about
it
and
how
we
can
involve
evolve
catch.
We
have
tons
planned
going
to
be
creating
plugins
where
you
can
easily
extend
catch.
A
If
you
want
to
add
other
ingress
controllers
or
add,
storage
or
other
application
definition
components,
you
can
find
catch
docs
on
learn.the
catch.io
and
the
simple
repo
that
I'm
that
I
use
it's
it's
here.
It's
super
simple
and
the
definitions
that
we
used
is
in
the
documentation
as
well.
So
we
would
love
to
see
your
support.
Help
us
build
cache,
help
us
build
an
application
definition
layer
that
you
can
use
anywhere.
A
That
will
allow
you,
as
a
devops,
to
evolve
the
infrastructure
without
all
the
complexity
and
having
to
rebuild
charts
and
rebuild
everything
every
time
you
change
api
version
or
cluster
version,
or
you
change
infrastructure
as
co-provider.
So
let's
help
us
standardize.
This
would
love
to
hear
your
thoughts
and
your
use
cases
and
build
together
with
you
appreciate
you
taking
the
time.
Thank
you.