►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
B
Thanks
sheryl
thanks
for
having
me
here,
no,
it's
pretty
exciting
because
I
watched
the
two
sessions
that
were
there
in
the
last
two
months
and
one
was
from
cern
other
from
twitter.
I
have
interacted
with
both
organizations
in
a
past
life
from
an
open
source
perspective,
so
this
is
awesome
to
have
a
startup
and
on
this
conference
yeah.
Thank
you
yeah.
I
am
santor
srinivasan.
I
am
the
co-founder
and
head
of
engineering
of
perito
state
ai,
so
we
are
building
out
knowledge
networks
to
help
developer
self-service
where
they
work,
and
this
knowledge
comes
from
experts.
B
A
B
Yeah,
it's
a
fantastic
question.
So,
just
a
little
bit
of
a
background
about
my
own
career,
I
started
my
career
in
the
labs
development
center
later
I
went
to
grad
school
and
landed
up
at
yahoo,
where
we
were
working
on
what
we
used
to
call
as
large
scale
data
processing,
and
that
eventually
became
big
data.
I
got
lucky
and
I
was
introduced
to
the
hadoop
ecosystem
by
a
good
friend
of
mine,
arun
murthy,
one
of
the
lead
engineers
on
hadoop
and
that
journey
began
in
2008
about
13
and
a
half
years
ago
into
open
source.
B
So
in
that
journey
we
built
hadoop
at
yahoo
for
yahoo
it
was
not
commercial.
It
was
not
meant
to
be
used
by
other
people,
as
is,
but
it
was
meant
to
foster
innovation
and
what
we
noticed
was
with
open
source.
If
things
work,
people
pick
it
up
and
the
adoption
is
really
tremendous.
I
noticed
two
or
three
different
flavors
in
open
source,
where
you
can
have
viral
adoption.
One
was
the
yahoo
flavor
where
we
built
something
at
rapid
scale,
massive
scale,
hundreds
of
millions
of
dollars.
B
The
hadoop
ecosystem
became
so
massive
that
entities
started
commercializing
it
and
I
ended
up
in
one
of
those
entities
called
cloudera.
So
I
went
from
being
a
end-user
contributor
committer
to
a
governance
member
in
apache
to
participating
in
a
commercial
activity
at
cloudera
and
at
cloudera.
What
I
noticed
being
on
the
other
side
is
open.
Source
is
easy
if
you're
a
developer,
but
if
your
skill
levels
are
below
that
of
a
developer,
it's
extremely
challenging
to
use
and
that's
where
the
enterprise
companies
were
forming,
and
this
is
the
genesis
of
parities.
A
B
Yeah,
so
one
of
the
things
about
being
a
co-founder
is
my
official
title
is
co-founder
of
vp
of
engineering.
I
do
a
ton
of
things
and
sometimes
people
call
you
as
the
chief
janitor
as
well.
So
you
have
to
do
anything
that
relates
to
the
company,
but
my
primary
responsibility
is
to
build
out
technology
and
product,
so
a
significant
amount
of
our
engineering
resources
are
built
towards
using
the
technology
to
rapidly
build
features
in
the
product.
B
So
one
chunk
of
the
engineering
arc
is
for
infrastructure,
because
without
infrastructure
you
cannot
build
out
product
quickly
and
when
I
first
started
the
company,
and
since
now
it's
been
about
three
and
a
half
years.
The
challenge
was,
I
came
from
the
big
data
scale
out
technology
and
we
are
trying
to
try
those
technologies,
and
this
is
when
kubernetes
are
sort
of
taking
off
and
it
was
not
quite
mature.
B
So
we
tried
a
few
things
and
finally
settled
on
kubernetes
about
two
years
ago
and
we
invested
a
lot
of
energy
into
doing
both
the
scale
out
and
also
giving
developers
flexibility
to
spin
up
things
on
demand
to
do
their
own
innovation.
So
that's
one
part
of
the
organization
which
is
infrastructure
and
we
try
to
use
multiple
cloud
providers
because
some
of
our
customers
tend
to
say:
hey.
B
You
just
have
to
work
on
one
or
the
other,
and
we
wanted
to
be
careful
here,
because
if
you
choose
any
cloud
native
technology
hosted
by
the
provider,
you're
kind
of
stuck
in
some
sense,
it's
awesome.
It's
I
would
say
it's.
The
value
is
tremendous,
but
if
someone
else
wants
you
to
be
on
a
different
cloud
provider,
it's
challenging
so
we
decided.
Okay,
everything
is
going
to
be
containerized.
B
A
B
A
B
It's
just
experience
bias,
and
so
when,
when
I
left
cloudera,
we
were
trying
to
launch
a
cloud
initiative
to
spin
up
clusters
on
demand
to
do
scale
out
and
elastic
stuff.
So
when
we
came
in
and
we
were
saying,
okay,
let
me
first
check
the
context
of
what's
the
problem
you're
trying
to
solve.
We
are
trying
to
build
out
a
knowledge
network,
so
knowledge
resides
in
multiple
forums,
documentations
kb
articles
forum,
conversations,
github
issues,
github
pr
comments
and
all
of
those
things.
So
now
we
want
this
from
everywhere.
B
In
one
central
location,
we
have
a
knowledge
graph
which
supports
what
we
finally
end
up
doing
is
provide
recommendations
to
developers
as
they
are
working.
So
we
have
a
machine
learning
team
of
a
few
engineers
who
are
rapidly
doing
experimentation
to
try
out
the
quality
of
these
recommendations.
We
have
the
infrastructure
team
trying
to
help.
You
know
spin
up
scale
down
and
maintain
stuff,
and
then
we
have
the
data
crawling
ingestion
and
organization
team
and
then
finally,
you
have
a
full
stack,
ui
ux
team
trying
to
productize
the
underlying
technology.
B
So
these
are
the
four
different
components
to
the
organization.
So,
coming
from
a
big
data
technology,
I
said,
okay
crawling
is
a
solved
problem.
So
let's
just
spin
up
things.
Processing
is
interesting
because
it
depends
what
you
want
to
process
and
how.
So,
since
I
came
from
the
hadoop
background,
we
tried
a
few
things
there.
It
worked,
but
it
was
slow.
B
B
The
reason
it
is
challenging
is
we
are
highly
skilled
engineers.
People
who
have
been
at
bigger
companies
with
the
same
background
and
getting
to
use
technology
is
one
thing,
but
if
things
don't
work,
try
to
find
out.
Why
fix
them
as
soon
as
possible,
without
waiting
on
the
community
to
provide
a
fix
and
I've
been
on
the
other
side
providing
the
technology.
Now
I
was
consuming
technology
from
open
source
while
trying
to
have
very
fast
product
iteration.
A
A
B
B
Spaces
and
kubernetes:
we
have
somewhat
of
a
staging
environment
that
we
prep
before
we
go
live
on
production,
so
we
want
to
do
testing
and
stuff
and
for
developers
they
can
spin
anything
on
demand.
So
we
have
integrated
right
from
the
time
you
do
a
commit.
Your
pr
gets
merged.
You
can
get
it
deployed
on
the
cloud
almost
within
a
matter
of
minutes
into
your
own
developer,
namespace
and
you
can
create
as
many
developer
namespaces
as
possible
because
you're
doing
rapid
prototyping.
B
And
uiux,
so
you
want
this
subset
of
engineers
working
on
a
feature
to
work
on
a
feature
branch
and
you
should
be
able
to
deploy
to
the
namespace
for
this
feature:
branch
from
each
commit
to
your
own
developer,
namespace
and
when
you
think
it's
reasonably
stable,
you
go
through
your
pr
review
process,
merge
the
branch
to
your
main
branch
and
then
the
next
release.
We
try
to
do
one
or
two
releases
per
week.
It
goes
to
staging
and
then
we
promote
it
to
production.
B
A
B
A
A
Oh
very
cool,
it
sounds
like
you
have
a
pretty
smooth
pipeline,
then
for
the
very
nice
developer
experience
you
could
say
you
mentioned
some
of
the
challenges
as
well
earlier
that
you
faced
so
right
now.
What
would
you
say
are
your
biggest
challenges
when
you're
building
infrastructure
or
you're
managing
and
deploying
applications.
B
B
B
B
B
The
bigger
challenge
is:
if
you
hire
someone,
they
may
not
even
be
familiar
with
the
technology
that
you
picked,
even
though
it's
open
source,
so
I
mean
at
the
higher
order
stack
you
have
these
angular
versus
react
battles
going
on,
so
I
have
more
more
of
a
core
back-end
technologist,
not
a
front-end
ui
person.
So
if
you
as
you
go
to
the
back
end,
these
are
the
fundamental
pieces
you're
building
on
you
can't
change
them
quickly
compared
to
the
higher
layers
of
the
stack.
B
So
when
you're
thinking
about
this
workflow
thing,
we
tried
a
few.
We
tried
air
flow,
it
worked
initially,
but
it
wouldn't
work
for
us.
Then
we
really
explored
to
see
hey.
Have
you
built
a
kubernetes
integration
that
we
can
contribute
to?
Oh,
it
was
not
there.
Then
we
looked
at
cube
flow
as
too
nascent
for
us
to
pick
up.
Then
we
said:
okay
begrudgingly.
We
agreed.
Let's
build
something
in-house,
knowing
that
at
some
point
in
time
we'll
give
this
up
or
migrate
to
something
which
is
more
standard.
B
B
B
Well,
I
had
a
lead,
come
to
me
and
say:
don't
build
anything
in-house
and
the
reason
he
said
is
we'll
train
people
on
a
bunch
of
proprietary
technologies
and
that
skill
is
not
portable
and
when
we
hire
smart
engineers
we'll
spend
like
a
month
or
two
training
them
on
our
technology.
That's
not
useful
to
us
either.
He
pretty
much
said
it's
a
lose-lose
proposition
for
us.
A
Yeah,
I
mean
that's
totally
fair.
I've
heard
this
as
well
from
other
companies
that
one
of
the
benefits
of
open
source
is
that
you
don't
need
to
spend
time,
training
or
retraining
people
when
they
come
in
or
out.
Let's
take
a
slightly
different
angle
now,
because
I'd
love
to
hear
from
both
your
experience
and
from
what
you've
seen
in
the
in
the
knowledge
base
that
you're
building
out
I'd
love
to
talk
about
some
trends
and
predictions
for
cloud
native.
A
B
Yeah,
so
we
actually
did
a
deep
analysis
of
cncf,
so
I
have
that
maybe
we
can
talk
offline
about
it,
but
so
here
are
some
interesting
things.
I
found
that
you
may
already
know
right.
So
I
looked
at
the
graduated
and
incubating
projects
right.
I
didn't
we.
Although
we
have
used
some
sandbox
projects,
I
just
narrowed
the
focus
to
something
which
is
well
known,
so
there
are
36
projects
in
that
list.
B
Just
as
a
quick
tidbit
for
one
project,
emissary
ingress,
there
is
no
reference
to
any
of
their
activity
on
the
main
landing
page
for
cncf,
so
including
that
I
mean
there's
no
reference
to
any
github
link
community
page
or
anything.
Everything
else
is
very
nicely
set
up
on
the
cncf
webpage.
I
know
where
the
github
repo
is
the
dev
stats
and
where
the
community
is,
if
they
do
have
a
community,
so
interesting
stats.
Now
that
you
asked
is
70
of
them.
Have
a
twitter
account
it's
omnichannel,
so
they
have
to
have
a
presence
online.
B
B
You
need
people
who
can
help
answer
questions
so
that
both
developers
and
end
users
can
rapidly
use
adopt
and
build
out
features
and
technologies.
So
what
this
tells
me
is,
if
you
take
out
kubernetes
and
grpc,
they
over
dominate
the
activities
going
on
in
cncf,
so
we
we
actually
did
analysis
saying
with
and
without
kubernetes,
then.
B
B
B
A
B
Right,
so
if
you,
if
you
really
think
about
people
who
are
using
these,
these
technologies
are
complex.
Let's
first
state
that
this
is
not
easy
technology,
so
people
are
building.
It
are
very
sharp,
very
smart,
I'm
talking
about
the
after
building
of
the
technology
or
in
the
process
of
building
out.
How
do
you
get
it
off
the
ground?
B
B
B
So
what
we
I'm
on
several
of
the
cncf
slack
channels.
So
I
see
this
activity.
It's
very
high
activity
and
these
public
slack
channels
have
a
shortcoming
right
because
slack
doesn't
give
you
free
versions
with
infinite
capacity
at
10,
000
messages
you
age
out,
people
tend
to
ask
the
same
question
over
and
over
again
on
slack,
so
there's
a
gap
here
right
so
people
who
are
building
out
the
product
they
are
fatigued
by
trying
to
answer
the
same
question.
They
have
to
dedicate
time
to
answer
questions
on
slack
and
you
have
to
set
aside
time.
B
A
B
B
B
That
demos
have
talked
to
one
of
their
founders,
it's
a
really
impressive
technology,
but
unfortunately
they're
considering
moving
it
into
an
attic
right.
That's
very
sad
to
see
very
complex,
highly
useful
project,
so
you
have
to
build
out
to
your
community
and
you
have
to
build
it
out
so
that
it
sustains
beyond
the
initial
founders
involvement
and
when
it
gets
incubated
or
when
it
graduates.
A
Interesting
to
hear
that-
and
also
I
I
very
much
agree
with
you-
that
community
building
is
much
harder
than
it
seems,
takes
a
lot
of
time
takes
a
lot
of
persistence,
but
it's
the
only
way
for
the
project
to
outlive
the
original
maintainers,
that's
correct.
So
what
do
you
think
is
the
most
surprising
thing
that
you've
seen
so
far
like
now
that
parasite
ai
has
been
around
for
a
little
while,
like
anything
surprising
that
you've
seen.
B
B
Impressed
with
the
level
of
rigor
on
the
mechanics
of
how
the
decision
is
made,
it's
so
public
everybody
can
see
the
decision
making.
That's
impressive,
because
transparency
means
people,
trust
the
process
and
the
last
part
I
find
somewhat
funny,
but
also-
and
I
found
it
I
found-
I
had
a
good
feeling-
is
everything
it
was
on
git
for
a
developer.
That's.
A
B
So
that
that's
very
friendly
both
for
people
contributing
and
when
you
import
the
technology
in
you're
you're
fine
in
terms
of
the
legality
of
using
it,
there
are
certain
open
source
licenses
where
you
have
to
think
100
times
before
thinking
or
picking
it
up,
because
it
may
have
to
it
triggers
these
things
of
hey.
If
you're
using
it,
you
have
to
open
source
everything
around
it
and
it's
too
complex.
A
A
B
Yeah,
absolutely
so,
when
we
built
out
our
products
on
cloud,
we
went
to
some
enterprise
customers
and
they
asked
they
would
give
us
this
huge
checklist
of
things
we
had
to
pass
before
they
would
let
us
in,
and
some
of
these
questions
are
like
have
you
had
a
third
party
consultant
certified
that
your
product
is
secure
right?
Have
you
done
some
kind
of
pen
test?
Have
you
done
shock
to
a
whole
bunch
of
these
things?
So
some
of
these
are
compliance
things
right.
B
You
do
it
at
that
point
in
time
it
doesn't
mean
you're,
doing
it
every
day,
every
minute,
every
second,
so
you
have
to
be
doing
that
it's
somewhat
in
the
realm
of
observability
and
monitoring
from
a
security
aspect,
so
raw
metrics
and
monitoring
infrastructure
engineers
are
awesome
right
for
debugging
and
things
like
that.
Security
is
life
and
death
for
some
companies.
The
recent
you
know
the
ransomware
that
happened
with
this
pipeline
company,
which
carries
oil
physical
pipelines
on.
B
Coast
of
the
us
that
was
alarming.
First
and
foremost,
I
didn't
even
know
this
company
existed
and
the
ceo
of
the
company
said
this.
We
wanted
to
be
nameless
throughout
our
existence.
We
never
wanted
to
be
in
the
news
and
they
probably
supply
nearly
fifty
percent
of
oil
to
eastern
united
states.
Forty
five
percent
to
fifty
percent
say
when
you
build
out
these
technologies.
B
If
they
get
hacked,
then
there
is
no
recourse
other
than
having
to
pay
ransom
and
then
trying
to
actively
patch
holes,
and
it's
an
adversarial
game.
You
patch
one.
Something
else
opens
up
so
for
us
what
it
meant
is
you
had
to
get
ahead
of
it?
Some
of
the
cloud
vendors
have
really
good
technology
that
supports
it.
They
do
port
scanning,
they
do
anomaly
detection,
but
you
also
go
deeper
into
your
own
use
of
the
products
and
try
to
find
out
what
else
is
happening.
So
in
that
context
we
are
looking
into
using
falco.
A
B
B
There
two
main
reasons:
one:
we
are
using
the
technology
piece
by
piece
while
not
getting
involved
in
the
community
right.
So
one
of
our
technical
advisors
said:
hey,
you
guys
have
to
be
in
cncf.
They
look
at
all
these
other
things
that
are
being
built
and
what
we
are
trying
to
build
as
a
knowledge
network.
You
have
to
do
it
for
a
domain
which
is
as
it
stands
today,
taking
off
or
in
common
power
lines
hot,
and
you
need
to
be
aware
of
what's
happening.
B
So
our
technical
advisor
said
here
is
the
community,
where
you
need
to
be
there.
Thanks
to
him,
we
got
involved.
We
started
building
out
our
technology
as
a
subset
of
that.
Then
we
broadened
the
lens
saying.
What
else
are
we
missing?
That's
how
falco
and
other
things
came
into
the
picture,
and
then
we
said,
oh,
if
you
have
to
build
out
a
knowledge
network,
you
really
need
to
understand
these
technologies
from
an
abstract
perspective
of
what's
happening.
What
are
the
gaps?
So
that's.
The
second
reason
we
got
involved.
B
Yeah,
so
our
foremost
objective
was
to
understand
and
build,
which
is
the
main
motivation.
The
outcome
that
you're
hoping
for
is,
if
you
can
give
out
a
roadmap
or
a
guideline
to
new
projects
and
existing
projects.
To
say
here
is
a
path
to
success
and
we
can
help
you
get
there
faster
sooner
with
little
to
no
friction.
B
That
will
be
awesome
if
you
want
to
provide
the
intelligence
for
cncf
based
communities
to
do
their
job,
better
developers
can
focus
on
building
product
end-user,
skin
consumption,
and
we
can
take
care
of,
let's
say
the
community
intelligence
part
at
no
cost
to
cncf.
That
will
be
awesome,
so
we
want
to
provide
the
community
intelligence
to
cncf.
So
that
would
be
an
amazing
outcome
for
us.
A
B
Oh
no,
this
is
thanks
for
having
me
on
this
channel
and
it
is
phenomenal.
I
mean
I
am
continue
to
be
amazed
with
how
well
cncf
is
run.
It's
kudos
to
all
of
you,
because
it's
a
sea
change
from
having
been
part
of
a
earlier
open
source
community.
Now
I've
been
on
the
outside
looking
in
so
I
hope
to
participate
further,
and
you
know.
A
A
I'm
very
happy
to
hear
that,
and
it
is
a
pleasure
to
have
you
in
the
community
as
well.
So
thank
you
so
much
today
and
thank
you.
Everyone.
Thank
you
to
our
audience
for
joining
our
latest
episode
of
the
cloud
native
end
user.
Lounge
again,
we
love,
having
other
end
users
to
come
and
join
us.
So
we
really
hope
that
you've
enjoyed
the
interaction
and
heard
about
learn
a
little
bit
of
something
as
well
we're
going
to
bring
the
latest
cloud
native
end
user
stories
on
the
fourth
thursday
of
the
month
at
9.
A
00
am
pt
and
also
don't
forget
to
join
us
for
kubecon
cloudnativecon
north
america,
which
for
the
first
time
in
a
year
and
a
half,
will
be
in
person
as
well
as
virtual,
which
I'm
very
excited
bye.
So,
if
you're
coming
in
person,
it's
going
to
be
in
los
angeles
it'll,
be
october
12th
to
the
15th,
and
you
can
hear
the
latest
from
the
cloud
native
community
also,
if
you
would
like
to
showcase
your
use
of
cloud
native
tools
as
an
end
user,
go
to
cncf.io
enduser
to
join
the
end
user
community.