What SL did you just A to?
IT leaders like you live in a world where the only thing you can be certain of is that there will always be new – often unexpected – business challenges to address.
These unanticipated challenges might take the form of security issues (or attacks), compliance or regulatory changes, technology refreshes or problems encountered during regular maintenance. For business-critical workloads in the cloud, your first point of protection against these challenges should be the services offered by your cloud provider – in short, your SLA.
However, not all Service Level Agreements are created equally. Given the massive migration to cloud solutions, the ease of standing up new services and workloads in the cloud, and the sense of urgency many companies have in establishing a cloud strategy, things can easily get rushed or overlooked. In particular, service level obligations can be a less-than-transparent part of the process, resulting in inadequate coverage being discovered only when it is too late.
The best way to be prepared for those unexpected challenges is to clarify ownership and triggers for the SLA resolution steps before an issue occurs. Basics like bandwidth and uptime (usually part of the pricing model you choose) are typically the easiest elements to identify when planning a move to the cloud and selecting a service level offering. But they are just the tip of the iceberg. Specification-level metrics like this may or may not relate to relevant business metrics, just as airspeed and aircraft type may be interesting data points, but probably not the most relevant considerations when selecting an airline for your next trip.
To establish a truly useful SLA, it is crucial to understand how geographic coverage, the strict definition of availability and downtime, and who – the cloud service provider or the customer – is responsible for specific operations and processes. For example, an SLA offering 99.99% uptime still equates to almost an hour of downtime per year. And carefully worded fine print in the SLA of a cloud service may mean that events that seem like catastrophic outages don’t actually qualify for any sort of protection or remediation [1,2]. Your business is stuck suffering the very real consequences of a disruption in service.
Even if an outage is covered, there are still critical questions to be addressed. This is where the other half of a cloud service contract comes into play. Where will your support come from? Will they be available in the middle of the night, whether that’s when an issue occurs or simply because that may be when it’s most convenient for you to do work involving planned outages? Are there consulting services available from a real human being, rather than troubleshooting guides or AI chat-bots?
Before committing to a cloud platform, you should understand the full spectrum of the service you will receive as a customer. This includes defining boundaries on liability, compliance and security checkpoints, ownership of key operational task work, and even ownership of data stored on the service provider’s system. Beyond this, there are other considerations that should be included with your contract. Specifics around the location and operational hours of support personnel need to be addressed. The availability (and pricing) of additional services or expertise to augment your in-house capabilities should be clear as well.
Establishing clarity around your cloud solution’s SLA will save time, resources—and above all, headaches—if completed prior to the inevitable occurrence of unexpected business challenges.
Nitin Krishna
As Sr. Director of Cloud Product Management, Nitin oversees the entire cloud lifecycle process from concept, to design, to implementation. In addition, he manages the improvements to the cloud platform, prioritizing new features and functionality, building those into the product.