In this scenario, developers quite happily begin to use the private cloud, but, when confronted with unwillingness on the part of operations to support self-service, application elasticity, etc., become dissatisfied with the offering and choose to either: (1) deploy the application outside of the internal data center; or (2) more worryingly, turn their back on the private cloud and choose to develop and deploy in a public cloud environment.

This kind of situation can be blunt or subtle, but, in the end, falls short of what developers want. One of the main points that we emphasize with our clients is that cloud computing reduces the friction in obtaining and using computing resources -- discarding the endless requests, meetings, telephone calls, emails, escalations, not to mention the often heavy-handed rationing of resources that expects developers to justify why they want a server (or storage or whatever).

Putting an unresponsive production infrastructure behind an agile development environment may end up investing in a development cloud that ends up unused. Even worse, this scenario can hold the potential for stranded investment, as expensive production environments lie fallow while applications are deployed into public clouds that support low friction interaction.

Overall, organizations looking to deploy private clouds should thoroughly understand what they're signing up for. A development cloud is an appropriate start, but is not sufficient for a long-term plan. It's inevitable that a development cloud will be the first step toward implementing a larger production environment capable of supporting self-service, elastic provisioning, and agile operations fully committed to cloud computing characteristics. Anything less will, in the end, fall short.

Bernard Golden is CEO of consulting firm , which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.