A couple of days ago, I posted some thoughts about the recent Amazon AWS outage. In the passing days, many others have written their own missives collecting their thoughts on what may have happened and the ensuing consequences. The opinions range widely from a typical outage to outrage to a potential cover-up of a larger issue.
The ramifications of the outage are certain to impact the stratospheric velocity of the cloud computing trajectory. Many will consider the impact in a very negative way. They may go so far as to say that an outage at the poster child for cloud (Amazon) demonstrates that the cloud market is still immature for the demand it seeks.
While some place the blame squarely on the provider (Amazon in this case), others point to the short-sided expectations of the clients. Personally, I believe both carry some responsibility in the matter. This is true of all cloud providers and those that leverage the cloud. Further, it is not specific to cloud, but any provider that one uses.
I’ve been on both sides of the coin over the course of my career; both provider and consumer. The objective should be to create a true partnership. But what is a true partnership? And what are the characteristics that differentiate a partnership from a traditional vendor/ customer relationship? We each may have a different set of objectives and characteristics that define a partnership.
A partnership is much like a personal relationship; friends, family, etc. And both parties are responsible for maintaining the partnership over time. Partnerships take work. As such, there are several attributes that characterize a true partnership. Honesty, trust, communication and shared responsibility are just a couple of the core attributes. Without a solid foundation, it is difficult to pinpoint expectations. I could delve into the realm of SLAs and SLOs, but will save that for a future entry.
While it is well and good to talk about what makes a partnership, is it (or should it be) necessary for the cloud market? That depends on the expectations. If the expectations are for basic services with few requirements around confidence, then probably not. If, however, the expectations are more critical to the business or the expectations are higher, a stronger relationship is warranted. And I’m talking about more than just a contract and SLA.
There are many ways to create a partnership. Understanding what is core and important is a good first step. I’m not referring to technology requirements. I’m referring to relationship requirements. What is important to you for that specific service or offering? Thinking ahead, what is expected when things do not work as expected? Do both parties agree to the approach? In some cases, this may be a simple documented communication and action plan. In other cases, it may require a more engaged discussion.
In many ways, this is not too different from a contract. What is a contract? Frankly, it should be something you negotiate at the beginning of the relationship and never have to refer to again. But it really serves as a backstop for when things do not go as planned. SLAs may serve in a similar capacity. When the contract is negotiated, both parties agree to the process, actions and consequences…up front. When something happens, you know what to expect.
But is that really enough? Plenty of providers have written contracts and SLAs available. They provide a basic understanding of expectations, but do not go far enough for critical business processes. In those situations, one needs to look deeper into the organization, the processes, the expectations and the level of relationship to establish. Where there is a gap, correct it. When there is confusion, clarify it.
I was told many years ago that the best business relationships have a senior or executive-level relationship behind it. That is very true to this day. I’m sure this is harder to do with the larger providers. But you may be surprised.
Bottom Line: Look beyond the contract and SLA. What other attributes are in place to ensure a successful relationship?
A common misconception of the cloud is that it is a panacea for everything that ails IT, but it is important to remember that regardless of where your infrastructure is, “everything fails all the time”, and as such, you need to plan for it. While contracts, SLAs, and partnerships all play a vital role in achieving successful implementations in the cloud, it is important to remember that best practices can oftentimes alleviate the need to dust off those contracts.
– Brian Adler, PS Architect, RightScale
To me, “the cloud” is a fancy name for hosted services mashed up with virtualization, and juiced up with instant-on provisioning and elastic usage billing. It’s a new — and welcome — twist on an old concept. Companies want to use the cloud in areas where it makes sense — for hosted email, productivity, and sales automation — but they want to do it only when they can be assured that their data is secure.