Let's talk about how azure SLA's can impact your application.
Any system can experience a failure.
Hardware breaks networking, has transient failures, and software has bugs and crashes,
even with all the redundancy built into azure services. And sometimes whole regions can experience a disruption
amongst the many things you need to think about when designing your applications is also its reliability.
Knowing your application requirements, you can make more informed decisions as to what as your services to use to achieve your performance goals
using as your zealous in your application architecture, you can build your own application SLA's that you can provide your customers with
resiliency is the ability of a system to recover from failure.
The goal is not to avoid failures, but to be able to respond to failures and avoid downtime or data loss.
Important components of resiliency are high availability and disaster recovery.
When designing your application, you should always design for resiliency.
One of the common traps application designers fall into is to maximize availability by implementing measures to prevent application failures.
The problem with this is that implementing preventative measures can be difficult and expensive.
Preventative measures also complicate the systems
increased availability always results in increased complexity, which results in higher cost.
Knowing the availability requirements for your application will determine how you handle the additional complexity.
One thing to consider when designing your application. SLA's is the level of automation built into your application.
If your application requires manual intervention and has no built in self healing capabilities,
achieving high SLA's is going to be difficult.
L. A. Is higher than three. Nines are hard to achieve.
You need to make sure that the effort warrants the return on investment,
the smaller the time window for your performance targets. The lower is to the tolerance you need to consider.
Do not use hourly or daily up times in your SLs because a small failure can throw you off of your metrics.
Here's how you can approach the calculation of your application. SLA's
Let's assume that you have a single VM that stores data into Cosmos DB
The S L. A. For the VM is 99.9% while the S L. A. For the Cosmos DB is 59
The composite s L A. For that system is 99.9% times 99.999 or 99.899 and something which is lower than the S L A. For both participating services.
This is understandable.
If this is not satisfactory for your application, you can, of course, improve it by adding a secondary VM.
The probability of simultaneous failure of both VMS is 0.1 times 0.1 or 0.1%.
The L A for simultaneously running VMS is 69 while the combined for the system is 99.9989%.
This is much closer to the for the most reliable component of the system.
notice that the complexity and the cost of the system has increased with the addition of another VM that will require maintenance and incur additional costs.
Now you are aware how azure SLS can impact your application SLS and how you can combine services to improve them.