Cloud SLA: How to Get it Right

When choosing a cloud provider, customers' first criterion is guaranteed data safety and reliability. Therefore, I would recommend choosing a provider whose SLA contains provisions that promote business process continuity. For example, the availability of a data center certified by the Uptime Institute for TIER III compliance and geographically distributed sites means that such provider has a fault tolerant infrastructure, modern equipment and employs best data center design and deployment practices and properly organized operation processes.

Ownership of a data center building gives a provider another significant advantage, making it easier to build relationships with it (with no middlemen) and identify responsible persons in case of disputes.

Along with technical aspects, it is important to evaluate a provider’s team. As a rule, even during the first interaction with a provider, a customer can decide whether their team will be a good fit or not. I would recommend paying attention to their response time, the ability to give comprehensive answers, as well as expertise in related industries allowing them to solve cross-technology problems.

A SLA should always contain technical support criteria, including its availability, response time and efficiency. Even though many providers claim 24х7 support availability, sometimes it is nothing more than a declaration. Just submit a query to a provider’s helpdesk and see if they respond as fast as promised. Sometimes a SLA also includes contact details of responsible managers, which helps accelerate the resolution of many problems, as requests are received directly by managers who then forward them to appropriate specialists.

In rare cases, systems can be migrated to a cloud as is, without adaptation to a cloud infrastructure. But typically, any migration starts with customer's system optimization and rebuilding in order to fix all the bugs and achieve the most efficient system operation in the cloud. Providers should always inform customers of this requirement so it can be fulfilled in full to ensure service satisfaction. A question is whether to perform such optimization for free or not. We believe, it should be a free option and set forth in a SLA. Before starting the migration, a customer and provider should list all requirements to the infrastructure and services to be hosted, as well as specify data transfer steps, deadlines and results. At this stage, a provider should not only meet customer’s demands but also provide consultations and recommendations.

A proper SLA should start with brief description of a system (name, technology, etc.) and define roles of process participants (users, HelpDesk specialists, a list of company’s business units, etc.).

Regardless of system functions and features, a SLA should define service quality and universal provider performance metrics. A SLA can also refer to other process-specific documents and should indicate request processing systems in use and links to their regulations.

If a company has a complex IT infrastructure consisting of many systems, then a separate SLA can be drafted for each system. Thus, from the very start, it is important to make all SLA metrics and their values universal, ideally by dividing systems into classes (Mission Critical, Business Critical, and so on). Never forget that a SLA is a regulatory tool that requires periodic revision (usually, once a year).