►
From YouTube: Invitae + Solo.io
Description
Invitae talks about the value they get from working with Solo.io.
A
A
Can
you
describe
what
challenges
you
have
in
your
organization?
Our
journey
really
began:
Once
Upon,
a
Time
just
using
a
very
basic
open
source,
istio
Envoy
configuration
in
kubernetes
clusters
built
in
ec2
with
cops,
and
for
that
to
be
quite
honest,
most
of
the
knowledge
of
istio
at
that
time
and
our
usage
was
very
limited
to
Simply,
using
istio
as
an
Ingress
with
virtual
services
and
that's
about
where
it
ended.
It
was
we
weren't,
utilizing
all
the
features
and
functionalities
of
istio.
We
weren't
doing
anything
in
depth
with
Envoy
as
well.
A
It
occupied
this
space
that
was
fairly
opaque,
where
it
was
frustrating
to
both
our
application
development
teams
because
they
were
trying
to
do
things
and
interact
with
it
and
they
simply
were
not
able
to
get
up
to
speed
on
the
things
that
they
did.
It
also
had
an
organizational
effort
for
from
our
part
about
you
know
the
limitation
was
exactly
who
could
we
devote
to
that
task
and
devote
to
the
building
of
it?
We
can't
devote
half
of
our
team
to
Simply.
A
Building
this
out
of
the
open
source
means
available
as
we've
expanded
and
as
we've
grown.
There's
been
a
particular
focus
on
security,
implementations
and
also
in
terms
of
Automation
and
management
of
certain
aspects
of,
for
instance,
a
service
mesh
or
service
mesh
components
within
our
clusters,
one
of
the
things
that
became
a
very
solid
requirement
for
us
was
to
have
managed
mtls
within
our
clusters
to
be
able
to
encrypt
traffic,
to
also
be
able
to
authenticate
services
and
to
be
able
to
have
machine
to
machine
authorization
as
well
as
a
requirement
for
our
platform.
A
Many
companies
still
rely
upon
password-based
credentials
for
basic
authorization,
and
we
wanted
to
move
away
from
that
and,
in
particular,
with
a
long-term
goal
of
moving
toward
a
zero
trust
environment,
to
be
able
to
ensure
everything
from
regulatory
requirements
to
also
just
better
secure
our
own
environments.
As
we
move
forward
with
some
of
the
challenges
we
faced
on,
the
organizational
side
is:
who
do
you
have
on
your
end,
to
be
able
to
support
you
moving
toward
that
in
many
ways?
A
This
is
a
very
new
and
very
highly
advanced
technologies
that
we're
working
with,
and
you
don't
often
find
either
the
depth
of
knowledge
or
the
specific
domain
knowledge
available
within
your
organization,
to
sort
of
go
it
alone
and
build
out
your
own
services
and
your
own
systems,
or
if
you
do,
it
takes
a
lot
of
time
and
a
lot
of
effort.
A
lot
of
you
know
sort
of
missteps
and
it's
a
very
steep
learning
curve.
In
many
ways,
why
did
you
Peak
solo?
A
You
can
do
something
like
that:
just
fine,
if
you're
tightly
integrated
with
AWS
and
the
AWS
environment,
what
was
an
alternative
that
we
had
attempted
to
implement,
at
least
in
our
non-production
environments,
initially
was
Amazon's
app
mesh
and
AWS
app
mesh
seemed
to
us
like
a
great
choice,
because
it
was
simple,
relatively
easy
to
use.
Well
integrated.
A
We
were
trying
to
implement
spiffy
Inspire
with
with
app
mesh.
We
were
hitting
some
roadblocks
there.
We
also
attempted
to
then
really
utilize
external
authorization
through
Envoy
as
an
Envoy
filter,
and
we
found
that
we
weren't
getting
the
exposure
that
we
needed
to
Envoy
in
in
order
to
be
able
to
implement
that.
A
Specifically,
there
were
some
issues
that
we
faced
with
something
like
forwarding
the
actual
cert
details
from
one
lesson
or
to
another,
and
we
weren't
finding
that
that
was
working
for
us,
I'm
sure
everyone
is
well
aware
in
the
industry
there's
only
so
far,
you
can
go
working
with
a
very
large
company,
that's
on
its
own
roadmap.
That's
on
its
own
pace
that
you
don't
have
a
very
strong
personal,
almost
I
would
say
relationship
with
as
a
smaller
company
or
even
a
mid-sized
company.
It's
difficult
to
really
have
that
kind
of
strong
relationship
with
the
vendor.
A
Rather
than
simply,
you
pay
us
money,
and
we
give
you
this
thing,
and
maybe
we
implement
the
features
you
need
or
want,
or
maybe
we
don't
and
that
will
change
your
plans
as
well.
One
of
the
reasons
why,
after
we
were
assessing
a
number
of
different
options
available,
why
we
went
with
solo
and
glumesh
is
in
particular
that
level
of
support
that
was
available,
that
level
of
domain-specific
knowledge
and
expertise
that
was
available,
which
other
products
are
offerings
or
Services,
didn't
necessarily
provide
for
us.
It's
based
upon
open
source
components
underneath
true
is
dealing.
A
Would
we
have
access
to
the
same
very
highly
technical,
domain-specific
Knowledge
from
the
engineers
at
solo,
and
would
we
be
able
to
retain
them
on
a
permanent
basis?
Almost
through
you
know,
a
variety
of
you
know,
onboarding
or
or
on
calls
or
anything
else
like
that
for
your
entire
organization
and
be
able
to
keep
that
pace
going
without
any
external
support
if
you're
a
large
enough
organization.
A
It's
more
of
a
question
of
the
access
that
would
give
you
to
really
domain-specific
experts
in
the
field
to
be
able
to
then
Advance
the
product
and
grow
and
the
product,
knowing
that
the
product
will
grow
with
your
organization
as
well,
rather
than
just
simply
be
a
product
that
you
grab
off
the
shelf
and
try
to
implement,
as
they
experience
with
solo
so
far,
we're
still
fairly
early
in
the
process
of
onboarding.
Our
applications
to
the
service
mesh
so
far,
I
found
solo
to
be
very
responsive.
A
We've
hit
quite
a
few
interesting
edge
cases
that
it's
been.
You
know
a
unique
experience
being
able
to
interact
with
solo
Engineers
to
be
able
to
resolve
that
being
able
to
work
with
us
on
that
also,
the
absolute
you
know:
depth
of
knowledge
and
domain
specific
knowledge,
that's
available
with
the
engineers
at
solos,
just
incredible
we're
using
gloomish
Enterprise
one
of
the
things
that
we
also
appreciate
with
that
is
blue
mesh
gateways.
A
That
are
part
of
that,
because
we
didn't
need
all
of
the
functionality
of
glue
Edge,
but
we
definitely
can
use
some
of
the
functionality
of
it
and
that
functionality
from
glue
Edge
is
inherited
within
bluemesh
Gateway
as
part
of
the
Enterprise
glue
mesh
service
mesh.
Our
main
priorities
and
our
main
focus
for
service
mesh
itself
is
to
be
able
to
secure
our
internal
Network,
make
sure
that
we
can
have
appropriate
service
to
service
authentication
and
machine
to
machine
authorization.
A
That's
done
in
a
fairly
consistent
and
manageable
way.
Overall,
it's
been
a
very
positive
experience
so
far,
a
very
responsive
team
at
solo
I'm,
looking
forward
to
continuing
to
work
with
solo
thinking
of
it
again
as
building
our
own
organization
in
kind
of
a
symbiotic
way
with
the
service
mesh
as
a
platform,
and
you
know
seeing
where
it
can
go
from
that.
So
I'm
excited
and
it's
been
a
very
a
very
helpful
healthy
and
the
unfunctional
relationship.
You
value
each
one
of
your
customers
as
a
partner
and
I
think
that's
where
it
comes.
A
That's
where
the
difference
comes
across
I,
deeply
value.
I
deeply
appreciate
the
fact
that
solo
is
willing
to
see
the
value
in
smaller,
more
Dynamic
companies,
leaner
companies
that
are
out
there
doing
really
amazing
things
and
really
trying
to
push
the
envelope
rather
than
just
saying.
Well
we're
just
going
to
focus
our
entire
model
on
you
know,
according
these
larger
agencies
or
organizations.
So
far
we're
very
happy
with
the
decision.