23/9/2020 Application SLA

Application SLA

Azure customers can use SLAs to evaluate how their Azure solutions meet their business requirements and the
needs of their clients and users. By creating your own SLAs, you can set performance targets to suit your specific
Azure application. When creating an Application SLA consider the following:
Es
te
do
Identify workloads. A workload is a distinct capability or task that is logically separated from other tasks, in
cu
m
terms of business elogicnto and data storage requirements. Each workload has different requirements for
pe
availability, scalability,
No data
rte consistency, and disaster recovery. To ensure that application architecture meets
es n
tán
your business requirements, ijm ecdefine
e target SLAs for each workload. Account for the cost and complexity of
pe .con a Ju
rm
meeting availability requirements, tre inanaddition to application dependencies.
itid r
as as@ Man
las gm uel
Plan for usage patterns. Usagecopatterns a also C play a role in requirements. Identify differences in requirements
pia il.co ollan
during critical and non-critical periods. m
s sFor example, tesa tax-filing application can't fail during a filing deadline. To
in Co
ensure uptime, plan redundancy across several au nin
tor regions trecase one fails. Conversely, to minimize costs during
iza ras
non-critical periods, you can run your applicationciin ón a single region.
.
.
Establish availability metrics — mean time to recovery (MTTR) and mean time between failures (MTBF).
MTTR is the average time it takes to restore a component after a failure. MTBF is how long a component can
reasonably expect to last between outages. Use these measures to determine where to add redundancy and
Es
te service-level agreements (SLAs) for customers.
to determine do
cu
me
Establish recoveryntmetrics
op — recovery time objective and recovery point objective (RPO). RTO is the
No ert
maximum acceptable
es time e n application can be unavailable after an incident. RPO is the maximum duration of
an
tán ijm ece
data loss that is acceptable
pe . c a a disaster. To derive these values, conduct a risk assessment and make
during
rm ontre Juan
sure you understand the itcost
ida and
r a risk Mof downtime or data loss in your organization.
s la s@g anu
sc ma el C
Implement resiliency strategies. il
opResiliency o the ability of a system to recover from failures and continue to
is
ias .com llant
function. Implement resiliency design patterns, sin suchesas isolating critical resources, using compensating
au Co
transactions, and performing asynchronous ooperations t ntr
whenever possible.
riz era
ac s.
ión
Build availability requirements into your design.. Availability is the proportion of time your system is
functional and working. Take steps to ensure that application availability conforms to your service-level
agreement. For example, avoid single points of failure, decompose workloads by service-level objective, and
throttle high-volume
Es users.
te
do
cu
m
Understand yourentapp o p requirements
No ert
es en
t ij ec
Building an efficient and á m
n preliable e a solution requires knowing your workload requirements. You can then select
.co Azure
erm ntr Jua
Azure products and services,itiand provision e n resources according to those requirements. It's important to understand
da ras@ Ma
s la n
the Azure SLAs that define performance g ma uelfor
s c targets Co
the Azure products and services within your solution. This
o p i l. lla
understanding will help you create achievable ias coApplication
m nte SLAs.
sin sC
au on
In a distributed system, failures will happen. Hardware tor can treThe network can have transient failures. It's rare for
fail.
iza ras
an entire service or region to experience a disruption,cióbut n. even this. must be planned for.

Resiliency
Es
te ability of a system to recover from failures and continue to function. It's not about avoiding failures,
Resiliency is the do
cu
but responding to failures
me in a way that avoids downtime or data loss. The goal of resiliency is to return the
nto
application to a fully functioning
pe state following a failure. High availability and disaster recovery are two crucial
No rte
components of resiliency.
es n
tán ijm ece
pe . c a
rm ontre Juan
When designing your architecture itid you ras need Mato design for resiliency, and you should perform a Failure Mode
as @ nu
Analysis (FMA). The goal of an FMA las is to gmidentifyel possible points of failure and to define how the application will
co ail Co
respond to those failures. p .
ias com llant
sin es
au Co
tor ntr
iza era
Cost and complexity vs. high availability ció s.
n.

Availability refers to the time that a system is functional and working. Maximizing availability requires implementing
measures to prevent possible service failures. However, devising preventative measures can be difficult and
expensive, and Es often results in complex solutions.
te
do
cu
As your solution grows mein complexity, you will have more services depending on each other. Therefore, you might
nto
overlook possible failure pointspe in your solution if you have several interdependent services.
No rte
es ne
t ij c
https://www.skillpipe.com/#/reader/book/2e7c28ed-154c-59cb-8ee9-9897b08254a2 1/2
23/9/2020 Application SLA
Tip - For example: A workload that requires 99.99 percent uptime shouldn't depend upon a service with a 99.9
percent SLA.

Most providers prefer to maximize the availability of their Azure solutions by minimizing downtime. However, as you
increase availability, you also increase the cost and complexity of your solution.

Tip - For example: An SLA that defines an uptime of 99.999% only allows for about 5 minutes of total downtime per
year. Es
te
do
cu
me
The risk of potential downtime is cumulative across various SLA levels, which means that complex solutions can
nto
face greater availability pe
challenges. Therefore, how critical high-availability is to your requirements will determine
No rte
how you handle theesaddition ne
tán ijmof complexity
ce and cost to your application SLAs.
pe .con a Ju
rm tre an
itid r Ma
Considerations for defining as as@ application SLAs
las gm nuel
co ail Co
pia . c l lan
s s om tes
If your application SLA defines four 9's (99.99%) in
au performance Co targets, recovering from failures by manual
ntr
tor era
intervention may not be enough to fulfill your SLA. izYour ac Azure solution must be self-diagnosing and self-healing
i ó s.
instead. It is difficult to respond to failures quickly enough n . to meet SLA performance targets above four 9's.
Carefully consider the time window against which your application SLA performance targets are measured. The
smaller the time window, the tighter the tolerances. If you define your application SLA as hourly or daily uptime, you
need to understand these tighter tolerances might not allow for achievable performance targets.
Es
te
✔ Performance targetsdo
cu about 99.99% are going to be very difficult to achieve.
me
nto
pe
No rte
es n
tán ijm ece
pe .con a Ju
rm t an
itid rera
as s@ Man
las gm uel
co a C
pia il.co ollan
ss m tes
in Co
au ntr
tor era
iza
ció s.
n.

Es
te
d oc
um
ento
pe
No rte
es n
tán ijm ece
pe . c a
rm ontre Juan
itid ras Ma
as @
las gm nuel
co a C
pia il.co ollan
ss m tes
in Co
au ntr
tor era
iza
ció s.
n.

Es
te
d oc
um
ento
pe
No rte
es n
tán ijm ece
pe . c a
rm ontre Juan
itid ras Ma
as @
las gm nuel
co a C
pia il.co ollan
ss m tes
in Co
au ntr
tor era
iza
ció s.
n.

Es
te
d oc
um
ento
pe
No rte
es ne
t ij c
https://www.skillpipe.com/#/reader/book/2e7c28ed-154c-59cb-8ee9-9897b08254a2 2/2