Do SLAs have more/less importance depending on if you're running a private, public or hybrid cloud?

Good points Crystal - they are equally important and you make some good observations with respect to risks associated with each. The only things I would add are that the farther you move away from the "private" cloud (i.e., private to hybrid to public), the harder it is to define and enforce SLAs. As you build applications from distributed cloud services, the likelihood of having meaningful SLAs diminishes pretty quickly. We've written quite a bit about this here on Focus.com, so check out some of those threads.

The other point is to carefully read and understand the SLA's definitions of performance, availability, accessibility, recoverability, etc., and ensure that you know the roles and responsibilities of each party. In the private cloud world, this might be a tad easier since everybody is the same enterprise. But even then, you have suppliers of the piece-parts from which you are building your private cloud, and you need to understand their SLAs, support processes/procedures, and warranties.

We are learning quickly that "architecting for the cloud" is an essential step in application and systems design. "Plan for failure" is the new mantra. So understanding those SLAs and R&Rs, regardless of the cloud model you choose is vitally important!

Good answers Crystal & Robert. SLA's are indeed a slippery slope, but definitely a requirement of any organization looking to do anything in the cloud (public, private, hybrid, et al). When you are evaluating providers, an SLA audit should be at the top of your due diligence list. It needs to be robust, complete and comprehensive. It gets a bit trickier when you look at private clouds because more often than not, they are done internally, in your own data center and with various vendors (virtualization and potentially consultants).

With a Private Cloud, who owns up to issues on hardware, software, cooling, bandwidth, security? Are they different departments within your organization? Do they have different individual SLAs with different uptime guarantees or response times? These are often hard questions to ask internally.

These were questions that we identified early when we compiled our Hosted Private Cloud offering at GoGrid (http://privatecloud.gogrid.com). We had many years of experience servicing our public cloud so we wanted to ensure that our Hosted Private Cloud solution upheld the same SLA standards. We take the worry of internal SLAs out of the equation by simply offering our SLA for our dedicated, managed solution.

The reason I'm doing a bit of a "pitch" here is because it's quite unique in the marketplace. We already Orange Business Services as a customer with many more in the wings, and the SLA is a big factor in their decision to go with us.

Just my 2 cents!

SLAs don't matter too much without severe consequences / remedies. When there are severe consequences / remedies, then they matter more in the context of a public or hybrid cloud.

If I guarantee 105% uptime to you in an SLA (which you'll note is impossible), but offer the remedy of "I will give you 3 cents for every month I don't make 105% uptime", then what is that SLA worth ? Nothing. It is purely marketing spin.

However, if I offer 95.3% uptime in an SLA and give you the remedy of "5% cash back to you of the total contract term value for each month I miss the SLA", then all of the sudden that is a very legitimate SLA.

Too many organizations get caught up with whether or not there is an SLA, but the real thing you should look at is whether or not the SLA has real teeth where your vendor will really suffer for missing it.

When an SLA has real consequences and remedies, you'll typically see that promises come way down from numbers like "100%" or "99.9%", but you can usually believe that the vendor organization really does know its operational limits, and will strive mightily to never, ever miss that SLA.

I'm a big fan of ITILv3 for mid- and large-sized organizations that manage large number of IT assets. If you follow this best practice, which describes delivery of IT as a service, then you don't have a complete service package without defining your SLA.

The SLA, to me, is the artifact that represents that you understand the end-user's needs and that you can represent that appropriately in your business' demand management during the service strategy definition and then later support in capacity management.

So, instead of looking at the SLA as a CYA tool, look at it as a tool to facilitate the right conversations between IT and the business.