►
From YouTube: Gloo: Function Gateway with Idit Levine
Description
Visit our website
https://softwaredaily.com
Gloo is a function gateway built on top of the popular open source project Envoy. The goal of Gloo is to decouple client-facing APIs from upstream APIs. Gloo is similar to an API gateway, which is a tool that software companies can use to collect all their APIs and one place and impose security, monitoring, and other standards around those APIs.
The goal of Gloo is to provide all the tools necessary to glue together traditional and cloud-native applications. Idit Levine is the CEO of Solo.io, a company that is building Gloo and several other projects.
Transcript
Transcript provided by We Edit Podcasts. Software Engineering Daily listeners can go to weeditpodcasts.com/sed to get 20% off the first two months of audio editing and transcription services. Thanks to We Edit Podcasts for partnering with SE Daily. Please click here to view this show’s transcript.
Sponsors
Azure Container Service simplifies the deployment, management and operations of Kubernetes. You can continue to work with the tools you already know, such as Helm , and move applications to any Kubernetes deployment. Integrate with your choice of container registry, including Azure Container Registry .Also, quickly and efficiently scale to maximize your resource utilization without having to take your applications offline. Isolate your application from infrastructure failures and transparently scale the underlying infrastructure to meet growing demands—all while increasing the security, reliability, and availability of critical business workloads with Azure. Check out the Azure Container Service at aka.ms/sedaily .
GoCD is a continuous delivery tool created by ThoughtWorks. GoCD agents use Kubernetes to scale as needed. Check out gocd.org/sedaily and learn about how you can get started. GoCD was built with the learnings of the ThoughtWorks engineering team, who have talked about building the product in previous episodes of Software Engineering Daily. It’s great to see the continued progress on GoCD with the new Kubernetes integrations–and you can check it out for yourself at gocd.org/sedaily .
Every team has its own software, and every team has specific questions about that internal software stack. Stack Overflow for Teams is a private, secure home for your team’s questions and answers. No more digging through stale wikis and lost emails—give your team back the time it needs to build better products. Your engineering team already knows and loves Stack Overflow. They don’t need another tool they won’t use. Get everything that 50 million people already love about Stack Overflow in a private, secure environment with Stack Overflow for Teams. Try it today, with your first 14 days free. Go to s.tk/daily Stack Overflow for teams gives your team the answers they need to be productive–with the same interface that Stack Overflow users are familiar with.
A
Glue
is
a
function
gateway
built
on
top
of
the
popular
open-source
project
envoy.
The
goal
of
glue
is
to
decouple
client-facing
api's
from
upstream
api's
glue
is
similar
to
an
api
gateway,
which
is
a
tool
that
software
companies
can
use
to
collect
all
of
their
api
s
in
one
place
and
impose
security,
monitoring
and
other
standards
around
those
api's.
The
goal
of
glue
is
to
provide
all
the
tools
necessary
to
glue
together
traditional
and
cloud
native
applications.
Aditi
Levine
is
the
CEO
of
solo.
Do
a
company
that
is
building
glue
and
several
other
projects.
A
A
Azure
container
service
simplifies
the
deployment
management
and
operations
of
kubernetes,
eliminate
the
complicated
planning
and
deployment
of
fully
orchestrated
containerized
applications
with
kubernetes.
You
can
quickly
provision
clusters
to
be
up
and
running
in
no
time
while
simplifying
your
monitoring
and
cluster
management
through
Auto
upgrades
and
a
built-in
operations
console
avoid
being
locked
into
any
one
vendor
or
resource.
You
can
continue
to
work
with
the
tools
that
you
already
know,
such
as
helm
and
move
applications
to
any
kubernetes
deployment.
A
Integrate
with
your
choice
of
container
registry,
including
Azure
container
registry,
also
quickly
and
efficiently
scale,
to
maximize
your
resource
utilization
without
having
to
take
your
applications.
Offline,
isolate
your
application
from
infrastructure,
failures
and
transparently
scale.
The
underlying
infrastructure
to
meet
growing
demands
all
while
increasing
the
security,
reliability
and
availability
of
critical
business
workloads
with
Azure
to
learn
more
about
Azure
container
service
and
other
azure
services,
as
well
as
receive
a
free
ebook
by
Brendon
burns
go
to
aka.ms/offweb.
A
A
A
B
Actually
interesting,
but
actually
over
my
life
I'm
looking
to
start
a
company,
so
actually
the
transmission,
the
transition
to
actually
UC
was
really
strange
because
it
was
a
big
company,
so
I'm,
basically
back
home
right
because
I'm
all
my
life,
it
startups
so
yeah
I
mean
I
much
like
it,
because
I
feel
that
you
can
go
much
faster.
As
you
know,
there's
not
a
lot
of
the
overhead
of
a
big
organization,
but
then
again
there
is
a
lot
of
advantage
to
being
an
EMC.
B
B
B
Mean
it's
much
harder
because,
specifically
because
I'm,
the
only
founder,
you
need
to
do
all
the
work.
So
it's
everything
on
you.
So
you
need
to
raise
the
money
and
unity
investors
and
you
need
to
find
space
to
see
it,
and
so
there's
a
lot
a
lot
of
worried
that
you
don't
need
to
do
in
the
beginning
to
kind
of
like
jumpstart
it.
So
there
is
much
more
responsibility
right.
You
need
to
do
a
lot
of
stuff
at
all,
so
you're
responsible
for
this.
B
A
B
So,
actually,
you
know
these
markets
move
so
fast.
So
when
we
started
in
the
beginning,
what
my
my
plane
was
at
even
before
I
got
the
money.
What
I
pitch
was
regarding
service
and
actually
I
had
this
idea
for
like
over
a
year
and
so
and
it's
move
its
move
right.
So
when,
when
I
kind
of
like
came
to
a
point
that
actually
got
the
money,
I
couldn't
you
know
I
had
to?
Actually
you
know
a
twisted
a
little
bit
or
actually
what
we
did.
B
We
actually
extend
the
ID
so
before
it
was
only
about
service,
and
then
I
saw
the
movement
and
I
also
looked
and
I
figure
out
that
this
market
is
moving
under
service,
but
not
as
fast
as
I
want
anymore.
So
I
said
you
know.
We
need
also
to
kind
of
like
include
the
current
situation
of
the
market,
which
is
also
analytic
and
micro
services.
B
So
that's
what
we
basically
took
something
and
that's
how
glue
basically
was
born
right,
which
is
basically
the
beginning
drew,
was
well
we're,
probably
going
to
do
it
on
the
several
s,
and
then
you
say
you
know
what
actually
the
biggest
problem
in
the
market
right
now
is
actually
to
move
from
analytic
to
Microsoft
to
several
s.
So
what?
If
we
just
going
to
extend
it
to
be
able
to
do
everything.
A
Right,
so
you
can,
you
can
see
where
things
are
going.
You
know.
Eventually,
people
are
going
to
want
to
deploy
applications
in
a
server
list
fashion,
where
they're
not
addressing
specific
containers,
they're
just
deploying
their
applications
as
collections
of
functions,
and
they
can
perhaps
choose
whichever
cloud
provider
they
want
to
deploy
these
functions
on
to.
Maybe
they
do
it
based
on
price?
Maybe
they
do
it
based
on
performance
or
some
workload
specificity,
but
we're
not
there
today,
we're
still
in
we're
significantly
far
from
that
future.
A
B
So
exactly
right,
as
you
said,
right
now,
I'm
startup
right,
which
means
that
I
actually
also
need
customer
and
when
I
was
in
emc.
That
wasn't
my
case
right.
I
could
actually
do
whatever
crazy
project
that
I
my
job
wasn't
to
bring
customer
and
we
knew
that
you
know
we
will
have
customers,
that's
not
a
problem,
so
you
know
here
I
need
to
have
customer
and
when,
when
you're
looking
at
that,
you
know
the
market
and
you
understand
what
is
the
pain
point
right
now
for
customer?
It's
actually
not
in
several
that's
right.
B
B
The
people
are
right
now,
which
is
for
monolithic
to
micro
services,
but
I
know
that
in
the
open
source,
there's
people
right
now
have
micro
service.
Already
you
know
specifically,
you
know
they
did.
You
know
the
Google
of
the
world,
but
they
might
want
it
to
kind
of,
like
also
move
to
server
less
and
basically
glue
this
environment.
That's
why
glue
basically
glue
this
type
of
application
together
to
one
application
and
that's
basically,
all
your
sketch
and
that
way,
I'm
playing
and
I
can
get
customer.
A
So
if
I
think
about
your
product,
Glu
they're
there
or
the
the
thrust
of
your
your
set
of
products,
the
idea
is
that
let's
say
you
are
Procter
&
Gamble
and
you
have
all
of
these
legacy.
Applications
internally
and
you've
also
got
perhaps
some
newer
applications.
Somebody
within
Procter
and
Gamble
has
spun
up
a
kubernetes
cluster
and
it
does
new
things
and
it
does
new
things
that
would
ideally
leverage
the
old
things.
Perhaps
you've
got
an
old
inventory
management
service
and
you've.
A
You
know
you've
got
some
API
in
front
of
it
that
you've
built,
but
you
need
to
be
able
to
glue
together
that
legacy
API
and
your
newer
kubernetes
installation,
for
example.
So
you
want
to
be
able
to
glue
those
two
things
together.
Am
I
or
maybe
you've
done
MA
and
you've
got
three.
You
know
three
different
companies
you've
just
acquired
and
you
want
to
glue
those
those
acquisitions
to
your
existing
applications.
Are
those
some
of
the
use
cases
that
you
you're,
trying
to
it
you're
trying
to
appraise
here
so.
B
Glue
can
do
that
as
well,
but
what
I
think
that
is
more
important
is
the
fact
that
a
lot
of
the
enterprise
today
that
has
a
monolithic
application,
everything
that
they
doing
new,
which
is
I,
know
greenfield.
They
will
do
on
kubernetes
right,
but
the
old
things
are
still
there
and
usually
what
they
doing
there.
They
decided
to
rewrite
them,
write
refactor
them,
that's
the
biggest
problem
today.
Now
there
is
two
way
to
do
that.
The
first
time.
The
first
way
to
do
it
is
just
said:
well,
we
need
to
get
to
a
point.
B
We
were
rewriting
all
this
monster:
monolithic
application
to
a
micro
services.
That's
one
option,
but
that's
a
lot
of
the
time.
It's
just
not
successful,
because
there
is
a
lot
of
functionality.
It's
very
complex
and
and
more
worried
is
that,
even
if
you
do
try
to
do
that,
you're,
not
writing
any
new
feature.
B
On
this
time,
right
I
mean
I,
had
a
customer,
for
instance,
that
you
know
he
had
a
monolithic
application
and
they
really
wanted
to
move
actually
all
the
way
to
server
less
so
they
basically,
you
know,
went
to
their
boss
and
said:
look
we
want
to
rewrite
it.
It
would
be
so
much
better.
We
can
run
faster
right.
Everything
would
be
so
much
easier
for
us,
so
the
boss
said
tell
us
how
much
time
it
will
take
you.
So
the
Wendon
did
a
research.
They
came
back,
they
said.
B
Well,
it
will
take
us
a
nine-month
and
the
boss
said
so.
No,
and
here
is
why,
because
that
means
two
things
a
is
that
probably,
if
we're
not
going
to
take
you
only
nine
months,
it's
probably
would
take
a
year
or
a
year
and
a
half,
and
the
next
problem
is
that
on
all
this
year,
I
didn't
get
even
one
feature,
which
means
that
I
will
get
fired
right.
It's
like
you
know
you
innovating
a
new
room,
but
you
only
doing
piping
in
the
end
of
the
day.
You
know
you
can
see
that
right.
B
So
so
so
that's
basically
what
we're
trying
to
do,
what
we're
basically
telling
our
customers.
We
want
you
to
extend
the
new
functionality
to
the
you
know
of
this
application
to
microservices
and
server
less,
and
we
will
glue
it
like
it's
one
application
and
then
a
new
spirit
time,
because
we're
cutting
all
of
and
I
will
explain
in
a
second
but
we're
cutting
basically
we're
breaking
your
monolithic
application
to
function.
You,
which
is
really
small
unit
of
compute.
B
You
can
actually
move
them
piece
by
piece
gradually
when
your
time
and
and
you
know
it's
one
of
these
I
mean
then
it'll
learn
new
tools.
Right
I
mean
if
you're
doing
monolithic
application.
You
will
use
something
like
puppet
share.
Fancy
ball,
you
will
have
I,
don't
know
Splunk
for
logs
and
you
will
have
a
probably
SOA
architecture
when
you
move
into
micro
service,
it's
all
bunch
of
new
tools
right,
because
now
it's
distributed
application,
so
you
will
use
something
like
permit
use
and
we
use
something
like
open-open
tracing.
B
They
need
to
learn,
and
basically
what
we
give
them
is
time,
because
we
tell
them
first
of
all,
you're
already
going
to
the
right
direction,
because
we're
basically
adding
server
less
and
micro
services
in
the
new
features,
but
also
we're
giving
you
the
ability
to
gradually
move
it
with
no
rush.
Ok,.
A
B
So
so,
first
of
all,
I
would
start
by
saying
that
glue
is
a
platform
in.
The
point
is
that
this
is
the
base
project.
It's
a
kubernetes
in
the
terms
of
like
we
needed
it
in
in
order
to
build
what
we
really
want
right
and
now
we're
going
to
come
with
a
lot
of
small
product
that
you
will
see
in
the
market.
So
what
is
glue
so
so?
Basically
we,
you
know,
we
are
in
the
open
source
and
envoi
is
the
best
proxy
I
mean.
B
B
So
if
you're
looking
at
you
know
today,
you
have
my
own
monolithic
micro
services
and
service,
which
is
basically
function,
but
if
you
think
about
it,
the
monolithic
is
also
built
from
exposed,
API
function
and
actually
also
the
microservices
is
basically
built
for
my
exposed
API
function.
So,
if
I'm
actually
manage
to
discover
all
of
them
in
the
monolithic
in
the
micro
service
and
in
the
service
all
the
function
now,
I
can
actually
assemble
application
from
these
pieces.
So
what
I
need
to
do
in
order
to
do
something
like
this
right?
B
We
need
to
a
basically
break
the
application,
which
is
mean,
discover
the
function
and
be
able
to
route
to
them,
and
that's
what
we
do
we'll
be
doing
that
with
two
things.
We
have
a
discovery
service
that
it's
a
discover
all
your
infrastructure
in
terms
of
you
know
the
regular
upstream
so
like
kubernetes
and
co-founder
e
and
everything
we
discover
and
also
you
know
your
AWS
instances
and
then
the
the
other
thing
that
we
doing
with
discovering
functions.
B
So
if
it's
several
as
it's
easy,
just
a
REST
API,
but
but
if,
but
if
it's
not,
we
basically
supporting
swagger,
so
open
API,
basically
and
are
at
your
PC.
So
if
you
using
one
of
those
we'll
be
able
to
basically
get
the
specification
of
the
functions
so
now,
assuming
that
I
took
all
your
application
and
managed
to
break
them
to
you
not
to
break
them
by
discover
the
function
and
them
now,
the
only
thing
that
I
need
is
to
be
basically
be
able
to
route
those
function,
and
that's
why
we
use
envoi.
B
So
what
does
it
mean
in
route
to
a
function?
So
envoi
is
the
best,
for
my
opinion,
proxy
that
exists
there.
It's
worked
very
well
with
our
use
case.
The
only
thing
is
that
we
wanted
to
extend
it
to
round
on
the
function
level,
because
today,
every
proxy
that
exists
usually
route
from
route
to
a
cost
or
service.
So
we
did.
We
basically
use
the
filters
of
envoi
and
extend
the
filter
with
a
base
filter
to
actually
write
down
the
function
level.
B
So
now
every
feature
that
you
can
get
to
the
invoice
in
the
regular
level.
I,
don't
know
we're
doing,
meeting
security
and
so
on
transformation
to
the
restaurant.
Now
you
can
actually
get
it
on
the
function
level.
So
a
mission
canary
of
function,
donor
services,
so
we
did
that
we
have
standard.
Besides
that
we
wanted
to
extend.
You
know
we
wanted
to
make
it
very
easy
for
the
user
and
we
thought
that
if
it
will
be
on
the
request,
but
we
would
be
able
to
manipulate
the
code,
you
know
the
calls.
So
what
we
did.
B
We
basically
put
there
a
lot
of
created
a
lot
of
filter
that
really
relatively
it's
basically
working
very
well
with
functions.
So,
for
instance,
they
call
for
AWS,
with
the
signature
already
transformation
filter
to
transfer
from
any
language
from
JSON,
for
instance,
to
algae
OPC,
to
HTTP
and
so
on.
So
we
did
all
of
this,
so
what
we
created
is
basically
we
took
Android
and
extend
its
functionality
to
work
with
very
well
with
functions
and
route
on
the
function
level.
So
that's
the
first
thing,
but
now
it's
invoice
oil.
B
We
basically
need
to
manage
it
and
what
we
build
we
build
glue
and
what
glue
is
basically
it's
a
service
that
watching
three
things.
The
first
thing
that
is
watching
is
up
streams
and
function.
Basically,
the
discovery
that
we
do.
The
second
thing
that
is
watching
is
the
secret,
so
we're
supporting
right
now,
kubernetes,
secret
and
vault,
and
the
last
thing
that
we
are
watching
is
the
configuration.
B
So
these
are
configuration
so
we're
using
right
now,
either
Yama
C
or
these
a
console,
and
if
one
of
those
change
glue
getting
this
information,
but
it
doesn't
understand
anything
and
the
only
thing
that
is
doing
is
basically
saying
it
to
a
plug-in.
So,
basically,
all
the
logic
of
glue
is
in
the
plugin,
which
means
that
it's
really
extensible
so
for
us
to
add
feature
support
something.
The
only
thing
we
need
to
do
is
basically
add
a
plug-in
and
maybe
a
filter
in
and
and
we
basically
define
our
language.
We
a
click,
an
external
language.
A
Go
CD
is
a
continuous
delivery
tool
created
by
thought,
works,
it's
open
source
and
free
to
use
and
go
CD
has
all
the
features
you
need
for
continuous
delivery
model.
Your
deployment
pipelines
without
installing
any
plugins
use
the
value
stream
map
to
visualize
your
end-to-end
workflow,
and
if
you
use
kubernetes,
go
CD
is
a
natural
fit
to
add
continuous
delivery
to
your
project
with
go
CD
running
on
kubernetes,
you
define
your
build
workflow
and
let
go
CD
provision
and
scale
your
infrastructure
on
the
fly.
Go
CD
agents
use
kubernetes
to
scale
as
needed.
A
Checkout
go
CD,
org,
slash,
SE,
daily
and
learn
about
how
you
can
get
started.
Go
CD
was
built
with
the
learnings
of
the
thought,
works
engineering
team
who
have
talked
about
building
the
product
in
previous
episodes
of
software
engineering
daily,
and
it's
great
to
see
the
continued
progress
on
go
CD
with
the
new
kubernetes
integrations.
You
can
check
it
out
for
yourself
at
go.
Cd,
org,
slash,
SE
daily,
and
thank
you
so
much.
A
From
a
technical
point
of
view,
I
understand
what
you're
building
I
want
to
put
it
in
the
context
of
a
large
enterprise
that
is
doing
this
cloud
native
or
micro-services
migration,
so
they're
they're
doing
containerization
they're,
building
out
CI
CD
pipeline
they're
instrumenting
observability
across
their
application.
We're.
B
B
The
first
thing
that
they
will
do,
they
will
install
glue
and
it
will
discover
all
the
environment.
So
no
matter
how
much
cluster
there
is
on
which
type
of
platform
it
is
or
where
it
is
which
cloud
it
is,
they
will
discover,
although
all
the
application,
that's
right.
So
now,
if
we
know
the
application
that
is
running
now,
they
can
start
manage
them.
And
what
good
about
glue
is
that
you,
basically
that's
Wake
and
I-
can
show
you
a
demo
with
it
it's
basically,
you
can
actually
take
him
on
a
little
application.
B
I,
don't
know
pet
store,
something
like
that
reading
in
Java
and
start
basically
extended
it
by
writing.
I,
don't
know
service
or
micro
services
and
then
tell
glue
now
extend
that.
So
we
basically,
if
you
think,
about
via
multiplexer,
so
we
totally
separate
the
the
client
from
the
server
right.
So
basically
can
a
take
this
monolithic
application
and
said
now:
I
write
an
extension
piece
in
micro
services.
So
that
way
you
basically
can
tell
glue
to
extend
the
API.
B
So
now
you
basically
have
one
application
that
is
part
of
it
is
going
to
monolithic
and
part
of
it
is
going
to
micro
services
and
then
the
next
step
will
be
maybe
to
start
rewrite.
So
this
organization
will
go
and
say
well,
I'm
going
to
take
this
piece
and
I
will
rewrite
it
and
again
glue
will
be
the
one
who
basically
make
sure
that
you
will.
Basically
you
know
route
it
to
a
different
place
to
the
new
functionality.
B
So
that's
that,
besides
that
we
also
in
the
request
path
and
because
we're
on
the
request,
but
we
can
help
with
other.
So,
for
instance,
if
right
now,
you're
moving
your
application
form
analytic
to
microservices.
It
will
be
a
point
that
most
of
your
functionality
will
be
in
monolithic,
but
some
of
them
will
be
in
micro
services,
so
server
less.
So
the
big
question
right
now
is
how
you
monitor
it
right.
Why
you,
using
the
out
that
is
going
to
work?
You
need
to
monitor.
You
need
to
want
to
get
the
logs.
You
need
to.
B
You,
know
debug
it,
but
now
it's
you
deploy
it,
and
it's
now
in
three
separate
place.
So
what
we
doing
is
because
we
are
on
the
request,
but
we
basically
has
the
ability,
because
we
invoking
and
every
function
we
can
actually
suck
the
information
from
the
other
platform
and
bring
into
one
place.
So,
for
instance,
if
you're
running
application,
that
is
a
monolithic
running
on
VMware
infrastructure,
then
you
have
kubernetes
cluster
and
you're
running
there,
one
micro
services,
and
then
you
have
also
a
SS
lambda
that
you're
running
what
we're
going
to
do.
B
We
basically
going
to
suck
the
logs
for
models
with
these
places
and
suck
the
day.
You
know
their
metrics
and
basically
give
it
to
one
place,
so
it
will
be
I,
don't
know,
for
instance,
Prometheus
right
data
row
or
anything
else,
so
that
so
that's
that
the
same
thing
will
open
open
tracing
we're
basically
going
to
take
all
the
information
from
the
function
and
monolithic
and
the
micro
service,
fit
it
to
open
tracing.
B
So
now
you
can
see
actually
a
span
that
some
of
it
is
monolithic,
some
of
them
in
microservice,
and
some
of
them
is
serviced
which
I
think
really
cool.
And
the
last
thing
is
that
we
also
build
squash,
which
is
basically
debugger
for
distributed
application,
which
you
can
actually
attach.
Debugger
I
mean
we're
doing
it
very,
very
nice
user
interface
whip
from
the
IDE.
You
can
attach
the
monolithic
application
and
reading
in
Java
to
a
Java
debugger.
You
can
attach
the
microservice
reading
in
go
to
school.
A
Yeah
I
believe
you
and
and
people
can
definitely
check
it
out
by
going
to
solo
dot
IO.
So
can
you
help
me
understand
how
a
company
would
integrate
with
with
glue
like
we're
along
the
path?
Do
I
do
I
spin
it
up
and
how
so
you
said
it
does.
It
can
discover
all
of
the
services
that
I'm
running.
How
does
it
do
that
like?
How
does
it
plug
into
my
existing
infrastructure
so.
B
If,
for
instance,
let's
just
take
an
example,
I
said
that
you
have
a
VMware
and
you
have
a
kubernetes
and
you're
also
using
aw.
That's
just
back
of
it
for
the
example,
so
we're
basically
going
to
kubernetes
ask
for
the
world.
They
they
upstream
that's
easy,
and
then
we
also
looking
at
each
of
the
us
upstream
to
see
if
you
have
any
function
that
we
can
recognize.
For
instance,
if
you're
running
on
this
service
in
micro,
you
know
on
could
be
that
is
you're
running,
let's
say
application
which
water.
B
So
we
collect
that
as
well
right,
so
we're
basically
going
to
find
all
your
workload
cross
clusters
and
then,
besides
that
also
the
function
that
running
on
top
of
them
and
also
there.
You
know
the
regular
applications
are
running
on
top
of
it.
So
now,
if
we
know
that
we
can
act
as
a
a
regular
API
gateway,
because
you
know
by
far
the
way
we
build
it.
I
think
that
there
is
no
question.
We
are
the
best
API
get
whether
existed
in
the
market,
but
also
you
can.
B
It
will
give
you
a
lot
a
lot
of
tools
to
actually
make
way
those
application
in
case
you
want.
So
again,
you
decided
that
you
want
to
take
application
a
and
you
want
to
move
it
to
somewhere
L.
You
know
to
a
micro
services,
that's
where
you
will
basically
use
glue.
That's
one
one
option:
the
other
option
is
that,
if
you're
looking
a
lot
of
the
offer
today
like,
for
instance,
just
for
a
bit
Cloud
Foundry
they're
using
kubernetes
and
Cloud
Foundry
today,
so
they
have
like
the
container
runtime
and
also
the
application
runtime.
B
There
is
nothing
that
makes
them
work
together
besides
Bosh
who
is
deploying
them.
So
we
need
something
to
glue
that
together
one
place
that
people
can
actually
see
all
the
workload
and
you
know
maybe
create
an
application
that
some
of
them
living
in
in
this
cluster
and
the
other
one
living
in
that
data
cluster.
That's
where
glue
can
help
us
well
right.
So,
if
you
think
about
it,
there
is
so
much
overdue
there.
B
In
the
market
there
is
docker
we're
also
giving
stalkers
warm,
and
there
is
a
DCOs,
a
mesosphere
that
basically
offering
this
us,
but
also
cubanelle
is
there
is
I.
You
know
Cloud
Foundry,
as
we
said,
so
there
is
a
lot
of
a
lot
of
you
know,
kind
of,
but
from
the
today
when
you're
building
them
they're,
basically
giving
you
two
different
clusters
that
are
totally
silos
and
and
I
think
well
glue
can
help
is
basically
glue
them
together
as
well.
You.
A
B
So
API
gateways
is
not
me
right.
It
was
like
I
think
there
was
a
lot
of
company
that
spin
up
before,
like
apples
and
so
on,
and
basically
the
API
is
the
idea
of
instead
of
managing
API
of
each
server
right.
So
you
have
a
lot
of
workload
and
each
of
them
has
an
API.
They
basically
abstract
that
and
manage
that
in
one
place,
and
now
you
have
a
way
to
actually
configure
it
them
on
so,
for
instance,
security.
B
B
You
know
again
that
the
API
get
we're
usually
giving
you
like,
for
instance,
first
of
all,
giving
you
metrics
and
monitoring
and
tracing
that's
something
that
usually
they
giving
out
of
the
box
and
but
they're
also
giving
you
you
know
all
of
these.
The
regular
functionality
of
the
security
that
they're
putting
on
top
of
it.
The
management
itself,
transformation,
some
time
and
so
on.
So.
A
The
purpose
of
an
API
gateway
is
like
I'm,
a
company
and
I've
got
five
development
teams.
One
is
building
the
sales.
Software
and
they've
got
their
own
servers
and
can
Tanner's,
perhaps
and
the
other
that
you
know
then
there's
a
marketing
software
team
and
they
were
building
the
marketing
software
and
sauna
completely.
B
Security
management
orchestrated
right,
that's
basically
the
three
things
that
you
will
want
to
manage
by
API
get
right.
But
again
it's
one
place
that
Minister
as
I
said:
I
have
you
know
five
team,
a
lot
of
application,
but
in
you
know
the
day,
I
can
see
and
manage
all
the
API
in
one
place
and
make
sure
that
your
answer.
So
this
is
on
day.
B
This
is
what
it's
api
gateway
and
what
we're
putting
on
top
of
it
is
the
fact
that
we
also,
basically
because
we
want
them
to
move
to
one
of
the
big
use
case
that
we
wanted
to
applies
to
the
migration
between
monolithic
and
micro
services.
It
was
important
to
us
to
do
everything
like
people
doing
on
the
service
level,
but
on
the
function
level.
That
way
there
is
smallest
pieces
that
they
will
need
to
be
great
each
time
and
that's
giving
them.
A
B
We
can
do
both
way.
I
mean
we
can
actually
complement
that
the
api
getaway
that
they
have
the
current
one,
but
to
be
fair,
I
do
believe
that
the
who
is
the
best
hindi
I
get
rid
that
exists
there.
So
you
know
I
will
recommend
them
to
already
take
that
as
also
the
API
gateway
and
get
the
both
functionality.
But
again
we
also
can
work
site
next
to
the
next
to
the
the
legacy
API
gateways
right.
A
B
There
is
a
few
way.
One
one
way
is
just
we're
going
to
sack
the
information
from
the
regular
API
gateway
to
basically
do
a
chaining
of
proxies,
which
is
not
the
nicest
way.
But
if
you
really
really
want
to
use
your
API
get
ready,
that's
one
approach
to
do,
which
is
basically
a
chain
of
proxies
which
mean
that
every
time
that
we
curse
will
come,
it
will
go
to
the
one
API
ghetto
which
is
there.
B
You
know
the
legacy
one
and
we'll
you
know,
do
the
routing
based
on
this
and
then,
if
we
move
to
glue,
will
basically
apply
it
more
on
the
function
level.
That's
one
option
and
the
other
option
is
just
basically
to
totally
dismiss
the
other
one,
which
is
basically
just
distract
the
information
that
he
has
and
basically
take
over
and.
A
B
Again,
I
think
that
the
difference
between
us
or
any
API
get
raised
a
use
case
that
we
are
targeting
and
all
the
things
that
we're
doing
in
glue
today
is
all
about
migration.
Take
a
monolithic
application,
transfer
it
to
a
micro
services,
transfer
it
to
a
server
list
right.
So,
basically,
that's
why
we
targeting
so
a
lot
of
these
features
that
you
will
get
will
be
on
that
level.
B
I
will
give
you
an
example
if
we
already,
basically
taking
all
the
infrastructure
and
kind
of
breaking
it
to
function,
you're
not
really,
but
basically
you
can
call
it
that
way.
So,
a
lot
of
the
stuff
happening
on
the
ecosystem
of
the
function
like,
for
instance,
event-driven
architecture,
it's
very
popular
in
functions
right.
We
can
bring
it
to
the
ecosystem,
because
now
everything
is
a
function,
something
like
workflow
that
very
popular
in
in
this
in
the
function
level.
B
So
a
lot
of
this
functionality
that
none
of
the
you
know,
none
of
the
API
gateway
exists
today.
Besides
that,
as
I
said,
most
of
the
regular
API
curator
are
not
going
to
give
you
a
discovery,
that's
not
something
that
people
usually
doing
and
the
other
one
that
we're
giving
that
RL
is
not
giving
is
a
lot
of
assets.
We
can
do
a
lot
of
transformation
because
we're
doing
it
on
the
function
level,
because
we
know
what
the
function
is.
So
we
can
actually
transform
we're
doing
a
lot
of
security
which
that's
everybody
will
give.
B
A
B
I
mean
that
you
can
actually
do
a
quest
response
transformation.
Let
me
give
you
an
example
today,
when
you're
actually
running
your
lambda,
usually
what
it's
giving
you
back,
it's
a
JSON,
but
if
I
want
this
response
to
actually
show
in
a
you
know
in
a
browser,
I
want
to
return
an
HTML,
for
instance,
that's
something
that
we
will
do
for
you.
So
basically
you
can
say:
I
want
to
transform
this
situation
request
to
an
HTML,
and
basically
it
will
again
we
own
the
request
path.
So
we
can
do
a
lot
of
remediation
that
way.
B
So
that's
an
example.
I
said
that
you
have
a
back-end
of
GOP,
see
you
wanted
to
change
your
back
into
a
geo
PC,
but
you're
still
using
the
old
client,
which
is
Knology
IP
saying
so
what
we
basically
can
do
is
transform
it
between
that.
If,
and
that
way
you
will
not
need
to
write
a
full
new
client
here,
we
see
if
it
makes
sense,
so
that's
kind
of
like
a
lot
of
the
stuff.
B
So
imagine
basically
what
the
transformation
is
giving
us,
which
I
think
is
really
strong,
is
the
real
way
to
decouple
the
client
from
the
server.
And
today
it's
not
like
this,
because
I
will
give
you
an
example.
Let's
say
that
I
have
a
server
and
in
the
service
I
have
you,
know
the
domain,
and
then
I
have
the
you
know
the
api
pack.
Basically,
we
could
wait.
We
work
with
most
of
the
proxy.
They
will
remove.
You
know
the
initial
you
know
domain
and
so
on.
B
But
that
means
that
on
the
back
end
of
the
service,
you
need
to
have
this
displace
a
clip
ax.
So
if
you
had
just
for
a
community,
did
you
know?
I
did
version
one,
but
you
need
to
have
this
part
in
the
service,
not
in
our
case,
because
we
totally
decouple
it.
So
that's
another
example.
So
basically
we
really
will
decoupling
all
the
client
from
the
back
end.
That's
giving
you
a
lot
of
use
cases
for
friends
for
transforms
again.
You
know,
transfer
Mesa,
you
know
soap
to
rest
and
so
and.
A
B
Basically,
Android
is
our
proxy,
which
means
that
we're
basically
defining
him
on
any
request.
What
is
the
route
that
I
need
to
go
and
we're
putting
some
filters
on
it,
and
basically
we
can.
You
know
we're
getting
the
request
and
we
can
do
you
know
we
can
route
to
the
right
place,
but
we
can
also
do
a
lot
of
apply
a
lot
of
stuff
on
it.
So,
for
instance,
we
can,
as
a
setting
in,
for
instance,
in
AWS
you're,
basically
putting
the
signature,
because
we
know
the
secret
so
we're
basically
putting
the
signature.
B
So
that
way,
the
user
doesn't
need
to
take
care
at
all
about.
You
know
applying
gaya
keys
and
so
on,
and
we
could
do
a
lot
of
other
stuff.
So
basically,
what
we're
doing
is
we're
writing
filter.
This
is
the
way
to
work
with
envoi
and
you
can
put
a
lot
of
functionality,
atom
functionality
that
will
imply
on
the
own
on
the
request
path
on
there
is
response
actually
as
well.
So
so
that's
what
we
did
so
this
is
basically
the
proxy.
But
now
you
need
to
manage
the
proxy.
B
You
need
to
tell
you
what,
where
to
route,
how
to
route
you
know
on
and
that's
what
basically
glue
doing
or
they
be
I
get
way.
Scale
basically
is,
is
giving
a
configuration
to
envoi
to
know
what
you
know,
what
to
do.
Basically,
what's
make
sense,
and
also
you
know,
because
its
own
voice,
oh,
and
we
already
have
filter
like
stats,
D
and,
and
you
know,
open
tracing
and
so
on
that
we
can
actually
leverage
for
metrics
and
so
on.
So
so
again
we
will.
B
Okay,
so,
okay,
so
ask
you:
is
this
service
mesh?
That
means
that
on
every
every
microservices
that
running
in
your
you
know
on
your
your
infrastructure
on
your
on
your
cubanelle?
If
you
also
put
it
next
to
it
a
sidecar
with
a
proxy,
and
then
you
also
trick
this
sidecar
to
always
talk
only
to
this
envoi,
which
means
that
that
way,
the
all-day
you
know,
traffic
in
and
out
this
service
is
going
through
and
what
so
now
I
can
manipulate
that
right.
So
now
imagine
that
you
have
actually
this
all
over
the
cluster.
B
Now
you
basically
can
create
mesh,
because
all
those
invoice
add
car
capable
of
talking
between
themselves.
That's
what
service
mushy
is
doing.
What
glue
right
now
is
basically
using
as
an
ingress
by
using
an
ingress
is
doing
some
stuff
that,
maybe
you
don't
need
to
do
in
a
mesh.
That's
number
one
number
two,
you
know
is
not
deployed
as
as
a
mesh
we
mean
that
when
we
are
routing
for
envoi
there
is
one
number
that
route
you
to
this
service
itself
to
the
micro
services
so
packed,
but
to
be
fair,
we
are
in
glue.
B
We
can
actually
also
do
service
management.
Just
know
I
mean
it
is
a
service
management
just
not
using
it
as
one.
So
basically
we
can
give
a
multi
and
vojta
configuration
to
different
animals,
so
for
instance,
but
we
yeah
so
I
mean
we
can
be
a
service
ministry.
Just
you
know,
there's
already
STS.
So
there's
no
point
can.
A
B
I
mean,
as
I
said,
I
mean
a
good
example
is
a
customer
that
basically
wanted
to
move
from
one
only
because
I
said
this
is
the
target
that
we
are
that
we
are
basically
targeting.
So
you
know
that
would
be
our
customer,
so
they
basically
wanted
to
move
from
analytic
to
micro
services.
They
actually
decided
to
use
glue
as
the
API
get
ready,
so
that
was
kind
of
like
easy
for
us
basically
put
glue.
We
discover
all
the
environment
they
wanted
to
move
for.
B
Actually
they
want
AWS
and
what
they
wanted
to
do
is
to
migrate
their
monolithic
application
to
urbanize.
What
we
did
is
we
basically
ran
in
kubernetes,
discover
also
the
instances
of
the
ws,
and
when
we
did,
we
basically
manage
them,
both
so
all
the
API
or
the
immigration
and
so
on,
and
then
we
basically
let
them
extend
new
functionality
and
kubernetes
when
they
wanted,
they
would
be
able
to.
B
You
know,
rewrite
the
pieces
and
basically
move
them
to
a
micro
services
and
all
of
these
being
managed
by
could,
in
the
terms
of
like
that,
you
can
apply.
You
know
you're,
basically
changing
the
route
and
it's
working
and
and
and
envoi
is
so
good
that
it's
like
we're
using
the
M,
the
ADSA
API
v2
API.
So
it's
so
fast
is
so
efficient.
B
So
you
can
easily
change
the
you
know:
don't
go
to
these
micro
server,
the
those
monolithic
just
go
to
these
micro
services,
so
that's
an
example
of
basically
nicely
integrated
application
for
monolithic
to
micro
service
and,
if
you
think
about
it,
this
is
the
reason
that
Anwar
was
built
right.
I
mean
I
mean
it
was
before
every
company
that
did
a
really
great
in
like
this
from
Twitter
to
live.
Basically,
they
were
using
proxies
and
I
think
that
the
reason
lift
was
actually
building
and
volume
at
client
build
and
voice.
B
Because
of
exactly
this,
they
wanted
to
move
from
analytic
to
micro
services.
So
today
everybody
talking
in
any
voice
to
use
case,
usually
using
a
service
mesh
contacts
which
is
visibility,
observer
ability
and
security,
but
I
think
that
they
are
missing
the
fact
that
one
that
the
first
purpose
of
actually
building
it
was
migration.
And
that's
where
we
kind
of
like
clever.
A
Every
team
has
its
own
software,
and
every
team
has
specific
questions
about
that.
Internal
software,
Stack
Overflow
for
teams
is
a
private,
secure
home
for
your
teams,
questions
and
answers.
No
more
digging
through
stale
wiki's
and
lost
emails.
Give
your
team
back
the
time
it
needs
to
build
better
products.
Your
engineering
team
already
knows
and
loves
Stack
Overflow.
They
don't
need
another
tool
that
they
won't
use,
get
everything
that
50
million
people
already
love
about
Stack
Overflow
in
a
private,
secure
environment
with
Stack
Overflow.
A
Four
teams
try
it
today,
with
your
first
14
days,
free
go
to
s
dot,
TK
/,
daily
Stack
Overflow
for
teams
gives
your
team
that
the
answers
they
need
to
be
productive
with
the
same
interface
that
Stack
Overflow
users
are
familiar
with.
Go
to
s,
TK
slash
daily,
to
try
it.
Today,
with
your
first
14
days,
free
Thank,
You,
Stack,
Overflow,
four
teams.
A
Right,
okay,
I
think
I,
understand
it
now.
So
envoy
is
a
service
proxy
and
you
use
envoy.
You
instrument
all
of
your
different
services
with
an
envoy
agent,
and
what
envoy
allows
you
to
do.
Is
things
like
like
changing
your
routing
on
the
fly
or
doing
circuit,
breaking
or
being
able
to
I?
Think
with
envoy,
you
can
do
things
like
routing,
you
know
person
a
percentage
of
your
traffic
from
you
know:
30
percent
of
your
traffic
to
the
new
service,
so
that
you
can.
You
know
if
you're
rolling
out
a
new
instance
of
a
service.
A
Then
you
want
to
route.
You
know
10
percent
of
your
traffic
to
it
to
make
sure
it's
stable
before
you
route,
100
percent
of
your
traffic
to
that
new
service,
and
so
you've
got
all
of
your
containers
or
your
your
servers
instrumented
with
envoy,
and
what
you're
saying
is
that
glue
is
useful
for
a
migration,
because
you
are
that
you,
you
want
to
maintain
all
of
your
API
from
your
API
gateway.
A
You
know
percentages
of
traffic
changes
in
order
to
test
it
over
time
and
gradually
move
it
to
larger
and
larger
percentages
to
the
whatever
medium
you're
migrating
to
if
you're
migrating
from
a
monolith
to
micro-services
or
you're
migrating
from
an
on-prem
system
to
the
cloud
or
doing
hybrid
stuff.
Where
you
want
to
route,
you
know
the
you
know.
If
you
have
a
bursty
workload,
maybe
you
route,
the
the
burstiness
to
you
know
to
the
to
the
cloud.
For
example,
am
I
understanding
things
correctly?
I
mean.
B
That's
one
of
these
case,
but
that
C
will
get
run
anyway.
A
lot
of
others
like
retry,
circus,
breaking
I
mean
traffic
shifting
blue/green
deployment
canary
deployment
right.
All
of
this
you
will
get,
but
we
also
even
doing
that
more
because
we
want
also
the
ability
to
actually
change
the
route
right
but
again
on
the
function
level
to
the
right
to
the
you
know
when
you
actually
migrating
so
right
now,
if
we
taking
it
and
we're
saying
we
have
a
monolithic
application,
there
is
ten
API
for
it.
B
B
So,
basically,
you
have
one
application
that
some
of
it
is
the
monolithic
some
of
it
is
a
micro
services
and
so
on,
and
that's
giving
you
the
just
came
you
time
to
actually,
instead
of
taking
and
do
a
blow
out
kind
of
like
rewrite
of
all
the
monolithic
you
can
actually
cut
it
to
an
API
calls.
It
makes
sense
and
take
part
of
the
application,
and
that's
as
I
said
this
is
the
immigration
that
being
done
everywhere
in
the
lift
in
twitter
at
sun.
Can.
B
Right
now,
I
have
a
Java
monolithic,
application.
Okay,
it's
exposed
ten
function.
Okay,
ten
function
that
you
can
call
it
and
let's
make
it
easier.
Let's
say
that
I
have
calculator
application
and
it's
key
doing
you
know,
plus
you
know,
multiply
and
divided,
and
so
I
have
four
function
that
actually
obstruct.
You
know
expose
under
monolithic
application.
So
now,
let's
say
that
I
wanted
to
meet
great
this
application.
One
way
to
do
that,
it's
just
to
go
and
rewrite
all
of
this
as
a
microservices.
Okay.
B
Now
this
is
a
simple
example,
but
theoretically,
let's
assume
that
it's
you
know,
I
need
to
create
five
microservices
for
it,
though
you
know
what
for
function,
let's
go
because
it
would
be
easier
and
the
server
less
okay.
So
that's
will
take
me
time
right.
Usually
it's
not
that
simple
application,
which
means
that
we
need
to
rewrite
all
these
applications
will
take
me
time.
B
That's
what
people
doing
today,
they're
trying
to
take
this
monolithic
application
and
rewrite
all
in
either
function
of
service,
but
anyway,
learning
idiom
is
basically
said:
okay,
let's
continue
route
every
time,
the
term
I'm
doing
+,
o
multi
PI
I'm.
Still
logged
into
the
monolithic
application,
but
then
I
will
take
the
divide,
function
and
only
eat
I'm,
going
to
rewrite
it
and
put
it
as
function
like
a
service
function.
Okay,
so
what
will
happen
right
now?
Is
this
I?
Have
this
monolithic
application?
B
It's
still
theoretically
expected
they
are
still
full
functionally
right,
but
only
when
someone
will
call
+
and
multiply
it
will
go
to
the
monolithic
and
when
the
customer
will
the
client
right
now,
we'll
call
divided
to
go
to
the
function,
basically
running
one
application
to
the
user.
It
would
be
same
thing
right.
You
see,
Cox
/,
something
right,
I
mean
it's
totally.
Look
to
him
like
a
regular
client,
but
on
the
back
end
what's
happening
is
that
tree
of
the
function
will
be
calling
the
monolithic
application.
A
B
This,
if
now
for
this
now
you
have
this
application,
which
is
totally
separate
right,
it's
different
type
and
so
on.
You
still
want
to
reach
right.
You
still
need
to
do
circus
braking.
You
still
want
to
make
sure
that
the
rate
limiting
is
working.
You
still
need
to
do
the
traffic
shifting
blue/green.
All
of
this,
you
still
want
to
be
applied,
so
it
will,
but
now
it
will
do
it
like
you
know,
even
though
that
your
application
is,
you
know,
spread
it
around.
It
will
basically
animal
will
take
care
of
all
I
hope.
It's
makes.
A
Yeah
no
understood
so
I
want
to
talk
about
the
broader
kubernetes
ecosystem,
because
you
have
you
have
an
idea
for
how
things
are
going
to
go
from
the
current
popular
model
of
migrating
towards
kubernetes,
to
more
people,
adopting
server
lists
and
using
that
more
aggressively,
and
I
think
one
point
of
debate
that's
going
on
right
now
is
the
whole
idea
around.
Should
there
be
a
standard
around
what
an
event
is
because
many
of
these
service
functions
get
triggered
on
events.
The
way
that
people
want
to
implement
a
serverless
function
is
an
event
happens.
A
You
know
you
upload
an
image
to
s3
and
that
event
triggers
a
function,
call
a
serverless
function,
call
and,
and
one
of
the
things
that
people
want.
So
some
people
want
is
an
open
specification
around
those
kinds
of
events.
So,
for
example,
if
I
upload
an
image
to
s/3
s/3
would
create
an
event
that
would
be
less
s3
specific
so
that
if
I
wanted
to
instead
use
Google
blobstore
or
whatever
it's
called
or
the
you
know,
if
I
wanted
to
use,
SEF
or
so
I
think
SEF
is
a
isn't
as
an
object
store.
A
B
If
you
will
actually
have
a
language
or
the
protocol
to
the
standardization
of
those
infants
now,
basically,
what
you
can
do
is
to
basically
treat
all
those
cloud
like
one
big
virtual
cloud:
okay,
so
all
the
services-
and
basically
you
can
orchestrate
through
them
like
a
multi
cloud
solution.
So,
for
instance,
imagine
that
I'm
I
don't
know
I
wanted
to
actually
order
an
uber,
okay,
so
I'm
clicking
on
this
button
that
will
actually
go
to
my
infrastructure
on
Prem.
Do
some
stuff,
okay,
I,
don't
know.
B
Look
at
my
visa
is
good,
then
go
to
a
different
cloud
like,
for
instance,
AWS,
because
that's
where
my
storage
is
so
I
want
to
get
some
information.
Then
take
these
information
and
actually
go
to
Google
and
I.
Don't
know,
use
some
other
services
that
Google
is
supplying,
because
maybe
it's
better
than
what
they
do,
because
you
supply
and
then
I
don't
know,
go
to
a
zoo
and
do
something
else.
So
this
ability
to
actually
leveraging
all
the
services
and
all
the
cloud
will
be
much
easier.
B
There
will
be
one
language
that
all
those
services
were
going
to
work,
and
then
you
imagine
that
you
will
have
one
big
club
and
you
can
basically
mix
and
match
services.
Okay,
so
you
know
take
the
best
service.
That
is
work
for
you
and
that's
also
mean
in
a
way
that
you're
not
really
locking
to
the
cloud.
So
let's
say
that
all
your
data
is
in
AWS
s3.
B
B
The
problem
with
that
is
that
the
question,
if
the
provider
is
okay
with
that,
but
that's
a
different
question
right
because
most
of
this
same
movement,
it's
actually
been
done
for
people
who,
as
a
first
offer,
that
is
basically
you
know
kind
of
like
it
of
you
know
like
project
like
you
know
the
guys
from
several
s
or
the
guys
from
an
open
files
or
phishing,
or
you
know,
or
project
for
FN
and
so
on.
Those
people
usually
can
run
on
pram.
Of
course,
we
would
love
that
that
would
happen.
B
A
B
The
question
is,
why
should
they
write
I
mean
is
on
production
today,
service
most
likely
they're
running
on
AWS
support
is
a
specification,
basically
means
that
people
will
not
have
to
write.
They
will
be
able
to
run
on
Google
function
but
use
the
I
don't
know
why
they
should
because
they're
owning
this
market
anyway.
But
this
is
a
fault.
It's
right.
It's
not
related
to
technology.
B
I
mean
I
mean
this
is
a
good
question
from
what
I
see
I
again
I'm
not
like
for
what
I
see
from
far
I
think
that
you
know
it
makes
sense
that
Google
will
do
that,
maybe
as
rural,
because
as
I
said,
they
are
not
owning
this
market,
but
I
didn't
see
that
a
device
is
very
cooperative
on
this
and
maybe
I'm
wrong
again.
I
don't
have
all
the
data,
but
that's
that's
what
I
see
from
far
yeah.
B
But
I
think
it's
that
what
cool
about
it
is
that,
basically
the
vision
is
and
the
vision
is
right,
the
vision,
I
might
totally
supported
it
and,
as
I
said,
I
mean
when
we've
been
glue.
That
was
that's.
Why
we
start
when
I
pitch
it
to
my
investor.
This
is
where
we
started.
It's.
Basically,
the
ability
to
take
all
the
cloud
create
one
virtual
cloud
that
you
can
run
swap
flow
between
them,
that
you
can
mix
and
match
and
so
on.
B
The
problem
is
that
the
way
I
see
that
is
that
the
future
will
be
so
far.
I
mean
it
will
maybe
happen,
but
it
will
take
a
long
time.
So
it's
really
cool
but
I
think
that
it
will
take
a
long
time.
That's
why
I
extended
it
and
said
you
know
what
maybe
that's
you
know?
That's
also.
What
glue
during
glue
is
definite
like
as
I
said,
because
we
build
it
as
an
event
gateway.
B
We
build
it
as
the
ability
to
get
event
and
route
to
different
providers,
so
you
can
do
that
as
well
with
glue,
but
I
will
argue
that
that's
would
be
probably
more
popular
in
the
open-source
community
that
actually
in
enterprise
running
this
one
I
mean
F
customer,
and
he
said
to
me
we
are
totally
ready
for
a
lot
of
cloud,
but
not
the
multi-cloud
part,
which
is
basically
going
between.
So.
A
What's
the
go-to-market
strategy
there's
like
I
was
at
Q
Khan
recently
there
were
lots
of
enterprises
that
were
looking
to
spend
money
and
there
were
also
lots
of
vendors
that
were
pitching
to
the
enterprises.
So
you
you
do
have
this
two-sided
marketplace
where
people
are
ready
to
buy
and
people
are
ready
to
sell.
What's
your
specific
strategy.
B
B
One
of
them
is
the
iPod
app,
which
is
basically
I
call
it
iPod
app
is
the
ability
to
basically
glue
application
from
different
workload
and
the
other
one
is,
for
instance,
even
get,
which
is
the
ability
to
only
do
this
in
server
less
and
basically
be
able
able
to
get
an
advanced
cross
cloud
and
so
on.
That's
a
different
offer
for
my
opinion
for
different
people.
I,
don't
think
that
Enterprise
will
care
about.
You
can't
get
away,
and
that's
that
stage.
B
A
If
you
are
building
a
product
for
software
engineers-
or
you
are
hiring
software
engineers,
software
engineering
daily
is
accepting
sponsorships
for
2018.
Send
me
an
email
Jeff
at
software
engineering
daily.com
if
you're
interested
with
twenty
three
thousand
people
listening
Monday
through
Friday
and
the
content
being
fairly
selective
for
a
technical
listener.
Software
engineering
daily
is
a
great
way
to
reach
top
engineers
and
I
know
that
the
listeners
of
software
engineering
daily
are
great
engineers,
because
I
talk
to
them
all
the
time.
I
hear
from
CTOs
CEOs
directors
of
engineering
who
listen
to
the
show
regularly.
A
I
also
hear
about
many
newer
hungry
software
engineers
who
are
looking
to
level
up
quickly
and
prove
themselves
and
to
find
out
more
about
sponsoring
the
show.
You
can
send
me
an
email
or
tell
your
marketing
director
to
send
me
an
email
Jeff
at
software
engineering,
daily
comm
and
if
you're
listening
to
the
show.
Thank
you
so
much
for
supporting
it
through
your
audience,
ship.
That
is
quite
enough.
But
if
you're
interested
in
taking
your
support
of
the
show
to
the
next
level,
then
look
at
sponsoring
the
show
through
your
company.