When companies migrate their business processes to the cloud, service assurance will be an important aspect of the migration. CEOs need to be reassured that a minimum acceptable level of service will be provided and that there will be legal safeguards to ensure that this level of service can be enforced. Only when a vendor will offer guarantees instead of disclaimers will any prudent CEO agree to move away from the certainty of on-premise IT.
Therefore, all competent cloud services providers understand that a well written Service Level Agreement (SLA) is a document that instills confidence in the corporate user and is instrumental in getting more customers. There are also nuances to the SLA that must be understood by users if they are to get the best out of their solutions.
In a number of cases, vendors specify an uptime of 99.5% or more for your service. But they also say that to get this level of service, you need to hire the service so as to operate from two different geographic locations. Obviously, if you do not hire the service correctly, you will not get the guaranteed up-time. This is a typical case of understanding the SLA correctly.
There are several issues in cloud SLAs that are different from other service level agreements. This is due to the very nature of the cloud itself and these factors need to be understood well. Some of these issues are discussed below. They must be carefully handled in the SLA.
Who owns the Metadata?
The first of these relates to the ownership of data. If you were simply hiring storage space in the cloud, things would be straightforward. Whatever data you store is yours. But if you are hiring Software as a Service, things can get more complex. The business related data that the software generates is obviously yours, but what about other data that the software creates – the one that relates to usage trends, failed login attempts, metadata, user feedback, preferences and complaints, traffic statistics? Do these belong to the client hiring the software or the company hosting the software? You will need to understand these issues and the criticality of these to your business before you sit down to draft the SLA.
What happens if the government wants to see your data?
Your service level agreement must define what will happen in case a government agency makes a request for your data. While the service provider may be legally bound to comply with the government request, your SLA must clarify that your company will be informed
before any data is actually handed over so that you have the opportunity to take necessary action such as contesting the demand or obtaining legal counsel. On the other hand, there are legal requirements of archiving and maintaining your data, this is specifically so for financial or medical data. The service provider must be told this specifically through the SLA so that he becomes duty bound to protect the data. Also make it clear that in case there is a failure to meet these obligations, what would be the extent of legal penalties etc that the service provider would be liable for.
Well-Defined Metrics
The SLA must also describe in detail how the level of service and the uptime that the vendor is providing will be measured. How will service requests be handled and in what timeframe? What would the penalties be for not meeting them?
Data Security
Other important issues that the SLA must address in detail are levels of data security and segregation that the vendor will provide and what will constitute a security breach. While it may seem unnecessary to define what a breach would be, it is important to do so because at times there could be an incident that does not result in a loss of data or business but is nevertheless important. The SLA must specify that every breach or incident affecting your company or its data is reported to you along with the remedial action taken. You must also ensure that the provider gives you advance warning of any maintenance being carried out that may slow down your service. It is also critical to ensure that in case of a disaster – natural or manmade what will be the service provider’s role in supporting your business continuity.
Termination
There are issues of termination of the relationship, what assistance will the vendor provide in case you want to migrate your applications to another vendor or bring them back in-house. Whether the vendor can outsource your work to another cloud provider and if so then what terms of the SLA would apply to the new vendor must all be clarified in the SLA.
Is all of this possible?
Will you be able to meet all these terms and more when you set out to move to the cloud? If you are a small company without much leverage, chances are you will not. You may not even get to meet any of the staff of the cloud company since all activities may be completed on-line with a standard SLA. However, these are issues that you must think about. Obviously, if you are a large company giving big business to the vendor, you will have more leverage, but whether you are big or small, the importance of understanding the SLA clearly cannot be overstated.
Be Part of Our Cloud Conversation
Our articles are written to provide you with tools and information to meet your IT and cloud solution needs. Join us on
Facebook and
Twitter.
About the Guest Author:
Sanjay Srivastava has been active in computing infrastructure and has participated in major projects on cloud computing, networking, VoIP and in creation of applications running over distributed databases. Due to a military background, his focus has always been on stability and availability of infrastructure. Sanjay was the Director of Information Technology in a major enterprise and managed the transition from legacy software to fully networked operations using private cloud infrastructure. He now writes extensively on cloud computing and networking and is about to move to his farm in Central India where he plans to use cloud computing and modern technology to improve the lives of rural folk in India.
