Your clients do care about the whole availability of your application and service you provide to them to use it or consumed. They do not care about the separate SLA of your infrastructure and the software. The SLA you are calculating with Azure resources give you the highest SLA you can provide to your clients but when you add your software to the calculation then is difficult to estimate, because how can you estimate the downtime your REST API can have due to bugs, wrongful deployments, security related attacks.
Question about calculating an SLA for a REST-API
I am somehow stuck with my thoughts about an SLA definition, which I plan to determine for a RES-API running on a public cloud.
Imagine having a REST-API service running on Azure which has a database as a dependency. To calculate the SLA for the infrastructure part, I would use the following calculation, regarding that the components are serial.
App Service (Component Availability: 99.95%) --> SQL Azure (Component Availability: 99.95%) = Compound Availability: 99.9%.
But as mentioned at the beginning, I do provide as a service the REST-API for my clients. So looking only at the infrastructure part feels somehow wrong, and I would like to define the availability for the API.
Am I on the wrong path with thinking of it as two parts (application and infrastructure)? And if not, how would I estimate or define the value for a REST-API which does not exist today?
Sign in to comment
Sort by: Most helpful