►
From YouTube: Event Processing at Optum, the Cloud Events Way - Janani Pathangi & Murugappan Chetty, Optum
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Event Processing at Optum, the Cloud Events Way - Janani Pathangi & Murugappan Chetty, Optum
Event driven architectures are on the rise, organizations are scrambling to keep up with it. Will standardizing events with Cloud Events help in this process ? This talk by Janani Pathangi and Murugappan Chetty of Optum will help you find that answer, as they explain how teams at Optum are starting to embrace Cloud Events The audience will get know about * Cloud Events - the specification and 2.0 Go library * Easy wins and pain points of using Cloud Events. * Role, knative eventing is playing in sourcing and delivering cloud events. * Building events sources and consumers * Use Cases at Optum leveraging Cloud Events
A
Hi
welcome
all
today
we
would
like
to
share
even
processing
at
optum
the
cloud
events
way,
I'm
janani
pathangi
distinguished
engineer,
20
years
in
usa
and
currently
I
lead
the
optum
functions
platform
and
I
also
have
murugapan
sevakan
shetty
here
with
me.
He
is
a
principal
engineer
and
tech
lead
and
a
k,
native,
open
source
contributor.
A
We
would
like
to
have
a
quick
introduction
about
our
organization.
United
health
group.
United
health
group
is
a
highly
diversified,
health
and
well-being
company.
It's
headquartered
in
the
united
states
and
ranked
seventh
of
the
fortune
500..
We
have
two
business
platform:
united
healthcare,
which
will
focus
on
health
benefits
and
optum
is
a
health
services.
Innovation,
company.
A
Across
optum,
we
are
able
to
serve
many
constituents
of
health
system
and
we
are
grateful
to
serve
and
partner
with
9
out
of
the
10
1400
companies
9
out
of
the
10
u.s
hospital
and
serve
125
million
consumers
from
infrastructure
and
technology
perspective.
We
have
an
annual
spend
of
about
3.5
billion
dollars
on
technology
and
innovation.
A
Ecosystem,
this
is
the
agenda
we
plan
to
cover.
Today
we
want
to
give
a
quick
introduction
about
serverless
at
optum
challenges
with
even
processing
why
we
started
to
explore
cloud
events
and
some
of
the
autumn
use
cases
with
cloud
events
supplemented
with
demo,
and
we
would
like
to
conclude
with
summary.
A
So
now,
let's
look
into
the
optum
functions.
It's
an
on-prem,
fully
managed
multi-tenant
serverless
platform
which
supports
stateless
event,
driven
request
based
compute
workloads.
Currently,
it's
offered
cross
dc
active
active
without
a
capability
from
adoption
standpoint.
We
are
increasing
and
thousand
more
than
thousand
functions
deployed
today
with
more
than
500
developers
using
this
across
the
organization
to
solve
some
of
our
enterprise
use
cases.
For
example,
edl
jobs
today
run
as
functions.
We
are
able
to
serve
mission
loading
machine
learning
models
and
also
have
some
of
our
infrastructure
housekeeping
jobs.
Running
on
this
platform,.
A
So
how
do
we
make
the
open
source
stack
to
an
enterprise
service?
We
started
with
the
open
source
stack
here:
kubernetes
istio,
k
native
and
we
added
more
enterprise
capability
on
top
of
them
and,
as
you
can
see
here,
to
the
left
hand
side,
we
started
with
enterprise
integration,
with
vault
for
authentication
and
authorization
when
fi
for
auto
tls
search
rotation
and
with
our
enterprise,
job
scheduler
for
all
the
etl
jobs
that
is
running
as
functions
today
and
we
strengthen
our
sre
with
the
well-defined
slo,
sli
and
dashboards.
A
We
have
very
good
observability
and
we
added
a
lot
of
self-healing
and
automation
scripts
and
we
also
conduct
quarterly
chaos
game
days
and
to
the
top.
We
added
self-service
ui
to
abstract
the
infrastructure
apis
and
provide
simple
code
to
url
experience
to
our
end
users,
and
we
also
added
lot
of
training
and
template
projects.
A
This
is
the
reason
why
we
wanted
to
have
to
make
sure
that
the
use
cases
are
moved
in
a
lift,
transform
and
shift
from
monolith
to
functions.
This
is
all
helping
them
the
end
users
or
the
developers
with
it,
and
we
also
introduce
ground
vm
framework.
Garal
vm
frameworks
to
improve
the
java
cold
starts.
B
So,
as
generally
explained,
our
platform
is
based
on
k,
nato
and
k
native.
The
artifact.
That
keynet
expects
is
a
container
image
and
all
the
functions
run
as
pod.
Okay
and
other
thing
that
k
native
experts
is
the
container
image
should
expose
a
port
so
that
it
could
check
whether
the
application
is
up
or
not.
B
B
Image
you
need
to
define
a
docker
file
and
then
you
need
to
use
that
to
do
the
docker
build
and
run
it.
Instead
of
that,
I
have
a
go
based
application.
Okay,
this
is
a
go
based
application
to
run
this.
I
am
going
to
use
a
tool
called
as
co.
Okay,
so
core
is
a
tool
which
makes
the
darker
build
and
push
layer
invisible
to
you
totally
so
using
co
I'll,
be
able
to
take
the
source
score
and
then
build
and
push
it
to
the
repository
without
even
defining
any
docker
file.
B
Okay
for
deployment.
This
is
just
a
kubernetes
application
right,
so
I've
been
using
the
amplifier,
I
can
use
the
coconut
cmi.
Instead,
I'm
going
to
use
a
k,
n
cla,
which
is
efficient,
k
native
cli,
which
gives
a
better
experience
to
be
deploying
it
on
any
k,
native
based
platform
and
inside
our
company.
We
have
a
separate
ui,
which
abstracts
k
native
istio
and
kubernetes,
which
gives
a
better
experience,
but
for
a
wider
audience
I
thought
cane
would
be
more
helpful.
B
Okay,
so
now,
when
I
run
it,
so
what
I'm
expecting
is
a
k
native
controller
plane
to
deploy
this
in
the
kubernetes
cluster
and
give
me
a
url
okay.
So
that's
what
is
happening
here.
So
if
I
have
the
integrations
in
the
right
place
with
k,
native
and
search
manager,
I
am
I
have
I
I
can
even
get
an
https
url.
B
So
now
you
see
what
you
see
is
a
http
url
and
then
slowly
it
should
turn
to
https
there
you
go
okay,
so
within
like
30
seconds,
we
were
able
to
take
the
source
code
and
then
build
push
and
then
deploy
as
well
get
the
fully
secure
url
okay.
So
when
I
open
this
url
in
the
browser,
I
should
see
a
web
application
there
you
go
so
this
is
the
web
application
that
I
deployed.
So
when
we
send
some
events
to
this
web
application,
it
should
display
this
events
here.
B
So
so,
when
we
deploy
something
to
the
k
native
platform,
it
gives
you
a
url
and
to
trigger
that
it's
very
simple
you
can
use
a
you,
can
call
it
from
any
other
application.
You
can
do
a
post
put
get
you
can
call
it
from
postman,
but
in
the
real
world,
functions
are
like
synonymous,
true,
even
processing,
so
it
really
comes
down
to
how
you
are
going
to
deliver
events
from
a
say
even
source
like
kafka.
Okay,
so
that
is
where
k
native
has
a
pla.
B
Has
a
separate
ecosystem
called
k
n
a
t
venti.
It
is
even
like
independent
of
the
k
native
serving
platform.
Okay,
so
you
can.
Just
if
you
want,
you
can
just
have
the
knitting
even
thing
alone
installed
in
your
kubernetes
cluster
and
in
it
in
the
canadian
eventing
world.
There
are
like
two
main
components:
okay,
which
we'll
be
talking
throughout
this
session.
One
is
an
even
source
and
second
one
is
the
broker.
B
The
job
of
the
even
source
is
to
reach
out
to
the
actual
source,
which
is
like
kafka,
rabbit
and
queue,
or
another
application.
Take
the
data
from
it
and
then
send
it
to
the
processing
function
and
in
k91
the
processing
function
and
where,
whichever
is
the
receiver,
it's
called
as
a
sync.
Okay,
the
sync
can
be
any
addressable
service.
That
means
anything
that
gives
a
url
like
a
k
native
service.
B
A
B
This
can
be
a
sync
okay
and
then
in
the
first.
There
are
two
types
of
delivery
happen
here.
One
is
like
one,
two,
one:
delivery:
that's
what
we
take
the
data
from
the
source
use
the
k,
nato
even
source,
to
deliver
it
directly
to
the
canadian
service
or
kubernetes
service.
In
this
case,
it's
like
tightly
coupled
between
source
on
the
processor
and
instead,
if
you
have
a
buffer
in
between,
it,
will
be
better
for
processing,
also
you're,
decoupling,
the
source
and
the
processing
function.
So
you
can
do
a
lot
more
with
it.
B
That's
another
k
native
resource
which,
in
which
we
can
specify
which
types
of
events
needs
to
be
routed,
to
which
sync,
okay,
suppose
I
have
a
k-native
service,
which
checks
just
looks
for
a
kafka
service,
I'll,
create
a
trigger
and
then
say
that.
Okay,
I
want
kafka
events
alone.
Then
the
broker
will
deliver
the
kafka
events
alone
to
this
k
native
serves
for
all
these
things
to
happen.
They
need
to
be
a
glue
or
what
they
need
to
a
particular
even
type.
B
That's
the
okay,
that
is
where
cloud
events
comes
into
play
and
and
this
whole
eventing
ecosystem
of
k
native
is
built
around
this
cloud
events
only.
So
what
is
clouding
cloud
events
is
an
even
specification
given
by
cncf.
It
is
not
a
data
specification.
The
data
inside
cloud
events
can
be
anything
okay,
so
it
can
be
text.
It
can
be
binary,
they
don't
have
any
say
over
that.
Okay,
so,
as
you
can
see
in
the
right,
that
is
the
data
and
on
the
top
it
just
asks
these
four
headers
to
be
added.
B
Okay.
So
with
these
four
headers,
you
can
do
a
lot
of
things.
That's
all
we'll
be
seeing
in
this.
Our
use
cases
and
the
cloud
events
community
supports
and
then
gives
a
lot
of
sdks
like
for
all
the
languages
that
we
commonly
use.
Go
java
rust,
you
name
it.
There
is
an
sdk
support
for
it,
and
this
even
delivery
is
not
only
through
http.
It
is
also
through
kafka
avro.
They
support
different
formats
for
more
details
about
it.
You
can
look
at
the
cloud.
Events
are
your
website.
B
It
is
k
native
that
introduced
us
to
cloud
events,
but
it
happened
to
solve
more
use
cases
for
us
outside
of
knativ,
also,
okay,
so
the
problems
that
we
used
to
have
was
like
we
used
to
have,
and
we
are
having
right
now-
also
is
our
com.
Our
organization
is
really
big
and
then
there's
predominant
presence
in
the
data
center,
our
on-premises
data
center
and
there
are
like
various,
even
sources,
and
we
see
a
lot
of
redundancy
in
processing.
B
B
Then
they
can
use
that
particular
processor
and
the,
and
you
can
use
the
k
native
broker
that
I
just
showed
you
so
you
can
use
you
can
dump
in
all
the
events
from
a
different
sources,
even
if
they
are
not
within
the
k
native
system,
even
if
they
are
outside,
they
can
send
it
to
the
broker
and
we
can
use
the
k
native
triggering
mechanism
to
route
it
accordingly,
without
even
seeing
the
data
just
by
looking
at
the
header.
That
is
what
we
call
this.
No,
no
look
routine.
We
can
route
it.
B
So,
as
I
told
earlier,
the
sources
and
brokers
are
the
main
parts
of
event,
so
we
need
the
source
to
take
the
data
from
the
actual
source
and
send
it
into
the
k
native
system
which,
which
is
actually
like.
The
job
of
the
source
is
to
like
take
the
data,
convert
that
into
cloud
even
format
and
send
it
to
the
processor
or
broker
right
so
k.
B
Nato
community
gives
a
lot
of
commonly
used
infrastructure
sources
like
github
kafka,
but
we
in
within
our
organization
we
have
like
sources
like
graphql
source
and
then
there's
a
lot
of
file.
Processing
that's
happening,
so
we
have
like
sources
for
s3.
We
have
sources
for
ftp
and
below.
I
have
given
an
example
of
like
how
to
write
a
source
in
my
medium
article.
You
can
take
it
so
the
sources
can
be
either
dedicated
or
it
can
be
a
dynamic
source
as
well.
Okay.
So
when.
A
B
So
if
you
remember
this
is
the
cloud
events
application
that
we
built
and
then
it
receives
only
cloud.
Even
if
you
send
a
normal
data,
it
will
not
be
able
to
display
it
here.
Okay,
let
us
try
to
send
a
normal
data,
so
this
is
the
data
that
I
once
sent,
and
this
is
the
kubecon
viewer.
So
when
I
send
it,
it
will
say
that
unsupported
media
type,
so,
as
I
told
so,
what
it
means
to
send
a
cloud
event
is
just
by
adding
these
headers.
B
B
B
Storing
your
data
eventually
and
trigger
here,
you
can
see,
I
have
two
functions:
kubecon
wear
and
knew,
and
the
k
n
viewer
is
expecting
a
message:
type
k,
n
type
and
the
kubecon
viewer
is
expecting
message:
dot,
cube
contact,
okay,
so
and
then
this
is
the
this
is
the
subscriber
it
wants.
Instead,
if
you
want
to
change
change
change
it
to
a
kubernetes
service,
you
can
also
do
that
open
it.
I
can
just
do
v1
and
then
this
will
be
a
kubernetes
service.
Okay,
so
this
is
already
created.
B
I
just
want
to
show
you
how
it
looks
like
now:
okay,
so
now,
instead
of
sending
the
kubecon
viewer,
we
are
going
to
send
it
to
the
through
the
broker.
Okay,
so
and
it
is
sending
message.kn.take.
So
here
is
the
k
n
viewer.
If
I
send
this
message,
we
should
show
the
message
here,
and
you
see
the
message
here:
okay
and
just
by
changing
the
message
type
to
kubecon.
B
A
A
As
I
already
explained,
a
lot
of
our
workloads
is
running
in
our
own
data
center
and
infrastructure.
360
provides
a
360
view
of
the
application
infrastructure
components
for
a
given
app
or
a
service
like,
for
example,
if
an
application
is
using
a
vm,
a
database
host
container,
namespaces
storage,
chargeback,
etc.
A
Let's
talk
about
another
common
use
case,
the
etl
use
case.
This
is
a
very
common
healthcare
use
case.
The
example
we
have
is
with
eligibility,
even
data
coming
from
various
sources,
as
listed
here
as
the
eligibility
data
flows
through
the
system.
There
is
a
lot
of
hops
and
business
logic
that
it
has
to
go
through
before
consumption,
but
with
this
rv
architecture
with
cloud
events,
it
has
helped
us
to
move
from
traditional
esb
and
etl
processing
that
happens
with
the
database
to
even
driven
functions.
A
B
So
before
that
there
are
like
multiple
health
devices,
apps
like
that,
like
more
than
40
or
40,
commonly
used
devices
and
health
apps,
and
then
a
lot
of
healthcare
companies
do
give
benefits
to
the
users
for
sending
their
data
over
and
within
optum.
Also,
so
we
have
like
various
implementations
and
programs
to
give
benefits
to
our
users.
So
the
one
that
we
are
going
to
show
here
is
mirroring
an
actual
implementation,
but
not
the
actual
implementation
itself
and
the
data
that
we
are
using
is
a
simulated
data.
B
So
for
just
for
this
use
case,
we
are
showing
these
three
even
sources
alone
and,
as
I
told
there
like,
multiple
even
sources,
okay,
so
first,
I
want
to
show
how
these
different
data
formats
look
like.
So
this
is
an
example
of
like
how
the
strava
format
looks
like
it's
a
json
format
though,
but
you
can
see
the
data
and
how
they
give
the
activities
are
totally
different
and
fitbit
is
also
a
json
format,
but
the
data
names
here
and
there
don't
even
match
and
the
duration
here
will
be
like
in
milliseconds
there.
B
It
is
in
seconds.
So
this
is
some
some
of
the
examples
and
then
run
keeper.
The
data
comes
in
csp
format,
it's
not
even
json,
so
that
is
the
different
challenges
and
then
for
other
apps
there
may
be
xml
and
some
devices
we
need
to
have
a
particular
sdk
so
like
each
apps
and
devices
have
their
own
challenges.
Okay,
so
going
back
to
this
use.
B
A
B
Various
services
deployed
and
before
that
I
just
want
to
show
I
just
want
to
talk
about
this
application
that
is
showing
a
graphical
view
of
the
functions,
depart
okay,
it's
called
graph
and
then
it
is
developed
by
one
of
the
kennedy.
Community
members
important
contributor,
called
scott
nichols,
and
if
you
want
more
details
about
this
graph,
you
can
go
to
this.
B
His
github
report,
okay
and
then
any
use
case
that
we
are
showing
here
all
these
use
cases
are
available
under
my
github
repo
github.com
okay,
so
you
can
take
a
look
at
the
source
code.
Okay,
now,
coming
back
as
use
case,
we
have
like
various,
even
processors,
lined
up
okay
on
the
right
side.
You
can
see
for
elliptical
data.
We
have
one
function
for
fitbit
data.
We
have
one
function,
so
write
data.
We
have
one
function:
okay,
this
is
all
processing
function.
So
what
about
data
injection
function?
For
data
injection?
B
On
the
left
side
you
can
see
there
are
various
data
injection
functions.
The
first
one
is
like
the
the
fitbit
data
it
takes
the
data
and
then
converts
it
into
four
different,
even
types
and
then
puts
it
back
into
the
broker,
for
which
there's
a
separate
data
addition.
So
for
binding,
binding
the
function
back
to
the
broker.
There
is
a
resource
that
k
native
provides.
It's
called
the
sync
binding.
B
The
job
of
the
sync
binding
is
just
to
inject
the
ingest,
the
inject
the
broker
url
or
any
sync
url
into
the
function.
Okay,
so
they
can
send
the
data
over
there.
So,
on
the
left
side,
it
is
the
data
injection
on
the
right
side
is
the
processing
function
in
the
middle?
Is
the
broker
and
the
broker?
You
can
see
what
all
the
triggers
that
we
created.
So,
as
I
explained
earlier,
if
the
trigger
type
is
held
at
elliptical
type,
it's
going
to
go
into
the
elliptical
data.
B
B
So
you
in
the
you're
going
to
see
all
the
applications
that
are
going
to
get
created
and
the
functions
that
are
going
to
create
it
here.
Okay,
so
on
the
bottom,
we
have
just
triggered
the
shell
script
to
start
the
data
irrigation
process.
So
once
the
data
is
ingested,
you're
going
to
see
the
functions
getting
triggered
for
like
various
processes,
but
everything
is
going
to
come
up
here.
Okay
and.
A
B
B
So
fitbit,
as
you
know,
is
like
the
most
complete
thing,
but
this
data
for
most
different
activities.
Okay,
so
that's
about
it!
That's
about
this
example.
The
use
case
demo
that
I
wanted
to
show,
so
we
are
taking
various
different
data
formats
and
consolidating
and
then
putting
loading
into
it
into
a
database
in
common
format
for
this
kind
of
view,
or
give
some
incentive
programs.
A
So
now
that
you
saw
the
cloud
events
in
action
with
various
optum
use
cases,
we
would
like
to
summarize
by
saying
why
we
like
cloud
events.
The
first
thing.
The
first
thing
that
comes
to
my
mind
is
you:
don't
have
to
boil
the
ocean
because
it's
an
industry
spec
and
binds
to
existing
protocols
and
integrates
with
current
optimum
assets,
be
it
messaging
or
eventing
stack.
A
Basically,
it's
just
a
wrapper
around
an
existing
event
and
we
are
currently
actively
exploring
serverless
workflow
for
orchestration
of
the
even
driven
functions
which
is
again
based
on
cloud
event:
spec
open
api
grpc.
This
is
by
using
this.
We
want
to
reduce
our
esb
footprint
and,
most
above
all,
we
would
like
to
thank
the
growing
community
support.