Ownership of Public Clouds

I’ve recently been chewing through BlueMountainLab’s podcasts on Cloud Computing. I’ll be honest – I’m a skeptic when it comes to cloud computing, but I’m developing a better understanding of it after listening to ‘casts on this topic for about 2 hours (maybe I’m just been brainwashed?). If you’re not immediately familiar with what this term means, check out the below video – you’ll see some of the biggest and brightest minds in digital technologies explain in simple terms what ‘cloud computing’ is.

Unless you’ve been living under a rock, or away from a digital connection, for the past couple of years you’ve likely experienced cloud computing. Have you hopped into Google docs, Zimbra, or any other environment where you perform standard tasks in a web-based environment? If so, you’ve been ‘in the cloud’. What we’re seeing is a shift away from centrally owned company infrastructure toward infrastructure that is owned and operated by another company. To picture it, rather than host your own mail servers, you shift your corporation over to Google Apps, and at the same time can take advantage of the word processing, chat, and page creation features that accompany the Google solution. Should you need to increase storage, or alter your current feature set, you can have it set up in a few hours – this contrasts with spending corporate resources acquiring a solution, installing it, educating your users, etc. By outsourcing high-cost, high-time-sink operations you can realign your IT staff so that they can focus on corporate issues; designing unique solutions for unique problems, focusing their skill sets in more cost-effective areas, etc.

I don’t really like cloud computing, but that’s largely because I’ve seen what happens when you have a medium-sized user base that is suddenly divorced from ‘net access. Things just stop. Productivity plummets, and there isn’t anything that IT can do other than say ‘Someone else is working on it.’ Working in the cloud heightens vulnerability to Internet service disruptions. This isn’t to say that a standard business won’t suffer if their ‘net is cut, but imagine the difference in output productivity for companies in the Middle East that recently had their bandwidth either cut off entirely or severely limited by the recent damage to undersea cables. If your business had transitioned its collaborative document sharing to Google docs, as an example, you would have been (and continue to be) at the mercy of repair crews to repair your connection to the greater ‘net. If, on the other hand and as an example, you had developed and hosted a local sharepoint server you’d still have your intranet access to locally hosted and collaboratively worked on documents.

I don’t like that kind of reliance on other people, but I can appreciate the desire of small businesses to want what were previously Enterprise-only capacities without the associated Enterprise costs. I also think that, once someone gets struck by lightening in the cloud, that they will likely reconsider any substantial reliances on a third-party for mission-critical service. This can sometimes result in duplication efforts – what is in the cloud is also kept locally – but this undermines the advantages of the cloud; if you’re hosting locally anyways, why bother with the cloud in the first place?

This, in part, gets into a discussion of ownership in public clouds. By this, I’m not referring to who owns the data – I’m assuming that you realize that as a content creator you ‘own’ your own data. The companies providing the cloud computing services (presumably) have no interest in owning the data their customers generate – they are in the business of selling their services. No, by ownership, I mean that by giving yourself over to a cloud you subject your own IT department to the whims of your cloud provider. This is, potentially, a real concern.

This issue isn’t new, but it was hammered home to me when I read an article over at tgdaily.com entitled, “Google tells users to drop IE6.” By shifting to a cloud computing environment, you are subjugating your internal IT staff to the norms that are imposed by your cloud provider, and that’s not necessarily what you want to be doing. For very good reasons, you IT staff may have developed a set of corporate norms that identify what browsers, chat clients, etc are and are not permitted in the IT environment. I know enough about how Google operates with companies who have chosen to use Google Apps that there is a reasonably limited range of control that system administrators have when it comes to adjudicating what Google does, and doesn’t, do. (I actually have set up small non-profits’ networking environment, and these groups wanted to use Google Apps. This has given me first-hand experience with the Apps environment.) Thus, when you have your cloud provider, effectively, ordering you and your users to a new web solution your IT team is forced to adjust intentional policies in favor of third-party mandated ones. (I realize that, assuming your IT department is worth much at all, that Google telling users to move away from IE6 isn’t something that hasn’t already happened. This article just highlights the power of your new infrastructure vendor over your own corporate policies.)

One solution for this borders on what Yahoo!’s Zimbra does – a local installation of email that strongly resembles a Google/Yahoo!/Microsoft cloud environment. This has the relative advantage of both keeping your own data local, as well as minimizing your dependence on the wider cloud to send and receive messages around your organization/share documents/etc. At the same time, you can take advantage of Zimbra’s expertise (epistemological economy of scale) to maximize your IT investment. (Obviously, if your organization is five people in a single room the value of maintaining data locally for sending and receiving messages is less than one where you have sixty, two hundred, or ten thousand users.) Given the relative sensitivity of many corporate documents, it seems to me that managers should be very careful in determining whether or not they want their communications infrastructure to be entirely outsourced beyond the walls of their company, with little or no way of ‘getting to’ system administrators who actually give a damn about your problem. Believe me, when you contact out-sourced IT support they are far less concerned with quickly getting a problem resolved than your internal IT support team, who will be pulling all-nighters until mission-critical systems are restored. (Case example: Try calling your ISP’s IT staff at 12pm. At the same time, ask your teenager for help. Immediate differences: the ISP is closed and not responding to your calls, vs a teen that is probably still awake; an ISP ‘who cares about your needs as a customer’ vs a teen ‘who *needs* the Internet to do my home/chat/downloading/etc.’)

This shouldn’t be read as a total condemnation of cloud computing, however. What should be taken away is that clouds might be best used where they are private – internal to the corporation. ‘Privatizing’ the cloud has the advantage of alleviating customer concerns about data privacy, and the ability of third parties to access confidential data. As soon as sensitive data is put in the hands of third-parties, you are responsible for ensuring that third-party security infrastructure meets your own policies, and for auditing that third party to ensure compliance (if you’re serious about policy compliance, at least). Money spend on that party can probably be better spent on your own house – why check out your neighbor’s house and your own when you can just focus on your own house’s foundations?