MANAGED SERVICES cloud
Any business adopting cloud services must carefully consider and negotiate public cloud SLAs before entering into any contract to ensure that its cloud applications, and hence its competitiveness and performance, are adequately protected.
Assessing the cloud infrastructure: why a cloud provider’s architecture impacts SLAs Public cloud naysayers insist that enterprise applications cannot be delivered via public cloud infrastructure. Yet the public cloud is being used to deliver all types of business critical enterprise IT applications, if the cloud provider maintains a high performance architecture.
Architecture can significantly impact performance of processing, memory access, file I/O and network throughput. can enable secure and reliable SLAs. Cloud services that enables network control are easier to secure and can be higher performance than “best effort,” server-centric cloud competitors. By allowing configuration at the networking layer and network-based security, network- centric cloud providers also deliver strong, enterprise-class performance.
The devil is in the SLA detail Knowing what to look for in an SLA is vital to measure and compare cloud providers and models. Traditionally, buyers have done this by requiring a minimum of “three nines” for their uptime guarantee (99.9%). However, oftentimes, SLAs cannot be simplified into a number of nines.
Many businesses find that the committed uptime percentage and areas of coverage should only be the starting points of their SLA agreement. The devil really is in the detail. There are a number of questions to ask and details to confirm with any provider’s SLA. Outlined below are the five most common considerations.
1. What level of uptime is the provider committing?
The ‘x nines’ SLA for uptime is usually the first cited and least meaningful part of a cloud provider’s SLA. Nevertheless, it is the first key point of an SLA to identify when evaluating your options. Many popular cloud providers today offer 99.95%, so look for a vendor who offers 99.99%.
2. How is uptime calculated?
SLAs are typically calculated monthly and are based on the period of a client’s downtime, or service unavailability. This is a relatively standard policy across public IaaS providers, although businesses would be advised to read the small print carefully as some well- known providers take a far different approach to this calculation. Instead, some use an annual uptime calculation of their platform, assuming that the service achieved 100% uptime for the previous 12 months (before the client signs on as a customer).
3. What does the SLA cover? There are usually five key areas for SLA applicability. The continuum ranges from facility and hardware-level SLAs, which are the least meaningful and most prevalent, to application level SLAs, which are the most meaningful and least common among IaaS providers.
Outlined below are the five areas: £ Facilities level (space and power) £ Hardware level (the underlying physical architecture)
£ Operating system (OS) level £ Platform level (for Platform-as-a-Service) £ Application level (for Software-as-a- Service and public cloud providers coupling managed services with their IaaS)
Public cloud SLAs most commonly cover availability, not performance, to the hypervisor level, meaning that if a business corrupts its operating system environment, it is responsible for fixing it, or deleting the server and starting over. The provider is typically responsible for ensuring that everything below the hypervisor is available to their users. Some cloud providers also offer an SLA for application delivery, though this typically requires some managed services agreement.
4. What constitutes failure under the SLA? Significant diversity exists among public cloud providers in the “failure” area. Businesses should be wary of SLAs mandating that numerous “availability zones” or “regions” need to fail to be considered an SLA violation. Many well-known cloud providers require two or three availability zones to be in use for an outage to be considered an SLA violation, meaning that the provider will not take any responsibility if
only one region fails. In this scenario, some cloud providers even stipulate that the client build another server in the failed region and have it fail a second time before they will consider the event an SLA violation.
5. What are the penalties for SLA violation?
After some threshold of downtime has been reached, most cloud providers will commit to refund a percentage of the fees paid for a given period of time (generally monthly). Businesses should be certain to carefully compare the time durations and associated percentage of fees the provider agrees to refund in the event of an outage.
Look beyond the nines As is demonstrated by the examples above, there is much more to a provider’s cloud SLA than simply an uptime percentage guarantee, and savvy businesses need to investigate their options and vendors carefully. The key to doing this successfully is to understand the details of the SLA: what is covered; the definition of downtime; and penalties.
Additionally, buyers should understand how the architecture of a cloud provider’s offering impacts security, control and SLAs. Be especially mindful of server-centric and network-centric cloud models against the above SLA considerations.
More often than not, they will find that the network-centric cloud model offers stronger, more reliable SLAs to protect the long term delivery of business critical applications in the public cloud.
Significant diversity exists among public cloud providers in the “failure” area. Businesses should be wary of SLAs mandating that numerous “availability zones” or “regions” need to fail to be considered an SLA violation
November 2013 I
www.dcseurope.info 47
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56