►
From YouTube: Tools That I Wish Existed 3 Years Ago To Build a SaaS Offering - Mauricio Salatino, VMware
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Tools That I Wish Existed 3 Years Ago To Build a SaaS Offering - Mauricio Salatino, VMware
If you are tasked with building a Software as a Service (SaaS) offering for your company products/components, you will need to make some big decisions, for example: one or more Cloud Providers, tools, creating your own abstractions, etc. From a developer perspective, this presentation covers tools in the Kubernetes ecosystem that will make your life easier when building a SaaS offering. This session cover tools such as Crossplane, Helm, CloudEvents for integrations and interoperability, Knative and Tekton to make sure that you have the flexibility to deploy your workloads in different cloud providers if needed. This presentation shows you in action tools that provide higher-level abstractions to help you to keep your implementations Multi-Cloud friendly.
A
Welcome
to
my
presentation,
title
tools:
I
wish
existed
three
years
ago
to
create
a
sas
platform.
My
name
is
maurice
latino
and
I
will
be
talking
about
a
bunch
of
open
source
projects,
I'm
at
salaway
in
twitter
and
I'm
a
staff
engineer
for
vmware
and
I'm
working
100
of
my
time
in
a
project.
That's
called
k
native
I'm
a
kubernetes
addict
and
I
really
enjoy
open
source.
So
I
enjoy
building
frameworks
and
abstractions
that
you
know
helps
you
to
build
better
applications
and
faster.
I
do
share
my
learnings
in
my
blog.
A
That's
salaboy.com
so
feel
free
to
check
it
out
if
you're
interested.
Before
I
start
my
presentation,
I
wanted
to
share
that.
I'm
writing
a
book
for
manning
that
it's
titled,
continuous
delivery
for
kubernetes
and
it
just
entered
the
early
access
program.
So
you
can
find
all
the
details
about
the
book
and
the
topics
that
I'm
covering
here
in
this
link.
If
you're
interested
in
that
feel
free
to
join
the
the
program
doing
today's
presentation,
I
will
be
talking
about
the
software
as
a
service
platform
anatomy.
From
a
developer
perspective.
A
I
do
consider
myself
a
developer,
so
I'm
looking
through
this
lens
and
then
building
and
packaging
stuff
pretty
quickly.
This
presentation
is
not
long,
so
I
will
just
be
showing
some
projects
that
you
know
you
can
use
in
order
to
do
something
related
to
building
and
packaging.
I
will
be
talking
about
application
infrastructure,
that's
a
little
bit
longer,
but
again
it's
pretty
rushed
because
the
amount
of
time
that
I
have
for
this
presentation
and
then
I
will
be
talking
about
making
your
developers
life
easier
by
installing
tools
like
k
native.
A
So
let's
start
by
defining
what
do
I
think
that
a
software
as
a
service
platform
is
and
why
it
needs
to
be
self-service
and
multi-cloud
enabled
as
well?
So
I,
when
I
think
about
like
building
a
software
service
platform,
I
do
feel
that
you
need
a
self-service
approach
right,
like
whatever
your
customers
are.
You
need
to
provide
them
a
way
for
them
to
just
go
and
parameterize
your
platform
and
just
click
a
button
and
then
provision
some
components
or
applications,
so
they
can
just
go
and
use
them.
A
Customers
between
quotes
because
they
can
be
internal
or
external.
You
can
have
internal
teams
of
different
departments
that
requires
to
provision
you
like
some
components
for
them,
so
they
can
do
their
work
or
they
can
be
external
being
like
real
customers.
If
they
are
internal,
then
sometimes
we
can
decide
where
we
can
run
this
software.
Sometimes
we
can't,
but
if
we
can,
our
life
is
going
to
be
definitely
be
easier.
A
That's
kind
of
where
I
usually
tend
to
have
my
experience
on
is
that
you
need
to
also
allow
your
customers
to
run
your
platform
like
your
software
as
a
service
platform
in
their
on-prem
cloud
services
as
well.
That's
again
because
of
regulations
because
of
the
nature
of
the
software
that
you
are
providing
for
them.
This
is
way
much
more
technical,
but
I've
seen
this
happening
a
lot
in
the
tech
industry.
A
So
it
is
very
important,
as
you
already
saw
the
fact
that
you
can
choose
different
cloud
providers
and
to
have
a
cloud
strategy
like
a
multi-cloud
strategy
in
place
for
building
your
platforms.
It's
really
important,
but
having
clear
definitions,
it's
even
more
important
and
this
blog
for
blog
posts
from
hashicorp
cto,
defining
different
dimensions
of
where
what
multi-cloud
means
it's
pretty
spot-on
right
and
when
I
read
it.
A
A
So
the
scenario
for
this
presentation
is,
you
know
a
conference
platform
that
you
can
create
instances
and
you
can
just
organize
your
conference
on
top
of
it
right.
So
you
have
different
sections
different
services
to
implement
this
functionality.
You
have
the
agenda
service,
you
have
speakers,
you
have
proposals
and
all
these
examples
can
be
found
in
this
repository
that
it's
down
below
it
says
sal
away
from
monolith
to
gates
where
you
will
find
step-by-step
guides.
A
Tutorials
on
the
examples
that
I
will
be
showing
during
this
presentation
for
all
the
tools
that
I
will
be
showing,
but
in
reality
I'm
building
this
this
conference
instances
with
different
services.
They
all
talk
to
each
other
using
rest
calls
and,
of
course,
in
real
life.
You
will
have
more
and
more
services
and
you
need
to
prepare
for
your
cloud
native
applications
to
expand
and
add
more
services
to
them.
So
you
need
to
have
the
right
tools
for
doing
that
and
make
sure
that
you
automate
as
much
as
possible.
A
But
what
I
really
want
to
build
here
is
something
more
like
this.
I
want
to
build
a
self-service
conference
platform
where
your
customers
can
go
parameterize
and
then
create
different
instances
for
different
events
right.
So
you
have
a
conference
in
argentina,
in
the
uk
and
in
denmark
you
have
your
customer
going
and
just
clicking
in
some
forms.
Just
entering
some
information
clicking
create,
and
you
know
a
new
instance
of
this
platform
should
be
created
for
them
when
they
don't
want
to
use
that
anymore.
They
can
just
shut
it
down.
A
A
Okay,
now
that
we
know
what
we're
building,
let's
talk
about,
building
and
packaging
stuff
with
tekton
and
with
helm.
So
now
that
you
know
that
the
application
is
composed
by
four
services,
we
need
a
way
to
automate
the
creation
and
building
all
these
artifacts,
which
will
include
testing
and
just
publishing
artifacts
to
different
repositories.
A
So
for
that,
I
usually
tend
to
think
that
we
will
need
to
have
a
pipeline
engine
in
this
case,
I'm
suggesting
to
take
a
look
at
tecton,
but
the
concept
that
I
want
to
share
here
is
the
idea
of
service
pipelines
for
every
service
that
we
want
to
build.
We
should
be
able
to
have
a
pipeline
that
is
automating
all
the
build
process
for
all
these
artifacts,
and
it's
also
looking,
for
example,
into
git
repositories
to
see
when
changes
happen.
A
If
you
follow
a
trunk
based
development
approach,
which
basically
is
every
time
that
you
merge
something
into
the
main
branch,
you
are
just
going
to
create
a
release
for
your
artifacts.
You
want
all
that
stuff
to
be
automated
for
you
and
this
pipeline
instance
and
the
pipeline
engine
that
is
running
this
pipeline
needs
to
be
configured
in
the
right
way,
with
all
the
infrastructure
required
for
you
to
publish
these
artifacts
at
the
end
of
the
day,
different
kind
of
pipeline,
it's
having
an
environment
pipeline
which,
basically,
it's
going
to
sync.
A
You
know
a
git
repository
that
has
the
configuration
about
the
service
that
you
need
to
be
running
in
a
kubernetes
cluster
with
you
know
a
real
kubernetes
cluster.
This
is
more
commonly
known
gitops,
but
here
I'm
just
calling
them
environment
pipelines
because
for
every
environment
that
we
want
to
have
in
our
you
know,
in
our
customers
for
our
developers
for
qa
for
tests,
customers
or
different
scenarios,
you
will
need
to
have
one
of
these
pipelines
that
basically
takes
the
configuration
from
a
git
repository
and
applies
it
to
a
live
cluster.
A
You
can
implement
this
with
different
tools
than
tecton,
but
in
this
case
I'm
just
suggesting
eutecton,
because
it
definitely
brings
kind
of
like
this
declarative
approach,
where
we
can
just
define
these
pipelines
using
kubernetes
resources
and
they
are
going
to
run
inside
our
kubernetes
cluster
as
well.
So,
let's
take
a
quick
look
at
a
demo
of
how
tekton
works
and
how
do
you
define
these
pipelines
using?
A
So
if
you
go
to
these
instructions,
you
will
see
that
tecton
comes
with
something
that
is
called
tecton
dashboard.
That
is
optional,
that
you
can
install
as
well,
and
what
I
have
here
is:
I
have
two
pipelines:
definitions,
one
for
a
service
that
is
called
api
gateway
and
that
basically
contains
all
the
steps
to
build
that
service
and
to
publish
all
the
artifacts
and
then
the
staging
environment
pipeline,
which
basically
is
in
charge
of
looking
into
a
git
repository.
A
That
has
the
configuration
for
what
I
want
to
deploy
into
the
staging
environment
and
sync
that
to
a
configured
kubernetes
cluster.
So
if
I
want
to
run
these
pipelines,
I
can
do
this
by
sending
a
command
to
kubernetes
and
that
command.
You
can
also
find
in
here
which
is
basically
creating
a
new
instance
of
a
pipeline
with
a
bunch
of
parameters.
A
I'm
creating
a
new
pipeline
instance
a
pipeline
run
in
this
case
it's
called
and
the
pipeline.
Of
course
you
can
parameterize
it
with
different.
You
know
parameters,
you
can
define
the
branch
where
that
you
want
to
build,
and
where
is
the
docker
file,
the
user,
that
you
want
to
use
to
publish
docker
images
and
all
that
stuff?
The
version
that
you
want
to
generate
and
as
soon
as
you
enter
all
the
parameters,
you
will
have
a
new
instance
of
that
pipeline.
That
is
going
to
be
running
and
you
can
monitor
here
in
pipeline
runs.
A
A
This
is
a
kubernetes
resource
that
you
applied
to
your
cluster
and
now
tecton
has
this
definition
available.
It
scan
pipeline.
It
comes
from
from
tecton
and
the
important
part
in
here.
Besides,
all
the
parameters
are
the
tasks
which
are
basically
the
things
that
you
want
this
pipeline
to
run.
In
this
case,
I'm
cloning,
a
repository,
I'm
using
a
bundle
from
the
tecton
catalog
that
it's
that's
a
pretty
fine
behavior,
it's
pretty
common
to
want
to
clone
git
repository,
so
they
already
included
that
functionality.
A
For
you,
it's
pretty
common
to
build
stuff
in
the
java
world
with
maven,
so
they
have
already
a
task
that
will
do
that
for
you
and
it's
pretty
common
to
build.
You
know
docker
images
and
publishing
docker
images
and
you
can
do
with
kaneko.
So
it's
pretty
straightforward
to
configure
these.
The
main
idea
here
is
that
you
define
one's
pipeline
template
and
then
you
just
use
the
same
template
for
different
services.
A
So
after
running
this
pipeline,
what
I
would
expect
is
having
all
the
you
know,
artifacts
required
for
me
to
deploy
this
service,
this
new
service
version
into
an
environment,
and
for
that
then
I
can
trigger
the
staging
environment
pipeline.
That
will
sync
again
this
repository
that
I
have
where
I
have.
The
new
version
of
my
service
specified
to
a
live
corners
cluster.
So
I
can
go
and
see
my
service
up
and
running.
That's
pretty
much.
A
What
tekton
is
it
allows
you
to
declaratively,
define
these
pipelines
using
kubernetes
resources
and
then
just
run
these
pipelines
inside
kubernetes
clusters,
so
you
can
automate,
building
and
deploying
all
the
services
that
you
are
that
are
required
for
your
application
to
run
when
building
staff.
It's
also
important
to
recognize
that
we
need
to
have
some
kind
of
package
manager
for
our
kubernetes
resources.
A
So
all
the
teams
can
install
the
same
thing
and
usually
the
recommendation
here,
because
I
don't
want
to
spend
too
much
time
on
this
is
to
keep
the
helm
chart
and
the
definition
of
the
chart
close
to
your
source
code.
So
if
you
have
a
service,
it's
quite
good
to
have
the
chart
in
the
same
repository,
for
example,
so
you
can
version
all
the
things
together
and
when
you
run
the
pipelines
kind
of
like
the
last
step
should
be
to
create
that
chart
and
just
publish
it
to
a
chart
repository
in
helm.
A
You
can
use
composition
and
dependencies,
but
you
need
to
be
very
careful
with
that.
For
example,
you
don't
want
to
include
too
many
dependencies
in
your
charts,
which
will
make
it
the
chart
very
difficult
to
configure
and
remember
that.
Also,
when
you're
using
helm,
there
is
no
need
to
install
the
kubernetes
manifest
using
helm,
install
you
can
use
helm,
template
to
print
out
all
the
manifest
and
then
use
customize
to
just
change,
for
example,
some
of
those
xml
files,
depending
on
whether
you
want
to
apply
them.
A
So,
let's
take
a
super
quick
look
at
what
you
can
do,
which
is
basically
installing
the
application
by
just
running
a
single
command
line,
so
I've
created
a
chart
with
all
the
services
that
are
required
for
my
application,
and
I
can
just
run
this
command
helm,
installer.
The
name
of
the
release
that
I
want
to
create,
and
the
name
of
the
chat
that
I
want
to
install
that's
published
in
my
own
home
repository
and
it's
fetching
the
chart
and
basically
installing
that
to
the
configured
coronaries
cluster
that
I
have
in
my
terminal.
A
So
here
I
can
see
the
services
that
are
being
started.
I
have
four
services
and
those
four
services
were
created
by
the
definitions
that
are
included
in
this
chart.
This
chart
has
a
version,
it's
0.1.0,
so
I
know
exactly
what's
in
there.
What
versions
of
my
services
are
in
that
specific
version?
So
I
can
trace
back
and
figure
out
what's
going
wrong
when
things
just
go
bad,
so
that's
pretty
much
helm.
I
totally
recommend
you
to
check
it
out.
A
I'm
just
sharing
this
because
I
do
believe
that
helm
is
a
good
project,
but
there
are
different
alternatives
as
well
and
as
soon
as
you
have
some
kind
of
like
package
manager
to
deal
with
versions
and
to
easily
distribute
your
applications,
you
are
good
to
go
so
once
you
can
build
your
services
and
your
environments,
then
the
next
step
is
to
talk
about
application
infrastructure,
and
for
that
I
will
be
talking
about
crossplane.
So
for
this
example,
some
of
my
services
require
databases,
for
example.
A
And
how
do
you
do
that
in
usually
right?
You
can
use
helm,
as
I
mentioned
before,
you
can
just
go
to
vietnam,
for
example,
and
find
the
redis
and
the
postgresql
and
the
kafka
chart
and
just
install
that
into
your
kubernetes
cluster,
but
that
becomes
pretty
problematic.
Quite
soon
because
you
need
to
maintain
these
components
inside
your
clusters
and
you
need
to
have
dbas
and
people
that
it's
trained
in
both
in
kubernetes
and
into
the
databases
in
this
case,
to
maintain
those
components
running
for
for
longer
times
right.
A
So
usually,
unless
you
are
doing
development,
you
tend
to
not
install
helm,
charts
into
kubernetes
clusters
for
application
infrastructure.
You
can
also
use
cloud
provider
specific
tools
right,
like
you,
can
go
to
google
cloud,
for
example,
and
create
possgray
sql
instance
on
a
reddish
instance
and
then
connect
your
services
to
these.
You
know
managed
databases
inside
google
cloud
right,
that's
kind
of
like
okay.
The
problem
is
that
you
need
to
learn
about
google
cloud
specifics.
A
So
crossplane
is
basically
a
multi-cloud
application.
Infrastructure
made
easy
and
how
does
it
work?
I
usually
tend
to
try
to
explain
how
how
it
will
go
for
you
if
you
want
to
use
it.
So
basically,
you
install
crossplane
into
a
kubernetes
cluster
and
then
you
just
configure
one
or
more
providers
like
google
cloud,
azure
aws
and
you
give
the
right
permissions
to
these
providers.
So
you
can
just
go
and
probably
provision
components
in
in
their
infrastructure
right
and
then
you
just
basically
create
kubernetes
resources.
A
A
It
also
creates,
for
example,
a
secret
with
the
url
and
the
username
and
password
that
your
services
inside
kubernetes
will
need
to
use
in
order
to
connect
to
that
specific
instance,
and
at
the
same
time
it
will
keep
monitoring
and
reconciling
the
definition
that
you
created
in
a
kubernetes
object
into
the
actual.
You
know
gcp,
azure
or
aws
infrastructure,
making
sure
that
if
somebody
deletes
you
know
that
database,
it's
automatically
recreated
for
you
and
for
your
application
to
keep
working.
So
let's
take
a
look
at
that
first.
A
So,
as
I
mentioned
before,
I've
installed
a
crossplane
into
my
cluster
and
basically
I
can
go
and
create
now
a
database
here
in
google
cloud
in
sql
cloud
sql,
and
I
don't
have
any
instance,
but
I
can
choose
between
my
sql
postgres
sql
and
sql
server
and
if
I
choose
postgresql
basically,
what
I
will
need
to
define
is
the
name
for
the
database,
password
version,
a
region
and
some
other
parameters
right.
If
I
click
create
instance
here
I
would
just
have
one
of
these
instances
with
crossplane
installed
and
the
gcp
provider
configured.
A
A
Basically,
what
I'm
also
going
to
get
is
a
secret
inside
the
namespace
that
will
contain
all
the
information
about
how
to
connect
to
that
a
specific
instance
and
the
username
and
password
and
the
url
that
I
need
to
put
into
my
services
that
wants
to
connect
to
it.
So
that's
pretty
useful,
but
still
we
can
do
better
than
that.
Let's
go
back
to
the
presentation.
A
But
we
can
do
much
more
right,
because
crossplane
also
comes
with
the
concept
of
compositions,
which
are
basically
abstractions,
that
we
can
build
for
our
own
domain
and
we
can
build
these
abstractions
based
on
the
uses
that
we
have
right.
So
I
can
create
an
object,
type
and
notice
that
this
is
my
type
that
is
called
postgresql
instance
when
I've
already
defined,
which
version
of
postgresql
do
we
want
to
use,
and
the
only
thing
that
I'm
asking
for
the
user
to
enter
here
is
the
size
of
the
database
right.
A
I'm
also
setting
up
here
the
name
of
the
secret,
where
I
want
to
that
crossblink
will
use
in
order
to
create
all
the
urls
and
usernames
and
passwords
for
connecting
to
that
specific
instance.
So
in
this
case
I
provide
like
a
higher
level
abstraction
of
how
to
provision
a
postgresql
instance
that
is
not
tied
to
a
cloud
provider
and
I
can
provide
different
configuration
packages
on
the
back
for
different
providers.
So
this
postgresql
instance,
I
don't
know
where
it's
going
to
be
provisioned.
A
It
will
depend
on
the
provider
that
I
have
installed,
and
you
know
it
will
not
change,
depending
on
the
cloud
provider
that
you're
running
on
right,
which
is
again
giving
you
this
abstraction.
This
moving
you
far
away
from
the
actual
car
provider
that
you're
using
for
running
this,
this
infrastructure
always
providing
that
interface
of
you
define
an
object
and
then
just
connect
by
looking
into
a
secret.
A
Nothing
stops
you
to
go
one
step
higher
right
and
create
an
abstraction
and
a
composition
for
what
a
conference
is,
and
this
interface
in
this
case
is
just
setting
up
the
details
of
the
infrastructure
that
you
need
for
that
conference.
But
you
also
can
specify
some
other
parameters
to
configure
the
services
that
are
going
to
be
composing.
Your
application.
I
showed
you
before
how
to
install
a
helm
chart
that
contains
all
the
services
of
the
application
and,
in
this
case,
I'm
doing
the
same
but
with
crossplane.
A
So
instead
of
manually
going
and
installing
you
know
a
helm
chart,
I
am
defining
a
high
level
abstraction
here
of
what
my
confidence
instance
is.
That
also
includes
the
infrastructure
that
I
need
to
run
my
services
and
I'm
telling
crossplane
to
go.
Create
a
new
namespace
install
a
home
chart
provision,
the
infrastructure
that
I
need
create
the
secrets,
so
my
services
can
connect
to
them
and
that's
pretty
cool,
because
I
managed
to
create
a
big
package
that
allows
me
to
create
new
instances
on
demand
by
just
creating
kubernetes
objects.
A
So
let's
take
a
look
at
that:
okay,
so
I've
just
deleted
the
instance
that
I've
created
before
so
I
do
not
have
any
postgresql
instance
and
we
can
switch
back
to
the
terminal
to
take
a
look
at
this
conference
jamal
file
that
I've
created
right.
So
I
have
this
definition
again,
just
setting
up
the
sizes
for
the
redis
database
and
the
postgresql
database,
and
what
I'm
expecting
is
that
as
soon
as
I
send
this
conference
instance
to
crossplane,
groundsplane
is
going
to
just
run
through
this
composition
that
basically
install
the
application
provision.
A
A
If
I
get
the
bots
there
inside
the
namespace,
I
can
see
that
my
application
boards
are
already
up
and
running,
which
is
pretty
nice
regarding,
like
all
the
automation,
of
course,
that
this
is
the
pods
are
going
to
connect
to
the
databases
when
the
databases
are
ready
and
they
will
just
keep
looking
into
it.
In
order
to
be
able
to
be
fully
function.
A
And
again,
I
can
just
check
the
status
by
just
listing
kind
of
like
the
conference
instances
and
wait
for
everything
to
be
ready,
so
I
can
give
access
to
my
users.
So
in
these
ways
we
have
just
obstructed
how
to
create
conference
instances,
and
we
are
now
at
a
point
where
we
can
say
if
we
got
a
call
that
we
have
a
new
customer.
A
The
only
thing
that
I
need
to
do
is
to
create
that
conference
object
and,
at
the
end
of
the
day,
I
will
end
up
with
the
namespace
plus
all
the
infrastructure
that
I
need
to
run
my
services
already
wired
up
and
provisioned
in
the
right
cloud
provider.
This
demo
can
be
extended
to
create
the
infrastructure,
for
example
in
nws
or
in
azure.
There
is
not
much
changes
required,
only
the
specific
configurations
to
define
which
resources
inside
the
cloud
providers
needs
to
be
created,
which
is
just
implementing
and
defining
these
compositions
for
using
different
resources.
A
Only
so,
let's
go
back
to
the
presentation.
Okay.
So
let's
talk
about
making
your
developer's
life
easier
with
knitting
k
native,
it's
a
very
difficult
project
to
explain-
and
I
think
that
kelsey
put
it
in
the
right
way
here,
which
says
if
kubernetes
is
the
electrical
grid.
10K
native,
is
the
light
switch
which
is
perfectly
aligned
with
the
idea
of
being
a
set
of
abstractions
and
tools
to
make
your
life
easier.
A
When
you
are
developing
cloud
native
applications,
k
native
comes
into
two
flavors,
two
different
components
that
you
can
use
independently,
kinetic
serving
that
provides
advanced
traffic
management
and
the
auto
scalers
and
canadian
eventing.
That
brings
the
concepts
of
producers
and
consumers
of
events
to
kubernetes.
So,
let's
take
a
look
at
k.
Native
serving
canon
observing
allows
you
to
create
canadian
services,
so
instead
of
creating
kubernetes
services,
ingresses
and
deployments,
you
just
create
a
canadian
service
and
canadian
service.
A
It's
going
to
create
all
these
kind
of
like
dependencies
for
you
what
you
can
do
it's,
for
example,
here.
What
the
example
is
showing
here
is
like
a
header-based
routing.
In
this
case
you
have
the
main
revision
of
your
application.
That's
the
version
that
you
want
to
expose
to
all
your
users
expose
there
like,
and
your
users
are
accessing
that
that
version
of
the
application,
but
you
want
to
introduce
another
different
version
for
developers
to
debug
certain
scenarios
and
certain
issues
that
can
appear
right.
A
So
in
this
case,
what
you
can
do
in
a
canadian
service
is
to
define
some
traffic
rules.
In
this
case
we
are
saying
hundred
percent
of
the
traffic
it's
going
to
go
to
version
one,
but
if
we
include
a
specific
http
header,
when
we
create
the
request,
we
are
going
to
route
to
this
second
version,
which
is
the
debug
version.
A
So
let
me
show
you
that
in
action
quickly
with
just
a
simple
example,
so
I
have
installed
k
native
serving
here
in
my
cluster
and
I've
installed
the
same
application
that
I
showed
you
before,
but
now
using
k
native
services.
Instead
of
you
know
normal
kubernetes
services
deployments
and
englishes,
so
if
I
list
my
candidate
services
that
I
can
do
with
that,
the
first
thing
that
you
will
notice
is
that
you
will
have
a
url
to
access
the
application
to
access
the
services
straight
away
without
the
need
of
an
ingress.
A
So
I
can
just
copy
that
into
you,
know
my
browser
and
I
can
access
the
application
that
I
showed
you
before.
As
I
mentioned,
one
of
the
features
that
k
native
allows
you
to
implement
quite
easily
is
to
create
this
header
based
routing.
So
one
of
the
things
that
you
can
see
here,
if
I
list
all
the
bots
is
that
I
have
two
revisions
of
my
application.
A
One
is
the
normal
version
that
the
users
are
accessing
and
the
other
one
is
the
the
back
version
that
it's
already
running
for
developers
to
troubleshoot
the
application
and
in
order
to
route
traffic
to
this
specific
version,
the
debug
version.
I
can
use
something
like
mod
header
here,
which
is
a
chrome
extension
that
allows
me
to
set
a
specific
header
when
I'm
doing
when
I'm
doing
the
request.
A
In
this
case,
I'm
setting
the
vag,
which
is
the
name
of
the
tag
that
I'm
using
in
the
traffic
rules,
and
if
I
refresh
the
application,
I
will
be
able
to
access
this
debug
enabled
version
of
the
application
that
is
running
there
in
the
same
cluster.
This
allows
me
to
run
different
configurations
of
the
same
service
at
the
same
time
and
then
create
these
traffic
rules
in
order
to
direct
traffic
to
different
places
based
on
different.
A
So
hopefully
that
just
shows
you
a
simple
thing
that
if
you
want
to
do
only
with
kubernetes
resources,
it
is
pretty
hard
to
do
and
you
will
need
to
rely
on
something
else
to
to
implement
this
kind
of
functionality.
So
I
totally
recommend
you
to
check
k
native
serving
for
that.
When
we
talk
about
canadian
eventing,
that's
a
little
bit
different.
So
we
are
talking
about
producers
and
consumers
of
events.
A
So
basically,
what
I
did
in
the
application
is,
I
enabled
my
services
to
emit
events
to
a
candidate
broker
that
it's,
this
kind
of
router
right
like
and
that
broker
can
be
again
any
different
implementation.
It
can
be
kafka,
it
can
be
google
pops
up
depending
on
where
you're
running
and
what
implementation
do
you
like?
A
You
can
use
that
and
then,
basically,
what
you
need
to
do
is
you
need
to
define
candidate
triggers
which
are
subscription
for
your
events,
and
here
it's
kind
of
like
how
a
canadian
trigger
looks
like
it's
a
simple
kubernetes
resource
where
you
set
you
define
which
broker.
Do
you
need
to
look
for
events?
In
this
case
my
broker
is
called
default,
and
then
I'm
saying
that
I
want
to
send
all
the
events
that
happen
in
the
broker
into
this
url,
which
is
another
here
like
another
application
that
is
consuming
these
events.
A
You
can
also
add
filters
here
so
here
you
can
just
create
some
filters
and
define
those
filters
here
in
the
specification
for
just
if
you're
interested
in
certain
kind
of
events,
you
can
do
that.
So,
let's
take
a
look
at
how
that
works.
The
I
configure
the
application
already
to
emit
events.
As
I
mentioned,
I
have
a
broker
and
I
define
a
trigger.
That's
going
to
send
events
to
you
know
an
external
application
in
this
case
sockeye,
which
is
just
an
event
monitoring.
So
let's
take
a
look
at
that.
A
Basically,
all
the
triggers-
and
also
you
can
see
here
that
I
have
this
new
application
that
it's
called
sockeye
in
this
url
and
that's
where
I'm
just
sending
all
the
events
that
are
happening
inside
the
application.
So
if
I
go
to
the
application,
this
is
socai.
Basically
it
doesn't
have
any
cloud
event,
and
in
order
for
me
to
generate
cloud
events,
I
need
to
interact
with
the
application
right,
because
different
services
will
send
different
events.
A
One
service
received
this
request
and
basically
generated
an
event
here
that
you
can
see
like
the
proposal
received
event
from
the
proposal
service
that
was
submitted
here
right
and
it
has
the
information
that
I've
just
submitted
in
the
form
right.
I
can
keep
interacting
with
the
application,
for
example,
going
to
the
back
office
and
accepting
one
one
proposal
here,
so
I
should
be
able
to
see
that
more
events
are
generated
by
the
application.
A
Imagine
how
you
can
use
this
to
emit
events
from
your
applications,
connect
that
to
a
broker
and
then
define
the
consumers
of
these
events
in
a
declarative
way
in
kubernetes.
You
do
this
on
configuration
and
per
cluster,
and
that
gives
you
the
flexibility
of
wiring
things
up
depending
on
what
do
you
have
available
and
depending
on
what
kind
of
integrations
do
you
want
to
implement
kinetic,
inventing
provide
these
concepts
of
consumers
and
producers
of
events,
which
is
pretty
important
for
integrations
and
for
building
event
driven
architectures?
A
So
I
totally
recommend
you
to
check
that
out
as
well.
Of
course,
all
these
examples
that
I'm
showing
are
in
this
repository
for
monolith
skates
under
k
native
and
it's
step
by
step,
guides
on
how
to
run
these
examples
in
your
own
clusters,
if
you're
interested
in
doing
so
so
check
that
out.
So
after
all
these
things
that
I
show
you,
what
do
I
want
for
christmas?
A
So,
first
of
all,
I
want
a
place
where
I
can
just
build
and
package
my
software,
so
that
pretty
much
means
that
I
need
a
kubernetes
cluster
that
is
dedicated
to
these
things.
It
will
have
something
like
tekton
installed
and
all
the
infrastructure
that
I
need
in
order
to
build
and
publish
all
these
artifacts
already
wired
up
for
me
right.
I
don't
want
to
spend
time.
Configuring,
a
docker
registry
or
a
chat
repository.
I
just
want
that
to
be
configured
for
me
already,
and
I
want
also
like
service
pipeline
templates
and
environment
pipeline
templates.
A
So
every
time
that
I
need
to
add
a
new
service
into
my
applications,
I
don't
really
need
to
think
about
creating
a
new
pipeline.
I
can
just
start
from
a
template
that
it's
doing
most
of
the
things
for
me
right
same
with
environments.
If
I
want
to
create
a
new
testing
environment,
I
don't
want
to
be
thinking
about
okay.
How
do
I
create
an
environment
pipeline
for
that?
A
I
need
a
template
that
I
can
just
use
to
get
things
out
quickly
and
if
you
haven't
checked
jenkins
x,
that's
pretty
much
what
it's
doing
right
like
it's
installing
creating
a
kubernetes
cluster,
installing
tecton
in
it
in
different
cloud
providers
and
configuring
and
wiring
up
all
the
infrastructure
for
you
right
and
at
the
same
time,
providing
these.
You
know
service,
pipeline
templates
and
environment
pipeline
templates,
which
are
pretty
pretty
handy
to
get.
You
started,
you
just
install
these
and
just
start
adding
services
and
creating
environments.
So
you
should
check
this
out.
A
On
the
other
hand,
I
want
a
place
where
I
can
just
create
my
platform
abstractions
and
that
basically
means
another
kubernetes
cluster
with
crossplane
installed
and
all
the
cloud
providers
that
I'm
planning
to
support
already
configured
right,
like
all
the
right
credentials
in
place.
So
I
can
provision
in
like
compromision
components
into
these
clusters
on
the
right
hand,
here
I'm
showing
you
my
compositions
and
my
configurations
that
my
infra
team
can
create
based
on
the
cloud
providers
that
we're
planning
to
support
and
on
in
yellow
here.
A
A
If
you
haven't,
checked
out
upbound
cloud,
that's
the
company
behind
crossplane
and
they
are
providing
a
managed
service
for
crossplane,
basically,
which
is
this
right,
like
a
specific
like
their
own
kubernetes
cluster,
with
crossplane
installed,
where
you
can
just
go
there
and
configure
your
credentials
for
different
cloud
providers,
so
they
can
provision
infrastructure
for
you
as
well.
So
you
should
check
that
out
because
that's
pretty
cool
and
finally,
what
I
want
for
my
users
is
to
be
able
to
use
this
self-service
approach
right.
A
So
I
can
create
a
portal
where
they
can
just
configure
these
instances
that
they
want
to
create
that
they
want
to
provision.
They
will
be
sending
that
to
crossplane,
so
crossplane
can
go
and
create
a
dedicated,
kubernetes
cluster
for
them
with
all
the
projects
and
tools
that
are
required
for
the
application
to
run
in
there
right.
Something
that
I
haven't
showed
you
before
is
basically
crossplane,
creating
a
dedicated
cluster
for
each
customer.
A
So
at
the
end
of
the
day,
it
should
be
like
the
entire
journey
from
the
customer
defining
what
they
want,
for
this
instance
crossplane
provisioning,
a
new
cluster
installing
the
right
tools
inside
that
cluster
for
running
the
application.
All
the
tools
that
are
installed
in
there
are
just
to
make
your
developers
life
easier.
So
when
they
are
developing
the
application,
they
can
rely
on
certain
things
like
k
native
and
then
installing
the
application
that
you
know
our
customers.
A
Custom
customers
are
going
to
be
able
to
access
that
should
be
kind
of
like
the
main
goal
in
here
and,
as
you
can
see,
this
requires
a
bunch
of
kubernetes
clusters
clusters
that
will
be
created
dynamically.
But
the
good
thing
about
this
is
that
this
is
100
relying
on
the
kubernetes
apis.
It's
multi-cloud
enabled
you
can
run
all
these
tools
across
multiple
cloud
providers
without
any
restrictions.
A
So
that's
pretty
much
it.
Thank
you
very
much
for
joining
my
session.
I
recommend
you
to
check
out
my
continuous
delivery
for
kubernetes
book
that
I'm
writing
just
join
the
early
access
program
there.
If
you
have
any
other
questions,
please
feel
free
to
reach
out
via
twitter
at
salawy.
That's
my
twitter
handle
and
thank
you
very
much
see
you
next
time.