►
Description
Microsoft 365 is not just one of the best set of collaboration tools to realize the modern digital workplace. Microsoft 365 is a great platform for building business-level solutions, too. In this session, you will understand how to define the architecture of a Microsoft 365 custom developed solution, how to leverage the infrastructural services that are at the basis of Microsoft 365, and how to leverage the full ecosystem of services provided in the Microsoft 365 offering. You will understand what is the right location in a business-level architecture for services like Azure AD, Microsoft Graph, Azure App Services, Azure Functions, etc.
Speaker: Paolo Pialorsi (PiaSys.com) | @paolopia
Supporting materials:
• What is Azure Service Bus? - https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview
• What are Durable Functions? - https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp
• What is Application Insights? - https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
• PnP SharePoint Provisioning Service - https://github.com/SharePoint/sp-provisioning-service
• Q&A of my session “Architecture of Custom Microsoft 365 Solutions” - https://piasys.com/blog/pnp-virtual-conference-qa-of-my-session-architecture-of-custom-microsoft-365-solutions/
Learn more:
• Learn more about the Microsoft 365 Patterns and Practices (PnP) community at: http://aka.ms/m365pnp
• Visit the Microsoft 365 Patterns and Practices community YouTube channel: https://aka.ms/m365pnp-videos
A
Hello,
everybody
and
welcome
to
the
pmp
virtual
conference,
I'm
paulo
pelosi
from
psysis.com,
and
today
we
are
going
to
talk
about
the
architecture
of
custom
solutions
built
on
top
of
microsoft,
365.,
before
digging
into
the
content
of
the
session.
Let
me
spend
few
words
about
myself,
I'm
paolo.
I
work
in
a
company
of
my
own
called
psys.com,
which
is
based
in
italy
and
in
the
usa
and
on
a
daily
basis.
I
support
my
customers
to
create
or
migrate
solutions
for
max
electricity.
A
5.,
specifically,
I
support
customers
to
migrate
solutions
from
the
old
school
development
model
to
the
sharepoint
framework.
I
help
customers
to
create
microsoft,
teams,
custom
developed
solutions
and
I
help
customers
to
migrate
from
old-school,
workflows,
based
solutions
to
power,
automate
and
logic
apps
on
a
daily
basis.
I
love
spending
time
with
my
family.
Indeed,
as
well
as
I
love
to
do
my
job,
because
my
job
is
actually
my
hobby
and
I
really
like
driving
my
car.
A
A
So
in
this
session
we
are
going
to
have
a
look
at
the
architecture
of
a
microsoft,
265
custom
solution,
and
specifically,
we
will
see
what
the
services
are
in
microsoft,
265
and
in
microsoft,
azure
that
we
can
leverage
to
create
a
custom
solution
built
on
top
of
microcentricity
5..
At
the
end,
we
will
also
put
it
all
together
and
see
the
architecture
of
the
real
solution
which
most
likely
you
already
know,
which
is
the
microsoft
lookbook
site.
As
a
side
note
here,
I'm
going
to
share
what
is
my
experience
on
the
fields?
A
A
Just
to
make
an
example,
we
can
create
process,
automation,
solutions
so,
for
example,
document
management,
approval
flows,
hr
or
hse
procedures
and
stuff,
like
that,
you
can
create
automated
provisioning
solutions,
which
includes
provisioning
of
scythe
in
sharepoint
online
or
of
teams
in
microsoft
teams
or
both
of
them
so
sites
and
teams
all
together
in
a
unique
solution,
or
you
can
build
the
solution
for
line
of
business
integration.
So,
for
example,
you
can
integrate
with
the
purchase
order
system.
You
can
create
customers
and
suppliers
sign
up
or
registration
forms
and
stuff
like
that.
A
So
this
is
just
a
small
set
of
examples
of
solutions
that
you
can
build,
leveraging,
microsoft,
365
and
whenever
you
do
that
there
are
some
technical
challenges
that
you
need
to
face
and
that
you
need
to
manage
defining
the
architecture
of
your
solution.
This
is
just
a
small
set,
even
if
it
is,
it
looks
like
a
wide
set
of
challenges,
but
they're.
Just
these
are
just
the
most
important
challenges
when
you
create
a
solution.
A
The
eye
availability
is
scalability.
This
security
providing
a
proper
ui
set
of
elements,
business
logic,
hosting
of
the
solution,
managing
of
multiple
environments
and
tenants,
having
a
content
repository
for
your
content
and
documentation,
having
monitoring
and
telemetry
in
place
and,
of
course,
defining
an
architecture
which
is
a
maintainable
architecture
on
the
group.
So,
let's
talk
about
all
of
these
challenges
and
let's
see
what
the
solutions
are
nowadays,
whenever
you
want
to
create
such
kind
of
solution,
thinking
about
eye
availability
and
scalability,
one
main
topic
is
the
persistent
storage.
A
So
whenever
you
need
to
store
data,
if
you
need
to
store
data,
of
course,
you
need
to
define
the
target
persistence
layer
based
on
the
kind
of
data
that
you
want
to
store.
So,
for
example,
if
you
want
to
store
list
items
objects
and
such
kind
of
stuff,
one
option
could
be
to
use
a
truly
relational
solution,
like
azure
sql
database,
eventually
with
entity
framework
in
the
backend
with
dot
net
core.
A
But
if
data
is
not
relational,
you
should
consider
using
a
polyglot
persistence
infrastructure
like,
for
example,
your
cosmos
db,
for
example,
for
storing
lists
of
items
or
objects
with
a
huge
amount
of
items.
You
shouldn't
use
a
sharepoint
list
because
you
would
have
slow
performances,
least
new
threshold
issues
and
also
complex
life.
While
writing
the
queries
to
query
the
list.
Eventually,
you
can
consider
microsoft
lists,
but
in
my
opinion,
for
this
kind
of
list
of
items
and
objects,
a
relational
database
or
a
polyglot
system
are
the
best
options.
A
On
the
contrary,
if
you
need
to
store
documents
or
files,
try
to
use
sharepoint
online
and
onedrive
for
business,
because
that's
why
they
are
here
and
you
can
use
microsoft
graph
or
eventually,
you
can
fall
back
onto
spo,
rest
and
csum
to
access
those
documents.
Those
files
are
stored
in
sharepoint,
online
and
onedrive
for
business.
Still
from
an
high
availability
and
scalability
point
of
view,
you
shouldn't
write,
custom
code,
or
at
least
you
should
style,
should
try
to
stay
away
from
custom
code
as
much
as
you
can.
A
But
if
you
really
need
to
write
custom
code
at
least
you
should
make
it
possible
to
have
that
code
highly
available
and
scalable,
meaning
that
you
need
to
make
it
asynchronous.
Always
you
need
to
make
the
code
repeatable
it
important,
monitorable
and
maintainable
on
the
go.
So
you
need
to
take
care
of
the
versioning.
A
You
need
to
have
a
proper
deployment
plan,
a
proper
release,
plan
and
stuff
like
that,
because
you
need
to
be
a
responsible
developer
still
about
scalability
and
availability,
as
I
said,
always
write
asynchronous
code,
so
avoid
writing
business
logic
in
the
ui,
avoid
having
in
the
web
part
in
the
ui
widget
in
the
teams.
Tab.
The
business
logic
rather
use
a
backend
asynchronous
set
of
microsoft,
microservices
that
you
can
execute
in
the
background
and
that
you
can
fire
using
an
azure
function,
a
blob
storage
queue
or
a
service
bus.
A
My
opinion,
you
should
never
live,
execute
complex
tasks
in
the
ui.
Rather,
you
should
enqueue
requests
to
execute
them
and
then
process
them
in
the
back
end.
Some
ideas
to
do
that.
Well,
first
of
all,
if
you
have
a
web
ui
or
a
native
app,
you
can
rely
on
a
backend.
Azure
function,
eventually
durable
function
and
do
the
stuff
in
the
background,
but
in
case
of
any
failure
of
the
function
or
of
the
connection
between
the
ui
and
the
function.
A
Of
course,
your
solution
will
not
be
highly
available
so
to
improve
the
availability
you
should
put
in
the
middle
between
the
front-end
and
the
back-end
storage
queue
so
that
you
can
use
an
asynchronous
pattern.
You
can
store
a
message
in
the
queue
and
the
job
and
the
function
will
dequeue
the
message
and
process
it
as
soon
as
they
are
available
for
a
better
availability
and
for
a
more
enterprise
level
solution.
A
You
should
consider
using
a
service
bus
instead
of
the
storage
queue,
because
the
service
bus
is
a
more
enterprise
ready
service
on
azure
rather
than
the
storage
queue.
In
fact,
with
the
service
bus,
for
example,
you
can
suspend
the
queue
you
can
stop
listening
for
a
queue
and
then
you
can
resume
listening
when
you're
ready
when
you
updated
the
job,
for
example
or
stuff
like
that.
A
Still
talking
about
scalability
and
availability.
Think
about
caching,
the
best
way
to
fast
execute
code
is
to
not
execute
it
so
use.
Caching,
you
can
use
azure
redis
cache
to
store
objects
and
state
information.
You
can
use
the
azure
blob
storage
to
store,
binaries
and
blobs
so
that
you
can
make
them
available
through
a
content
delivery
network,
and
you
can
use
sharepoint
online
and
onedrive
for
business
to
store
files
files
that
you
can
eventually
convert
on
the
fly
into
pdf
using
the
microsoft
graph.
A
So,
for
example,
if
you
are
storing
invoices
or
quotes
or
stuff
like
that,
you
can
easily
convert
them
into
pdf
on
the
fly
with
microsoft.
Graph
from
a
security
point
of
view,
authentication
and
authorization
really
matter
in
any
kind
of
solution,
specifically
in
a
micro,
testify
solution
where
you
should
rely
on
azure
active
directory
so
always
always
use
azure
directory
for
managing
and
storing
users,
roles,
apps
and
permissions
register.
All
of
your
application
in
azure
active
directory,
the
front-end
application
most
likely
we
use
delegated
access
tokens.
A
A
If
you
are
creating
and
registering
an
application
in
your
directory,
a
very
common
question
is:
should
I
create
it
as
a
single
tenant
or
as
a
multi-tenant
solution?
Well,
generally
speaking,
this
is
just
a
general
rule.
If
your
application
is
targeting
just
one
company,
just
one
tenant,
you
should
go
for
single
tenant.
If
you
are
creating
a
solution
that
you
want
to
sell
to
provide
to
multiple
customers.
Well,
you
should
go
for
multiple
tenant
solutions.
A
Whatever
will
be
your
choice,
hope
and
authorization
is
your
best
friend,
so
configure
authentication
for
your
application.
If
it
is
application,
only
you
should
prefer
using
an
x519
certificate
for
authentication
rather
than
the
shared
secret,
and
configure
the
permission
that
you
need
to
access
the
backend
apis,
whether
it
is
the
micrograph
or
the
sharepoint
online
apis
or
power
bi
or
whatever
else
use
the
delegated
permissions.
If
you
need
to
execute
the
tasks
on
behalf
of
the
user,
so
from
a
front-end
or
an
active
application,
use
the
application
permissions.
A
Whenever
you
need
to
store
secure
information
like
this
certificate
for
x509
application,
authentication
or
a
shared
secret
or
whatever
else,
you
should
rely
on
azure
key
vault,
which
is
the
right
place
to
store
tokens,
password
certificates
and
stuff
like
that,
as
well
as
sensitive
application
settings,
but
keep
in
mind
that
the
azure
key
folder
is
scalable.
If
you
read
it,
however,
if
you
plan
to
have
high
volume
right
on
the
keyboard,
that's
not
the
intended
use
for
that
service
and
you
will
easily
get
throttled.
A
So
that's:
okay
to
use
azure
key
vault
for
high
volume
wreath.
It
is
not
okay
to
use
the
azure
key
volt
for
high
volume
right
and
eventually
you
will
have
to
think
about
something
else
like
a
sql
database
with
encrypted
table,
or
something
like
that
when
you
use
azure
key
volta,
try
to
avoid
using
a
user
account
to
access
the
key
volta
rather
use
an
azure,
managed
identity
and
configure
an
application
if
you're
id
granting
that
application
the
right
to
access
the
azure
key
vault.
A
When
you
define
the
user
interface
of
your
solution,
usually
I
try
to
use
microsoft
teams
as
the
host
nowadays,
because
it
is
the
best
option.
The
fully
integrated
option
that
most
of
the
companies
and
enterprise
companies
are
willing
to
use
nowadays.
So
I
create
sharepoint
framework
with
parts
that
I
host
in
microsoft
teams
or
I
create
personal
or
custom
team
tabs
using
yeoman
generator
for
teams,
and
I
create
the
ui
inside
microsoft
teams
so
that
it
is
fully
integrated
with
the
experience
that
users
use
on
a
daily
basis.
A
Nowadays,
if
you
need
to
collect
information
from
the
users,
you
can
use
powerapps
hosted
inside
teams.
You
can
use
adaptive
cards,
you
can
use
logic,
apps
and
power
automate
and
adapted
cars
in
between
still
hosted
in
microsoft
teams,
and
if
you
need
to
provide
a
feedback
to
the
users,
you
can
write
back
to
the
channels
or
to
a
chat
using
a
bot,
for
example,
or
you
can
use
the
graph
api
to
write
back
into
a
channel
and
use
the
graph
api
to
interact
with
microsoft
teams.
A
A
If
you
want
to
use
power
automate,
that's
the
great
option
for
personal
processes
and
flows.
So
in
my
opinion,
it
is
a
user-centric
software-as-a-service
solution
for
building
processes
and
flows,
personal
processes
and
flows.
It
is
mainly
focused
on
approval
processes,
synchronization
processes
and
notifications,
and
it
is
fully
integrated
with
the
out
of
the
box
workloads
of
microsoft
365,
as
well
as
with
external
applications.
A
If
you
want
to
build
something
enterprise
ready
and
with
the
idea
of
enterprise
level
processes
and
solution.
Personally,
I
rather
use
logic
apps,
which
is,
in
my
opinion,
again
a
process
centric
platform
as
a
service
offering
it
has
a
deeper
integration
with
external
systems
like
adi
business,
to
business
systems
and
stuff,
like
that,
it
is
at
the
basis
of
power
automate,
nevertheless,
so
same
engine
same
web-based
designer
same
connectors,
but
also
with
a
designer
for
visual
studio.
A
If
you
want
to
build
the
solution
that
you
also
want
to
maintain
from
a
source
control
point
of
view,
you
can
eventually
think
about
writing
custom
code.
But,
as
I
said
as
a
responsible
developer,
you
should
try
to
stay
away
from
custom
code
as
much
as
you
can.
But
if
you
will
do
that,
because
you
need
to
do
something
really
uncommon
mind
the
hidden
cost
of
management
and
maintenance
of
your
custom
code
and
then
still
do
that,
because
if
you
need
it,
why
not
whenever
you
will
use
our
automated
logic,
apps
or
custom
code
micrograph?
A
Is
your
master
key
to
access
microsoft,
365
resources?
You
can
use
microsoft
graph
to
access
every
kind
of
object
in
your
solution
and
microsoft.
Graph
is
the
right
choice
whenever
you
need
to
read
to
consume,
to
manage
the
resources
in
microsoft,
365
from
a
developer
point
of
view,
you
can
access
users,
groups,
teams,
everything.
Almost
everything
in
microsoft,
365
workloads
keep
into
account
that
the
v1
version
of
the
graph
is
the
released
one,
the
production
one.
A
In
the
back
end,
once
you
have
defined
a
solution,
you
need
to
host
that
solution
and
again
my
suggestion
is
to
use
azure
app
services
in
digital
web
apps
or
eventually
the
azure
static
web.
If
you
just
need
to
provide
static
content
like
javascript,
css
and
stuff,
like
that,
so
that
you
can
easily
enable
the
cdn
of
azure
static
web
and
provide
the
content
with
a
really
quick
and
available
infrastructure,
you
should
leverage
the
deployment
slot
of
azure
app
services
so
that
you
can
easily
manage
multiple
environments.
More
will
come
on
this
topic
soon.
A
You
should-
or
at
least
you
can
leverage
the
azure
active
directory
integration
for
authentication
so
that
you
can
easily
authenticate
users
in
your
azure
app
service
using
still
using
azure
directory,
which
is
the
central
point
of
security
in
your
solution.
Architecture,
and
if
you
want,
you
can
leverage
azure
web
jobs,
sharing
the
same
hosting
environment
or
azure
functions,
sharing
the
same
app
service
plan
so
that
you
can
have
a
unique
coast
center
in
azure
for
hosting
all
of
these
services.
A
Whenever
you
create
an
app
service,
an
app
web
hosting
app
service,
you
should
try
to
rely
on
netstandard
and
net
core
to
have
a
lightweight
solution,
eventually
containerized
in
a
container.
Nowadays,
if
you
are
targeting
sharepoint,
you
can
use
csm4.net
standard
and
soon
we
will
also
have
the
pmp
core
sdk,
which
is
a
graph
first
sdk
which
targets.netstandard
and
net
core.
A
So
what
if
you
need
to
manage
multiple
environments?
Well,
let's
assume
that
you
need
to
manage,
for
example,
a
dev,
a
test
staging
and
a
production
environment.
You
can
leverage
the
deployment
slot
on
the
azure
app
services.
This
will
allow
you
to
have
multiple
environments
within
a
unique
app
service.
You
can
have
settings
local
to
a
specific
slot
or
settings
shared
across
all
of
the
slots,
and
you
can
easily
manage
the
life
cycle
of
your
sloth
in
an
independent
way.
A
At
the
same
time,
you
can
easily
swap
across
different
environments.
So,
for
example,
you
can
switch
swap
from
test
to
production
or
you
can
do
testing
with
something
like
the
first
release
we
have
in
mexico
65.
So
you
can
say
that
you
want
to
provide
the
staging
release
of
the
solution
to
the
30
percent
of
the
users,
and
you
want
to
provide
the
reminder:
users,
the
70
percent
of
reminder,
user
with
the
production
really
version
of
the
solution,
so
that
you
can
do
testing
of
your
new
solution
step
by
step.
A
All
you
need
to
keep
into
account
that
when
you
work
with
the
premium
slot
in
a
unique
azure
app
service,
you
have
a
unique
bill
to
pay
the
pay
for
that
specification,
app
service
plan
and
you
don't
pay
for
every
single
slot.
But
you
pay
just
for
the
app
service
plan,
which
is
really
good
from
a
budgeting
point
of
view.
A
A
Well,
if
you
can,
you
should
try
to
use
just
a
unique
tenant
for
test
staging
and
production
so
that
you
can
reuse
the
same
set
of
users,
the
same
as
your
active
directory,
the
same
taxonomy,
the
same
app
registration
in
interactive
directory,
and
you
can
simply
play,
for
example,
in
the
fields
of
sharepoint
online,
with
app
catalogs
local
to
a
specific
set
collection
for
local
testing
and
local
versioning,
or
upgrade
tests
in
a
local
site
collection.
When
you
are
ready,
you
release
the
solution,
the
global
catalog
of
the
tenant.
A
On
the
contrary,
if
you
need
to
do
something
which
is
tenant
specific,
like
reading
and
writing,
taxonomy
provisioning
users
or
resources,
or,
generally
speaking,
touching
these
settings
at
tenant
level,
well,
you
will
need
to
fall
back
to
having
multiple
tenants.
If
you
will
do
that,
of
course,
it
will
be
a
bigger
challenge
for
you,
but,
as
I
said,
if
you
really
need
to
do
that,
why
not
nothing
against
that?
A
If
you
need
to
store
content
like,
for
example,
documentation
files,
sample
content?
Well,
one
option
is
to
use
of
course,
onedrive
for
business,
and
you
can
also
consider
using
onedrive
for
business
to
store
personal
settings
of
the
users.
In
fact,
you
can
easily
get
to
the
microsoft
graph
api,
a
special
folder
for
every
single
application
register
in
azure
directory
and
in
there
on
a
user
basis,
you
can
store
user
specific
personal
settings,
for
example,
as
a
json
file.
A
Moreover,
if
you
need
to
store
documents
with
metadata,
you
should
consider
using
sharepoint
online
with
a
proper
information
architecture,
so
fields,
content,
types
and
libraries
avoid
using
the
content
type
hub.
That's
my
advice,
because
that's
an
old
technology
not
properly
working.
Nowadays,
you
should
rather
use
the
pmp
provisioning
engine
or
any
other
provisioning
technique
of
your
choice,
so
that
you
can
keep
the
content
types
in
sync
across
multiple
site
collections,
without
relying
on
the
content
type
hub.
A
On
the
contrary,
if
you
simply
need
to
store
content
like
documentation
or
stuff
where
you
need
to
have
multiple
authors
with
a
flow
to
manage
the
authoring,
you
should
consider
using
github
as
the
repository
for
this
kind
of
content,
and
you
can
leverage
the
git
model
to
manage
issues
commit
for
requests
and
stuff
like
that,
and
you
can
easily
read
the
content
from
github
using
the
rest
apis
of
the
github
platform
from
a
monitoring
and
telemetry
point
of
view.
Well,
you
can
use
application
insight
again.
That's
my
advice.
We
use
it
heavily
in
our
solutions.
A
A
If
you
want
to
store
information
about
user's
behavior,
you
can
consider
using
an
azure
sql
database
for
symmetric
data
or
a
cosmos
db
for
asymmetric
nosql
data,
so
that
you
can
then
easily
build
a
power
bi
dashboard
on
top
of
these
users,
behavioral
data
and
eventually
on
top
of
application
inside
telemetry
data.
This
is
really
powerful
and
you
can
keep
an
eye
and
you
can
control
and
measure
the
performances
and
the
availability
of
your
solution
using
this
kind
of
approach.
A
From
a
maintainability
point
of
view,
whenever
you
define
a
solution,
you
should
think
about
the
maintenance
of
the
solution.
When
you
define
the
architecture,
so
you
shouldn't
define
the
maintenance
plan
as
a
side
effect.
At
the
end
of
the
solution,
but
you
should
include
in
the
architectural
design
the
definition
of
the
maintenance
plan
of
your
solution,
and
you
should
choose
the
technologies
that
you
want
to
leverage
in
your
solution
based
on
the
maintenance
plan
and
on
the
goals
that
you
have
from
a
maintenance
point
of
view.
A
So,
for
example,
and
again
in
my
opinion,
you
should
rely
on
azure
app
services
with
deployment
slot
to
have
a
warm
update
of
the
solution.
You
should
use
the
azure
service
bus
for
asynchronous
communication
and
not
the
blob
storage
queue
or
other
asynchronous
communication
systems,
because
with
the
service
bus,
you
can
easily,
as
I
said,
suspend
the
queue,
suspend
listening
for
a
queue.
You
can
update
the
job
and
you
can
resume
listening
for
that
queue.
Once
the
job
has
been
updated
or
the
function.
A
So
that
said,
let
me
show
you
the
real
architecture
of
a
solution
that
most
likely
you
already
used
in
production.
The
microsoft
sharepoint
lookbook
site,
the
sharepoint
lookbook
site
is
a
site
provided
by
microsoft,
to
provision
site
collections
and
site
templates
in
sharepoint
online
leveraging
the
modern
ui
of
spo,
and
this
is
a
solution
fully
based
on
max
35.
A
This
falls
into
the
category
of
provisioning
solutions
and
it
has
a
really
nice
and
interesting
architecture,
specifically
for
the
sake
of
discussing
the
architectural
choices
that
we
made.
So,
first
of
all,
we
have
the
front
end:
the
lookbook.microsoft.com
site,
which
nowadays
is
available
to
tenant
admin
users,
but
also
to
common
site
collection
owners
so
common
end
users,
when
a
users
make
a
request
to
the
lookbook
site
to
provision
a
new
site
template.
A
In
order
to
process
the
actual
request.
We
need
to
have
a
token
which
will
allow
us
to
access
the
target
environment
on
behalf
of
the
requesting
user.
That's
why
we
store
the
refresh
token
in
the
sql
azure
database
as
an
encrypted
object,
and
that's
why
we
read
that
refresh
token
from
the
sql
database
into
the
job,
and
we
use
the
refresh
token
to
make
a
request
for
an
access
token
in
azure
active
directory.
A
By
doing
that,
we
will
be
able
to
use
the
micrograph
and
the
sharepoint
rest
api
working
on
behalf
of
the
user
consuming
and
requesting
the
provisioning
through
the
lookbook
site,
and
we
will
be
able
to
create
the
target
set
collection
on
behalf
of
the
user
and
to
do
all
of
the
stuff
on
behalf
of
the
user.
Then
we
get
rid
of
the
refresh
token.
A
We
recycle
it
with
an
expired
policy
to
not
get
any
sensitive
information
longer
than
needed,
and
we
store
all
of
the
telemetry
information
both
on
the
web
application
and
for
the
web
job
in
the
application
inside
service.
The
side
note
we
use
github
as
the
repository
for
the
content,
both
for
the
ui
and
for
the
web
job.
So
all
of
the
templates
are
stored
and
maintained
in
the
github
repository
that
we
have.
So.
This
is
a
clear
example
of
a
middle
complex
solution.