I am somehow stuck with my thoughts about an SLA definition, which I plan to determine for a REST-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?

  • 3
    What is the important thing your are providing a guarantee for? What guarantees does it consume in order to deliver? If it can operate regardless of a dependency being up or down, then that dependency has no effect. If however it goes down when a dependency goes down, then it matters, be it infrastructure or not.
    – Kain0_0
    Jun 23 at 4:39

Consider the things that might cause downtime and how you ameliorate them.

For the infrastructure its pretty easy, you can use the figures your cloud provider gives you and improve on that with multiple boxes, availability zones etc.

But for your code its tricky, you will have downtime related to :

  • Bugs
  • Deployments
  • Backwards incompatible releases
  • Downstream API providers (payments?)
  • Hack attacks (DDOS)
  • Migrations (when you change hosting)
  • Maintenance (don't need much of this in the cloud)

You can exclude some of these by giving an SLA for "unplanned downtime" rather than "downtime", so stuff where you know you will have downtime you can send out an email and it wont count against your SLA.

But bugs, hacks, botched deployments? things that should never happen are difficult to estimate. Keep accurate records and use last years figure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.