Cloud Failures Aren't The Problem; IT Is

Users go out to the Web to find tools to help them do their jobs. IT can meet them halfway with a roster of tools that IT has vetted as acceptable. In some cases, IT can even preload them into a corporate portal to make them more easily accessible, or create a service catalog of pre-approved cloud apps. This will allow IT to add features such as single sign-on, providing a stronger degree of authorization and access control, and making it easier to remove a user from a set of services if that person leaves the organization.

If IT can demonstrate some flexibility on its part, then it may become easier to enforce compliance with business users when the cloud just isn't an option. For instance, business users have to accept that documents containing core intellectual property are going to live inside a clunky, locked-down enterprise content management system. But that pill may be easier to swallow if IT can live with the idea that sales presentations built in partnership with an outside agency can reside on a cloud-based file sharing service.

IT also can't ignore the cloud when it comes to business-critical systems. SaaS-based business apps, and platform and infrastructure services hosted in the cloud, offer quick startup times and very compelling pricing. These benefits need to be weighed against risks, including security and availability, but IT no longer has the luxury of saying "no" without justification. As Cisco's Jacoby put it in a roundtable discussion with reporters, "IT has to know whether a service outside would be more efficient."

That said, IT can't simply wash its hands once it has signed up with a provider. The Amazon outage is a clear example of the role that IT must play as a broker of a third-party service. For Amazon, or any cloud-based provider, the service must be set up to assume a failure at one or more of the provider's data centers (or Availability Zones, in Amazon parlance), and be able to quickly shift to a second site. Blog posts on the outage from AWS customers Reddit, which was badly affected, and SmugMug, which wasn't, demonstrate the need for the kind of risk assessment and disaster recovery thinking that IT can bring to the table when building on top of a cloud infrastructure.

IT also can learn from providers about how to respond to problems. A common complaint about Amazon was a lack of communication about the outages and how the company was fixing them. Of course, any business user who's run into problems with an application or submitted a help desk ticket might echo the same sentiments about their own IT department. IT isn't staffed to hold every user's hand or provide high-touch concierge services, but corporate social networking tools make it much easier to open communication channels with internal customers.

CIOs can learn a lot from the failures of public cloud providers: How to structure a service for high availability. How to check an SLA for gaps in coverage. How to interrogate a provider about its security model. But they can also learn how to transform their own internal operations to be more like a public cloud provider: fast, efficient, and ready to meet customers where they are. That's the real lesson of the cloud's unhappy spring.

Recommended Reading: Cloud Services, SaaS Pose WAN Bandwidth Challenges Clouds Change Storage Administrator's Role DARPA Seeks More Resilient Cloud Infrastructure Lessons From FarmVille: How Zynga Uses The Cloud Tough Questions To Ask Cloud Service Providers SMB Cloud Spending To Double By 2015 See more by Andrew Conry-Murray

Vendors are fighting it out in the market for integrated network, computer, and storage systems. In the new all-digital issue of Network Computing, we go ringside to help you pick a winner. Download the issue now. (Free with registration.)