As reported on Wired.
BY JAKE GARDNER
Image: infomatique/Flickr
Why seven? Why not?! While none of these problem areas align with the so-called deadly sins, the reality is that each represents a real challenge that can arise in many organizations, whether enterprises or SMBs, when it comes to implementing and maintaining a cloud architecture.
These are universal challenges. While each is not an ultimate, insurmountable hurdle to adoption, thinking about how each of these is wrong, or at least misguided, is a smart way to navigate toward successful cloud strategy and implementation.
1. Organizational ignorance: Cloud is a hot concept for many businesses. In the last year, the emphasis on cloud computing as the go-to solution for infrastructure needs has propelled it to the forefront of the IT discussion, with many believing it will eventually become the way IT operates at a baseline.
However, the road to implementation is still fraught with difficulties and competing agendas in many organizations. Similarly, given the boom in the space, the parallel growth of cloud providers has lead many vendors to offer services that might not be best suited to a company’s strategic and operational requirements, simply because the sale can be an easy one. With a lack of internal understanding, or even a reticence by internal staff to provide a comprehensive reasoning for cloud (for fear of losing their jobs), chief decision makers are often not working with all the facts that could provide them with best reasons for or against cloud implementation.
2. Belief in just the SLA: Service Level Agreements, or SLAs, are important to consider for when something is going wrong. While such agreements do not guarantee that something won’t go wrong, many organizations sign SLAs assuming uptime and business continuity are assured. When things go down, with nothing more than a service credit and a cloud provider scrambling to regain uptime to show for it, businesses can lose untold amounts of revenue and get very little back for their trouble. Amazon famously dodges liability in its SLA.
Ultimately, an SLA doesn’t ensure uptime — building a redundant architecture does.
3. Role assumptions: When a business signs on to work with a particular cloud vendor, more often than not, the divvying up of roles and responsibilities is left in an assumptive state. Without clearly defining who has access to what, and what that can entail from a roles and responsibilities and workflow standpoint, a lot can go wrong that could pus both the cloud vendor and client in the wrong, damaging their business relationship, ultimately hurting the client’s business.
Having clearly defined conditions, such as determining whether root access is a necessity for a client, has strong claims toward ensuring that the business relationship is valuable for both the client and the cloud vendor.
4. Accepting guarantees of compliance: Often cloud providers guarantee compliance as part of their offering. This is well and good, unless of course compliance is only achieved in the loosest sense. If a business is dealing with any customer or proprietary data, or personally identifiable information of any sort, it needs compliance, and to know how that is achieved.
Many providers will claim to be compliant, but without knowing how that works at a technical or a policy and protocols level, it’s hard to feel safe. A business looking at any cloud vendor should always ask how the different levels of compliance are matched with security, how logs are kept and managed, and which organization performs the audit (this can actually tell you something about the caliber of compliance being sold).
5. Unregulated usage: Cloud is great for businesses when used in smart and cohesive ways. However, for many larger companies, hurdles to gaining access to IT resources may create autonomous decision-making for cloud adoption, group by group, since the ability to purchase and provision resources through the public cloud (often Amazon Web Services) can be simple.
This can, however, lead to a lack of unification where the IT strategy is concerned, with disparate groups all maintaining their own clouds without any oversight or guidance. What if there is sensitive information being put on a multi-tenant environment? That can create major compliance issues, and therefore legal problems. Cost can similarly spin out of control, because while consuming public cloud resources is relatively cheap, without knowing how much is being consumed at cost, it’s hard to judge whether the tool is beneficial for a business’ bottom line.
6. Thinking outsourcing removes risk or liability: There are many reasons to outsource a business’ infrastructure to a cloud provider. There are cost benefits, management benefits, and flexibility benefits. However, just because a cloud provider is running a company’s cloud does not remove it from owning a major portion of the risk associated with the arrangement. SLAs, MSAs, and contracts help ensure that roles and responsibilities are clearly defined.
But what if something goes down? What if customer data is breached? A business still has to deal with the ramifications of such events for its own customers and lost revenues. Yes, they can be mad at the cloud provider, and that relationship can suffer, but that makes little difference to how the company’s customers feel about their pain. In the end, risk is never alleviated. In fact, it can only be planned for up to a point. Ensuring a Highly Available (HA) cloud is a good step, as is maintaining constant communication with a cloud vendor. Ultimately, taking anything for granted is the biggest sin!
7. Failing to understand failure: The cloud fails. Amazon has many well-publicized failures from the past year alone. In the end, such failures will only impact businesses that have not built failure into how they think about the cloud.
Designing an architecture to withstand the loss of an Availability Zone (AZ), the crashing of a cluster, or even the loss of a data center (as with Hurricane Sandy) is all part of how a company should be thinking about the cloud. To not do so seriously jeopardizes a business’ cloud and increases its liability in terms of lost revenue and damage to the brand should something go down.
The reality of designing for failure with proper security, HA, and disaster recovery often ups the cost of cloud. But compared to the potential for lost revenue, is that price too much?