Creating a cloud SLA from diagnostic data

Where do you start in order to have a successful port of applications into a private/public cloud?

By Gregory Machler, CSO |  Cloud Computing, iaas

More importantly, the diagnostic helps determine what functionality was required for input into a SLA (Service Level Agreement) between a company and its cloud service provider. The accurate creation of the SLA is another end goal of the analysis. How does one gain confidence that the SLA covers all the various types of failure by the service provider? What should be analyzed first? Performance metrics are still needed for each supported application. Here are some other questions that need to be answered in order to properly come up with the performance metrics. Again this is a representative list; it is not necessarily complete.

* What is the web browser application's best user response type?

* What is the web browser application's response time under load (20% concurrent users)?

* For each application's components in each cloud layer, how long will component failure need to recover?

* Will component failure impact a given application's browser experience?

* If total data center disaster occurs, how long will recovery take?

* What is the application cost for each different type of failure?

* Will any potential income will be lost for each application?

* What are the reputation (brand) costs associated with the failure of this application?

* What probability is there of a lawsuit if an application fails?

Lastly, a grid of information, a row per application, should be inserted into the SLA. In the SLA, each application should have functionality requirements, performance metrics and financial penalties for the various types of downtime errors. Note the service provider is not required to deploy an identical architecture with the same products and software with models and releases as the client's architecture. The providers must meet similar functionality and response times. Areas of architectural risk should also be noted in the SLA. For example: the database product in the PaaS layer may only be one vendor. A weakness in the database vendor's release of software could impact all the applications that use the given database, a systemic risk. This should be noted and the cost of downtime calculated. The cost of brand loss (if the application has public confidential data) and potential lawsuits should also be included in the SLA for each application.

In summary, a diagnostic can be used to analyze critical web-based corporate applications for a corporation considering putting their applications in a provider's cloud. The provider need not use the same architecture or products but it must meet the SLA for each application. Besides the diagnostic questions some performance data for each web application needs to be collected so that the SLA can be complete.


Originally published on CSO |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Cloud ComputingWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness