If you’re a hospital, a government facility (or even a datacenter) – do you rely only on the power grid? Of course not, you get yourself some backup generators – just in case. The same applies to the cloud: organizations that really do need 100% uptime can and should embrace the cloud, but they should do so with a well-prepared contingency plan – just in case.

Cloud computing has become too much of an either-or question. Both vendors and customers need to start thinking how they can change that into an answer where everybody wins.

Read the article: 5 reasons Gmail’s fail is not the end of cloud computing

I recently talked with a cloud architect at IBM, a really smart guy who presented his personal vision of the components of a cloud offering – see below (click for full size):

Let’s clarify what this architecture is for. Whether you’re a large enterprise consolidating your computing resources into a private cloud or a new player trying to compete against the likes of Amazon – this is what you need.

The interesting thing, especially for the startup community, is what’s missing. While much of the OSS layer is present, it’s the boxes in the BSS layer that are in practice sparsely populated. This casts light into the kinds of technologies that vendors like IBM might be shopping around for some day. These understandings can be applied not only regarding vendors, but also regarding the major cloud providers. Despite the fact that most if not all use their own proprietary technologies – they still need to fill in the same boxes.

So what’s missing?

To a very high degree, much of this new service offers functionality that was already doable. Extending your network into the cloud with a VPN and securing your instances from any external network access was not impossible – it just required some work. Amazon have done a great job at realizing what people are trying to do anyway and turning it into a seamless part of the product experience.

VPN or no VPN, at the end of the day when you run in the public cloud you are still outside your hardware, outside your premises and outside your control. Only when businesses realize that full control is more of a liability than an asset will they truly embrace the cloud and realize its potential.

Here’s what I found.

1. Economy

The most frequent reason cited was that the cloud wins in cost. This isn’t fantasy, it’s reality: these companies significantly slashed their costs by switching. One CTO proudly mentioned his board of directors’ enthusiasm upon seeing the the new bottom lines.  Overall, there was agreement that despite the initial price tag – some work required to switch – it’s totally worth it.

2. Elasticity

Scale up, scale down, on-demand, the sky’s the (theoretical) limit, ’nuff said.

3. Development and testing

The process of developing, debugging and testing is not fully addressed in a classic deployment environment. It gets easier by an order of magnitude in the cloud. Staging environments, parallel testing and ad hoc farms can be created and destroyed at the developers’ pleasure.

Although this usually wasn’t the primary motive for switching to the cloud (as opposed to the reasons above) it was a bonus many chose to highlight.

4. Experimentation

The cost of experimentation is very low in the cloud. This is making it easy for companies to test drive new concepts without making a large up-front commitment. If it sticks, the transition into a fully-fledged application is smooth.

Non-reason:  Proprietary technologies

Notable absentees in the motivation to switch to the cloud were the new but proprietary services offered by several providers. There appears to be a notable degree of resistance to vendor lock-in, which is the Achilles’ heal of services such as AppEngine, SimpleDB and SQS alike. This is perhaps the secret to Amazon’s success in the cloud – its strongly decoupled offering allows for a pick-and-choose approach, without major paradigm shifts – evolution not revolution. Companies clearly prefer standard tools based on tried and tested technologies.