Google has been having a long argument with companies like VMware and EMC on whether the future of cloud computing will be centrally managed distributed services from companies like Google or whether it will be centrally managed distributed services that the company itself will control using technology from one of the large providers.
Last week, we once again saw the reliability problems that make it difficult to trust Google's services. It would be easy to argue that the public cloud won't work because it isn't reliable. But I can recall folks saying the same thing about Windows and Linux with regard to their enterprise capability. Heck, I said it myself with regard to both platforms, but both eventually grew up and they are now clearly enterprise ready. I started out as a telephony analyst, and telephony had a similar cycle. You had a choice between putting in your own PBX (or CBX if a ROLM system) or using a highly leveraged central office switch, which arguably cost a great deal less. A lot of companies used these centralized services and they did experience the cost savings; however, this was not the way the PBX market moved, and that market was very similar to the concept of the cloud. So why did cheap not win out?
Control Is More Important Than You Think
Large centralized services tend to focus heavily on cost control. That doesn't sound like a bad thing because saving money is what you are after. But when a service is focused on saving cost as an absolute, other things you may want this service to do get lost in the shuffle. In other words, from the standpoint of a centralized telephone service, as long as you were happy with basic phone features, you were fine, but as soon as you wanted call logging or different-sized voicemail boxes, or even unique phones, you suddenly found you were in a Model T world. You could have whatever you wanted as long as it was on the menu, and the menu was kept intentionally short.
In addition, whenever there is a technology change, the timing is that of the provider. They'll pick a time that is the most convenient and least costly to them. That can create serious problems if the upgrade goes badly and/or it is initiated during a time when you have a very high call volume. Centralized phone services are provided by utilities and they have forced customer loyalty. Now with phone systems, changes happened around once a decade so this wasn't a huge problem. But think about patching that might need to occur several times a week.
Finally, security was an issue. You can take over a phone and remotely switch it into a speakerphone, which is a lot of fun until someone outside of the company does it and you have an SEC moment. Logs can track this activity, but in a centralized hosted environment, can you trust the logs? I ran an internal audit group for a time and could audit the security of a PBX, but couldn't if a hosted service was used. This left an open security exposure that was hard to accept because it was almost impossible to estimate the related risk.
In short, while the cost savings were real, the loss of control became a bigger problem and most companies decided to take their telephone services private. I think the cloud will go the same way.
Public vs. Private Cloud
I see similar problems with the concept of a public cloud and hosted enterprise telephone services. Services and capabilities are tied to the provider's view of the world. Because the service has cost at a priority, getting needed changes in a timely manner will increasingly approach the impossible. Watch Google; it does what it thinks is right, down to scaring local homeowners and implementing poorly tested updates. It is the kind of vendor that appears to think the customer works for it. In short, responsive is not Google's middle name.
Technology advancement in this area is running at a very high speed. Not only does that mean a lot of unplanned disruptions but the increasing possibility that the timing will be less than ideal. This doesn't mean that small businesses won't use the service. Certainly they will, but enterprises typically need to assure systems like this. Being down at a critical time can be avoided with internal upgrades, but is at risk when provided by a public cloud utility. While it may be possible to create a public cloud service as secure as a private cloud, certifying the security level would be nearly impossible. You could host a private cloud, but to get the cost savings a public cloud service has to be free to shift loads widely. For all practical purposes, that makes certifying the result virtually impossible. It just takes one server, network device, or location that isn't up to the standard to break the model. The resources to assure that doesn't happen are beyond most governments, let alone companies.
As it was with Netscape, Google seems to largely not understand the requirements needed to sell to the enterprise. This isn't an uncommon problem. Microsoft went through a long learning period too. However, Microsoft came at the market in a more traditional way. As a result, its solution fit reasonably easily into existing processes and policies. Google is trying to break the model and this approach carries risks that most should find unacceptable for an indefinite period of time. Certainly, there are ways to mitigate the problems I've listed, but the easiest path is to simply contain the cloud structure inside an organization under the control of the department getting the service. As soon as you do that, you have a private cloud structure. This suggests that, eventually, even Google will have to move to this private cloud model.