Meeting performance standards and SLAs in the cloud

Service-level agreements are common in network services and they measure the parameter set popularly called "QoS", but for cloud computing or platform services it's difficult to find helpful precedents for negotiating an SLA.

At the high level, the issues are the same; you must define criteria to be met and remedies if they are not. The devil is in the details, and to get there it's essential that you begin with the parameters of the application experience at the user level. The business case for cloud computing will be based on some expected range of availability and performance, and that's what the SLA must address.

The first point to address in a cloud SLA is that everything associated with an application experience isn't part of cloud computing. Cloud performance as measured at the point of application use is the sum of network performance, application performance, and cloud infrastructure performance. The cloud provider can be accountable for the last of these and not the first two, so it's important to understand what both the other factors contribute to overall performance when writing an SLA.

Accessing cloud services over the Internet or other best-effort service will make it very difficult to create a meaningful cloud SLA because the network contributes a completely variable delay, loss, and failure rate. If you want to guarantee transaction/application performance as experienced by the user, you'll need to somehow limit this variable. That may be possible if you can negotiate an SLA with a specific ISP with whom your cloud provider has a direct connection. If you expect to access cloud applications randomly from multiple locations and ISPs, a tight and meaningful application performance metric will be very hard to obtain.

Getting the application's performance variables out of the equation will normally mean running the application using local server and network resources to measure performance under ideal circ...